deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qg8r-f7x3-25f7
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.24.0
Patched in: 0.24.1

Summary: imageproc: Out-of-bounds read via NaN coordinates in bilinear/bicubic sampling

Details:
A bounds check was performed in floating points before a cast to the index passed to an unchecked access function. This checked considered `NaN` cases improperly, causing them to succeed the check instead of failing it. The floating point coordinate is under caller control by passing a selected projection matrix.

Carefully controlling the coordinates of an image with no data and one non-zero dimension provides an arbitrary read primitive in the first 32-bits of address space with a Bilinear sampling method.

Using bicubic sampling can result in a read of a few bytes beyond an allocation.

Other out-of-bounds reads may be possible.
GitHub Security Advisory: GHSA-qg8r-f7x3-25f7
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.23.1
Patched in: 0.23.1

Summary: imageproc: Out-of-bounds read via NaN coordinates in bilinear/bicubic sampling

Details:
A bounds check was performed in floating points before a cast to the index passed to an unchecked access function. This checked considered `NaN` cases improperly, causing them to succeed the check instead of failing it. The floating point coordinate is under caller control by passing a selected projection matrix.

Carefully controlling the coordinates of an image with no data and one non-zero dimension provides an arbitrary read primitive in the first 32-bits of address space with a Bilinear sampling method.

Using bicubic sampling can result in a read of a few bytes beyond an allocation.

Other out-of-bounds reads may be possible.
GitHub Security Advisory: GHSA-5qv7-j6w5-fr4m
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: imageproc has fragile bounds check when sampling from image

Details:
A read of pixels was coded as modifying coordinates to lie within the image bounds. It would calculate a coordinate by adding a constant to an input and taking the minimum of the resulting coordinate and 'dimension - 1'. This would not protect against malicious inputs that could overflow the addition. Following the tricked bounds check, the image could then be sampled at multiple differently calculated coordinates that exceeded the bounds.
GitHub Security Advisory: GHSA-5qv7-j6w5-fr4m
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.25.0
Patched in: 0.25.1

Summary: imageproc has fragile bounds check when sampling from image

Details:
A read of pixels was coded as modifying coordinates to lie within the image bounds. It would calculate a coordinate by adding a constant to an input and taking the minimum of the resulting coordinate and 'dimension - 1'. This would not protect against malicious inputs that could overflow the addition. Following the tricked bounds check, the image could then be sampled at multiple differently calculated coordinates that exceeded the bounds.
GitHub Security Advisory: GHSA-5qv7-j6w5-fr4m
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.24.0
Patched in: 0.24.1

Summary: imageproc has fragile bounds check when sampling from image

Details:
A read of pixels was coded as modifying coordinates to lie within the image bounds. It would calculate a coordinate by adding a constant to an input and taking the minimum of the resulting coordinate and 'dimension - 1'. This would not protect against malicious inputs that could overflow the addition. Following the tricked bounds check, the image could then be sampled at multiple differently calculated coordinates that exceeded the bounds.
GitHub Security Advisory: GHSA-q2qq-hmj6-3wpp
Package: hickory-proto (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.3.1, <= 0.26.0
Patched in: 0.26.1

Summary: hickory-proto vulnerable to CPU exhaustion during message encoding due to O(n²) name compression

Details:
During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`. The name compression logic then searches for matches with a linear scan.

A malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.

This is similar to [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).

### Reporter

Qifan Zhang, Palo Alto Networks
GitHub Security Advisory: GHSA-3v94-mw7p-v465
Package: hickory-net (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 0.26.0-alpha.1, <= 0.26.0
Patched in: 0.26.1

Summary: hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

Details:
The NSEC3 closest-encloser proof validation in `hickory-proto`'s (0.25.0-alpha.3 ... 0.25.2) and `hickory-net`'s (0.26.0-alpha.1 .. 0.26.0)  `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of the SOA owner, terminating only when the current candidate equals the SOA name. When the SOA in a response's authority section is not an ancestor of the QNAME, the loop stalls at the DNS root and never terminates, repeatedly calling `Name::base_name()` and pushing newly allocated `Name` and hashed-name entries into the candidate `Vec`.

The bug is reachable by any caller of `DnssecDnsHandle`, including the resolver, recursor, and client, when built with the `dnssec-ring` or `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is triggered while validating a NoData or NXDomain response whose authority section contains an SOA record from a zone other than an ancestor of the QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice this can be reached through an insecure CNAME chain that crosses zone boundaries into a DNSSEC-signed zone returning NoData, but the minimum condition is just a mismatched SOA owner on a response requiring NSEC3 validation.

A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds abort with a panic on the first iteration past the root. Release builds compile the assertion out and run the loop unbounded, allocating until the process exhausts available memory. A reachable upstream attacker who can return such a response can therefore crash a debug build or exhaust memory on a release build, for the affected configurations.

The affected code was migrated from `hickory-proto` to `hickory-net` as part of the 0.26.0 release. Hickory DNS recommends that all affected users update to `hickory-net` 0.26.1 for the fix.

### Reporter

David Cook, ISRG
GitHub Security Advisory: GHSA-3v94-mw7p-v465
Package: hickory-proto (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 0.25.0-alpha.3, <= 0.25.2
Patched in: unpatched

Summary: hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

Details:
The NSEC3 closest-encloser proof validation in `hickory-proto`'s (0.25.0-alpha.3 ... 0.25.2) and `hickory-net`'s (0.26.0-alpha.1 .. 0.26.0)  `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of the SOA owner, terminating only when the current candidate equals the SOA name. When the SOA in a response's authority section is not an ancestor of the QNAME, the loop stalls at the DNS root and never terminates, repeatedly calling `Name::base_name()` and pushing newly allocated `Name` and hashed-name entries into the candidate `Vec`.

The bug is reachable by any caller of `DnssecDnsHandle`, including the resolver, recursor, and client, when built with the `dnssec-ring` or `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is triggered while validating a NoData or NXDomain response whose authority section contains an SOA record from a zone other than an ancestor of the QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice this can be reached through an insecure CNAME chain that crosses zone boundaries into a DNSSEC-signed zone returning NoData, but the minimum condition is just a mismatched SOA owner on a response requiring NSEC3 validation.

A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds abort with a panic on the first iteration past the root. Release builds compile the assertion out and run the loop unbounded, allocating until the process exhausts available memory. A reachable upstream attacker who can return such a response can therefore crash a debug build or exhaust memory on a release build, for the affected configurations.

The affected code was migrated from `hickory-proto` to `hickory-net` as part of the 0.26.0 release. Hickory DNS recommends that all affected users update to `hickory-net` 0.26.1 for the fix.

### Reporter

David Cook, ISRG
GitHub Security Advisory: GHSA-fpf5-4jw8-67x8
Package: rust-zserio (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: <= 0.5.3
Patched in: 0.5.4

Summary: rust-zserio has Unbounded Memory Allocation

Details:
### Impact

When deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.

### Patches

Please cherry-pick [57f5fb](https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a[PII_REDACTED]dd99c3c).

### Workarounds

- Do not accept `zserio`-encoded messages from non-trusted sources.
- Allocate a maximum heap amount to `rust-zerio` to avoid impacting other applications.
GitHub Security Advisory: GHSA-p8xm-42r7-89xg
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 37.0.0, < 43.0.2
Patched in: 43.0.2

Summary: wasmtime has a panic when allocating a table exceeding the size of the host's address space

Details:
### Impact

Wasmtime's allocation logic for a WebAssembly table contained checked arithmetic which panicked on overflow. This overflow is possible to trigger, and thus panic, when a table with an extremely large size is allocated. This is possible with the WebAssembly memory64 proposal where tables can have sizes in the 64-bit range as opposed to the previous 32-bit range which would not overflow. The panic happens when attempting to create a very large table, such as when instantiating a WebAssembly module or component.

This bug does not affect the pooling allocator which limits tables sizes to much less than the required amount to trigger the overflow. This bug is only present for the on-demand instance allocator, which is Wasmtime's default allocator. This bug also requires the `memory64` WebAssembly feature to be enabled, which is on-by-default.

Panicking in the host process is considered a denial-of-service vector for Wasmtime.

### Patches

Wasmtime 36.0.8, 43.0.2, and 44.0.1 have all been released which fixes this issue.

### Workarounds

Embeddings can switch to using the pooling allocator to work around this issue, or the `memory64` WebAssembly proposal can be disabled. Otherwise there is no workaround and users are recommended to upgrade.
GitHub Security Advisory: GHSA-p8xm-42r7-89xg
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 30.0.0, < 36.0.8
Patched in: 36.0.8

Summary: wasmtime has a panic when allocating a table exceeding the size of the host's address space

Details:
### Impact

Wasmtime's allocation logic for a WebAssembly table contained checked arithmetic which panicked on overflow. This overflow is possible to trigger, and thus panic, when a table with an extremely large size is allocated. This is possible with the WebAssembly memory64 proposal where tables can have sizes in the 64-bit range as opposed to the previous 32-bit range which would not overflow. The panic happens when attempting to create a very large table, such as when instantiating a WebAssembly module or component.

This bug does not affect the pooling allocator which limits tables sizes to much less than the required amount to trigger the overflow. This bug is only present for the on-demand instance allocator, which is Wasmtime's default allocator. This bug also requires the `memory64` WebAssembly feature to be enabled, which is on-by-default.

Panicking in the host process is considered a denial-of-service vector for Wasmtime.

### Patches

Wasmtime 36.0.8, 43.0.2, and 44.0.1 have all been released which fixes this issue.

### Workarounds

Embeddings can switch to using the pooling allocator to work around this issue, or the `memory64` WebAssembly proposal can be disabled. Otherwise there is no workaround and users are recommended to upgrade.
GitHub Security Advisory: GHSA-qxrw-f6fh-34r7
Package: lemmy_api (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: <= 0.19.1-rc.1
Patched in: unpatched

Summary: Lemmy resend-verification endpoint exposes registered email addresses to unauthenticated users

Details:
## Summary

The unauthenticated resend-verification endpoint returns different responses for registered and unregistered email addresses. A malicious third party can submit candidate addresses to `/api/v4/account/auth/resend_verification_email` and distinguish accounts from misses.

## Details

`resend_verification_email()` looks up the submitted address and returns the lookup error to the caller:

```rust
let local_user_view = LocalUserView::find_by_email(&mut context.pool(), &email).await?;
check_local_user_valid(&local_user_view)?;
```

The password reset endpoint already uses a safer pattern. It discards lookup errors and returns success, which prevents the same account-discovery channel.

## Proof of Concept

The following script creates one user and probes that address plus a missing address.

```python
import requests, random, string

BASE = "http://127.0.0.1:8536/api/v4"  # change to the target Lemmy URL
ADMIN_USER = "lemmy"
ADMIN_PASS = "lemmylemmy"
[CREDENTIAL_REDACTED]"

def post(path, **body):
    return requests.post(BASE + path, json=body)

suffix = "enum" + "".join(random.choice(string.ascii_lowercase) for _ in range(6))
admin = post("/account/auth/login", username_or_email=ADMIN_USER, password=ADMIN_PASS).json()["jwt"]
requests.put(BASE + "/site", headers={"Authorization": "Bearer " + admin},
             json={"registration_mode": "open", "email_verification_required": False})

email = "alice" + suffix + "@example.test"
post("/account/auth/register", username="alice" + suffix, [CREDENTIAL_REDACTED],
     password_verify=PASSWORD, email=email).raise_for_status()

for candidate in [email, "missing" + suffix + "@example.test"]:
    r = post("/account/auth/resend_verification_email", email=candidate)
    print(candidate, "HTTP", r.status_code, r.text[:300])

```

Output:

```text
alicepoceudtpf@example.test HTTP 200 {"success":true}
missingpoceudtpf@example.test HTTP 404 {"error":"not_found","cause":"Record not found"}
```

## Impact

A malicious third party can enumerate registered email addresses without authentication. The endpoint uses the registration rate limit bucket, not an endpoint-specific anti-enumeration limit, so the attacker can automate probes across candidate address lists. The response also distinguishes missing accounts from banned or deleted accounts because `check_local_user_valid()` returns separate error types.

## Recommended Fix

Use the password-reset pattern for resend verification. Move the lookup and email-send work into a helper, ignore helper errors in the handler, and always return `{"success": true}` for syntactically valid input.

---
*Found by [aisafe.io](https://aisafe.io)*
GitHub Security Advisory: GHSA-qcxq-75wr-5cm8
Package: ldap3_proto (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.7.1
Patched in: 0.7.1

Summary: ldap3_proto has LDAP Filter stack exhaustion

Details:
### Impact
LDAP queries are not validated for depth, which can cause the parser (both PEG and ASN) to exhaust the stack. This *may* cause a denial of service in applications that process queries.

### Workarounds
N/A

### Resources
Related to GHSA-r5fr-9gmv-jggh
GitHub Security Advisory: GHSA-53hj-r94p-8c8f
Package: kanidm (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: <= 1.9.2
Patched in: 1.9.3

Summary: Kanidm has non-constant-time comparison of OAuth2 client_secret

Details:
### Summary

The kanidmd OAuth2 token-exchange (`/oauth2/token`) and token-introspection (`/oauth2/token/introspect`) endpoints compare the supplied `client_secret` against the stored secret using Rust's `PartialEq` on `String`, which short-circuits on the first mismatching byte. This produces an observable timing discrepancy that varies with the length of the matching prefix.

### Details

- https://github.com/kanidm/kanidm/blob/master/server/lib/src/idm/oauth2.rs#L1135 — variable-time comparison in `check_oauth2_token_exchange`
- https://cwe.mitre.org/data/definitions/208.html — CWE-208: Observable Timing Discrepancy

### PoC

Static analysis only — no timing-recovery script was run because remote recovery of a 48-byte high-entropy secret over HTTPS is not practically demonstrable. The variable-time behaviour is established by inspection:

```rust
// server/lib/src/idm/oauth2.rs:1135  (check_oauth2_token_exchange)
if authz_secret == &secret { … } else { return Err(Oauth2Error::AuthenticationRequired); }
```

`String: PartialEq` delegates to `<[u8] as PartialEq>::eq`, which checks length equality then iterates byte-by-byte and returns on the first difference.

### Impact

An unauthenticated network attacker who can reach the OAuth2 endpoints can submit arbitrary `client_id`/`client_secret` pairs and observe response latency. In principle the early-exit comparison leaks the position of the first mismatching byte, providing a timing oracle toward incremental recovery of a confidential client's secret. In practice the stored secret is a server-generated 48-character high-entropy string, the comparison runs inside an async tokio handler behind TLS, and network jitter is orders of magnitude larger than a single byte-compare — so remote recovery is not considered realistic with current techniques. This is a hardening issue rather than a practically exploitable vulnerability.

### Affected versions

All published `kanidmd_lib` releases; the comparison is still variable-time on `master` at 1.10.0-dev
GitHub Security Advisory: GHSA-gpxg-fx2g-qxj2
Package: kanidm (RUST)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.9.2
Patched in: 1.9.3

Summary: Kanidm: Stored HTML injection in "passkey-enrolment" partial via displayname → htmx-driven authenticated request forgery

Details:
### Summary

The kanidmd web UI renders the WebAuthn passkey-registration challenge as raw JSON inside an inline `<script id="data">` element using the Askama `|safe` filter. The challenge embeds the account's `displayname`, which `serde_json` serialises without escaping `<`/`>`. A `displayname` containing `</script>` therefore terminates the script element early and injects arbitrary HTML into the credential-update page. Because the page is htmx-driven and the server's CSP allows `'unsafe-eval'`, injected `hx-*` attributes can issue authenticated same-origin API requests with the viewer's bearer cookie.

### Impact

An authenticated attacker who is a member of `idm_people_admins` can write the `displayname` of any `Person` entry — including high-privilege persons — because `idm_acp_people_pii_manage` carries no high-privilege exclusion filter. When the targeted high-privilege user later opens **Add Passkey** on their own credential-update page (`/ui/reset`), the injected markup is swapped into the DOM and htmx fires attacker-chosen same-origin requests authenticated as the victim. This allows a helpdesk-tier operator to escalate to `idm_admins` (e.g. by POSTing themselves into the group) or otherwise act with the victim's session. The self-write path (`idm_people_self_name_write`) is self-XSS only and is not counted toward impact. Even without the htmx vector, the breakout permits `<meta http-equiv='refresh'>` open-redirect and arbitrary defacement of the credential page.

### Details

- https://github.com/kanidm/kanidm/blob/master/server/core/templates/credential_update_add_passkey_partial.html#L3 — the `|safe` sink
- https://github.com/kanidm/kanidm/blob/master/server/core/src/https/views/reset.rs#L506-L509 — `serde_json::to_string` of the challenge
- https://github.com/kanidm/kanidm/blob/master/server/lib/src/idm/credupdatesession.rs#L2453-L2460 — `displayname` flows into `start_passkey_registration`

### Affected versions

All releases shipping the htmx credential-update views
GitHub Security Advisory: GHSA-2p6r-x3vv-xqm2
Package: rpassword (RUST)
Severity: LOW (CVSS 3.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: <= 7.4.0
Patched in: 7.5.0

Summary: rpassword affected by partial password reveal when input is interrupted 

Details:
rpassword maintainers were made aware of a possible issue with a partial password reveal when input is interrupted.

To quote @squell:

> @conradkleinespel I've confirmed this problem with SequoiaPGP, which I think uses rpassword, e.g.:
>
> Suppose we use pkill -9 sq in a different terminal right after the password has been typed in:
>
> $ sq key generate --userid "barf" --with-password
> Enter password to protect the key: Killed
> $ hello^C
>
> Where the password I typed in is "hello".

This has been fixed in version v7.5.0 and above.
GitHub Security Advisory: GHSA-xx64-wwv2-hcqq
Package: astral-tokio-tar (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 0.6.0
Patched in: 0.6.1

Summary: astral-tokio-tar: `unpack_in` can chmod arbitrary directories by following symlinks

Details:
### Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the `unpack_in` API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the `tar` crate.

### Patches

Versions 0.6.1 and newer of astral-tokio-tar use `fs::symlink_metdata` rather than `fs::metadata`, avoiding the traversal. 

### Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

### Resources

- GHSA-j4xf-2g29-59ph for the original `tar` vulnerability

### Attribution

- Reporter: Adam Harvey (@lawngnome)