deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g4v2-cjqp-rfmq
Package: wasmi (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 1.0.0, < 1.0.1
Patched in: 1.0.1

Summary: Critical Use-After-Free in Wasmi's Linear Memory

Details:
### Summary

A use-after-free vulnerability has been discovered in the linear memory implementation of Wasmi. This issue can be triggered by a WebAssembly module under certain memory growth conditions, potentially leading to memory corruption, information disclosure, or code execution.

### Impact

- **Confidentiality:** High – attacker-controlled memory reads possible.
- **Integrity:** High – memory corruption may allow arbitrary writes.
- **Availability:** High – interpreter crashes possible.

### Affected Versions

Wasmi `v0.41.0` through Wasmi `v1.0.0`.

### Workarounds

- Upgrade to the latest patched version of Wasmi.
- Consider limiting the maximum linear memory sizes where feasible.

### Credits

This vulnerability was discovered by **Robert T. Morris (RTM)**.
GitHub Security Advisory: GHSA-g4v2-cjqp-rfmq
Package: wasmi (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.50.0, < 0.51.3
Patched in: 0.51.3

Summary: Critical Use-After-Free in Wasmi's Linear Memory

Details:
### Summary

A use-after-free vulnerability has been discovered in the linear memory implementation of Wasmi. This issue can be triggered by a WebAssembly module under certain memory growth conditions, potentially leading to memory corruption, information disclosure, or code execution.

### Impact

- **Confidentiality:** High – attacker-controlled memory reads possible.
- **Integrity:** High – memory corruption may allow arbitrary writes.
- **Availability:** High – interpreter crashes possible.

### Affected Versions

Wasmi `v0.41.0` through Wasmi `v1.0.0`.

### Workarounds

- Upgrade to the latest patched version of Wasmi.
- Consider limiting the maximum linear memory sizes where feasible.

### Credits

This vulnerability was discovered by **Robert T. Morris (RTM)**.
GitHub Security Advisory: GHSA-g4v2-cjqp-rfmq
Package: wasmi (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.42.0, < 0.47.1
Patched in: 0.47.1

Summary: Critical Use-After-Free in Wasmi's Linear Memory

Details:
### Summary

A use-after-free vulnerability has been discovered in the linear memory implementation of Wasmi. This issue can be triggered by a WebAssembly module under certain memory growth conditions, potentially leading to memory corruption, information disclosure, or code execution.

### Impact

- **Confidentiality:** High – attacker-controlled memory reads possible.
- **Integrity:** High – memory corruption may allow arbitrary writes.
- **Availability:** High – interpreter crashes possible.

### Affected Versions

Wasmi `v0.41.0` through Wasmi `v1.0.0`.

### Workarounds

- Upgrade to the latest patched version of Wasmi.
- Consider limiting the maximum linear memory sizes where feasible.

### Credits

This vulnerability was discovered by **Robert T. Morris (RTM)**.
GitHub Security Advisory: GHSA-g4v2-cjqp-rfmq
Package: wasmi (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.41.0, < 0.41.2
Patched in: 0.41.2

Summary: Critical Use-After-Free in Wasmi's Linear Memory

Details:
### Summary

A use-after-free vulnerability has been discovered in the linear memory implementation of Wasmi. This issue can be triggered by a WebAssembly module under certain memory growth conditions, potentially leading to memory corruption, information disclosure, or code execution.

### Impact

- **Confidentiality:** High – attacker-controlled memory reads possible.
- **Integrity:** High – memory corruption may allow arbitrary writes.
- **Availability:** High – interpreter crashes possible.

### Affected Versions

Wasmi `v0.41.0` through Wasmi `v1.0.0`.

### Workarounds

- Upgrade to the latest patched version of Wasmi.
- Consider limiting the maximum linear memory sizes where feasible.

### Credits

This vulnerability was discovered by **Robert T. Morris (RTM)**.
GitHub Security Advisory: GHSA-jj6p-3m75-g2p3
Package: matrix-sdk-base (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: < 0.16.0
Patched in: 0.16.0

Summary:  matrix-sdk-base denial of service via custom m.room.join_rules event values

Details:
The matrix-sdk-base crate is unable to handle responses that include custom m.room.join_rules values due to a serialization bug.

This can be exploited to cause a denial-of-service condition, if a user is invited to a room with non-standard join rules, the crate's sync process will stall, preventing further processing for all rooms.

### Patches
The issue is fixed in matrix-sdk-base 0.16.0.

### Workarounds

Users can leave affected rooms on another client to mitigate the issue.

### References

The issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/5924.
GitHub Security Advisory: GHSA-xrv8-2pf5-f3q7
Package: nitro-tpm-pcr-compute (RUST)
Severity: MODERATE (CVSS 6.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: nitro-tpm-pcr-compute may allow kernel command line modification by an account operator

Details:
## Summary

Adding default PCR12 validation to ensure that account operators can not modify kernel command line parameters, potentially bypassing root filesystem integrity validation.

Attestable AMIs are based on the systemd Unified Kernel Image (UKI) concept which uses systemd-boot to create a single measured UEFI binary from a Linux kernel, its initramfs, and kernel command line. The embedded kernel command line contains a dm-verity hash value that establishes trust in the root file system.

When UEFI Secure Boot is disabled, systemd-boot appends any command line it receives to the kernel command line. Account operators with the ability to modify UefiData can install a boot variable with a command line that deactivates root file system integrity validation, while preserving the original PCR4 value.

Systemd-boot provides separate measurement of command line modifications in PCR12.

## Impact

In line with the TPM 2.0 specification and systemd-stub logic, KMS policies that do not include validation for PCR12 (command line measurement) or PCR7 (enabled Secure Boot) may allow kernel command line modification by an account operator.

## Patches 

Version 1.1.0 of nitro-tpm-pcr-compute has been updated to include PCR12 with a static zero value. The updated tool now outputs PCR12 in the JSON measurements:

```json
{
  "Measurements": {
    "HashAlgorithm": "SHA384",
    "PCR4": "<hex string>",
    "PCR7": "<hex string>",
    "PCR12": "[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000000"
  }
}
```

## Workarounds

For users who cannot upgrade to version 1.1.0 of nitro-tpm-pcr-compute immediately, the following workarounds are available:

1. **Manually add PCR12 to KMS policies:** Add PCR12 with a static zero value to your AWS KMS key policies:

```txt
kms:RecipientAttestation:NitroTPMPCR12:[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000000
```

2. **Enable and validate UEFI Secure Boot:** Configure your Attestable AMI to use UEFI Secure Boot and validate its enablement via PCR7 in your KMS policy. When UEFI Secure Boot is active, the command line cannot be overwritten.
GitHub Security Advisory: GHSA-2cgv-28vr-rv6j
Package: libcrux-intrinsics (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: = 0.0.3
Patched in: 0.0.4

Summary: libcrux incorrectly calculates on aarch64

Details:
On platforms without the `core::arch::aarch64::vxarq_u64` intrinsic, an unverified fallback in `libcrux-intrinsics` v0.0.3
passed incorrect arguments and produced wrong results. This corrupted SHA-3 digests and caused `libcrux-ml-kem` and
`libcrux-ml-dsa` to sample incorrectly, yielding incorrect shared secrets and invalid signatures.

The issue has been fixed in v0.0.4.
GitHub Security Advisory: GHSA-mj73-j457-8x9q
Package: maxminddb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: >= 0.11.0, < 0.27.0
Patched in: 0.27.0

Summary: maxminddb's `Reader::open_mmap` unsoundly marks unsafe memmap operation as safe

Details:
maxminddb prior to version 0.27 declared `Reader::open_mmap` as safe despite wrapping an inherently unsafe memmap2 operation with no extra step done to guarantee safety. This could have led to undefined behaviour if the file were to be modified on disk while the memory map was still active.
GitHub Security Advisory: GHSA-pq5v-rwp8-p7gm
Package: rtvm-interpreter (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-475: Undefined Behavior for Input to API
Vulnerable versions: <= 4.0.0
Patched in: unpatched

Summary:  rtvm-interpreter lacks sufficient checks in public API

Details:
The affected function is unsound due to insufficient checks on public struct field.
GitHub Security Advisory: GHSA-2fjw-whxm-9v4q
Package: nftnl (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: <= 0.8.0
Patched in: 0.9.0

Summary: libnftnl has Heap-based Buffer Overflow in nftnl::Batch::with_page_size (nftnl-rs)

Details:
A heap-buffer-overflow vulnerability exists in the Rust wrapper for libnftnl, triggered via the nftnl::Batch::with_page_size constructor. When a small or malformed page size is provided, the underlying C code allocates an insufficient buffer, leading to out-of-bounds writes during batch initialization.

The flaw was fixed in commit 94a286f by adding an overflow check:
```Rust
batch_page_size
    .checked_add(crate::nft_nlmsg_maxsize())
    .expect("batch_page_size is too large and would overflow");
```
GitHub Security Advisory: GHSA-8frv-q972-9rq5
Package: cggmp24 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 0.7.0-alpha.2
Patched in: 0.7.0-alpha.2

Summary: cggmp24 and cggmp21 are vulnerable to signature forgery through altered presignatures

Details:
### Impact
This attack is against presignatures used in very specific context:
* Presignatures + HD wallets derivation: security level reduces to 85 bits \
  Previously users could generate a presignature, and then choose a HD derivation path while issuing a partial signature via [`Presignature::set_derivation_path`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.set_derivation_path), which is malleable to attack that reduces target security level. To mitigate, this method has been removed from API.
* Presignatures + "raw signing" (when signer signs a hash without knowing an original message): results into signature forgery attack \
  Previously, users were able to configure [`Presignature::issue_partial_signature`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.issue_partial_signature) with hashed message without ever providing original mesage. In new API, this method only accepts digests for which original message has been observed.

### Patches
`cggmp24 v0.7.0-alpha.2` release contains API changes that make it impossible to use presignatures in contexts in which it reduces security. Follow [migration guidelines](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### Workarounds
Users can continue using un-patched versions of library as long as they don't use presignatures in said scenarios where it weakens system security. To be sure, migrate to patched version that excludes presignatures from being used in such scenarios.

### References
Read this [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.
GitHub Security Advisory: GHSA-8frv-q972-9rq5
Package: cggmp21 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: <= 0.6.3
Patched in: unpatched

Summary: cggmp24 and cggmp21 are vulnerable to signature forgery through altered presignatures

Details:
### Impact
This attack is against presignatures used in very specific context:
* Presignatures + HD wallets derivation: security level reduces to 85 bits \
  Previously users could generate a presignature, and then choose a HD derivation path while issuing a partial signature via [`Presignature::set_derivation_path`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.set_derivation_path), which is malleable to attack that reduces target security level. To mitigate, this method has been removed from API.
* Presignatures + "raw signing" (when signer signs a hash without knowing an original message): results into signature forgery attack \
  Previously, users were able to configure [`Presignature::issue_partial_signature`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.issue_partial_signature) with hashed message without ever providing original mesage. In new API, this method only accepts digests for which original message has been observed.

### Patches
`cggmp24 v0.7.0-alpha.2` release contains API changes that make it impossible to use presignatures in contexts in which it reduces security. Follow [migration guidelines](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### Workarounds
Users can continue using un-patched versions of library as long as they don't use presignatures in said scenarios where it weakens system security. To be sure, migrate to patched version that excludes presignatures from being used in such scenarios.

### References
Read this [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.
GitHub Security Advisory: GHSA-m95p-425x-x889
Package: cggmp24 (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.7.0-alpha.2
Patched in: 0.7.0-alpha.2

Summary: cggmp21 has a missing check in the ZK proof used in CGGMP21

Details:
### Impact
cggmp21  concerns a missing check in the ZK proof that enables an attack in which a single malicious signer can reconstruct full private key.

### Patches
* `cggmp21 v0.6.3` is a patch release that contains a fix that introduces this specific missing check
* However, cggmp21 recommends upgrading to `cggmp24 v0.7.0-alpha.2` which contains many other security checks as a precaution. Follow [migration guideline](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### Workarounds
Update to `cggmp21 v0.6.3`, a minor release that contains a minimal security patch.

However, for full mitigation, users will need to upgrade to `cggmp24 v0.7.0-alpha.2` as it contains many more security check implementations.

### Resources
Read this [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.
GitHub Security Advisory: GHSA-m95p-425x-x889
Package: cggmp21 (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.6.3
Patched in: 0.6.3

Summary: cggmp21 has a missing check in the ZK proof used in CGGMP21

Details:
### Impact
cggmp21  concerns a missing check in the ZK proof that enables an attack in which a single malicious signer can reconstruct full private key.

### Patches
* `cggmp21 v0.6.3` is a patch release that contains a fix that introduces this specific missing check
* However, cggmp21 recommends upgrading to `cggmp24 v0.7.0-alpha.2` which contains many other security checks as a precaution. Follow [migration guideline](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### Workarounds
Update to `cggmp21 v0.6.3`, a minor release that contains a minimal security patch.

However, for full mitigation, users will need to upgrade to `cggmp24 v0.7.0-alpha.2` as it contains many more security check implementations.

### Resources
Read this [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.
GitHub Security Advisory: GHSA-jf9p-2fv9-2jp2
Package: thread-amount (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-772: Missing Release of Resource after Effective Lifetime
Vulnerable versions: < 0.2.2
Patched in: 0.2.2

Summary: thread-amount Vulnerable to Resource Exhaustion (Memory and Handle Leaks) on Windows and macOS

Details:
Affected versions of this crate contain resource leaks when querying thread counts on Windows and Apple platforms.

### Windows
The `thread_amount` function calls `CreateToolhelp32Snapshot` but fails to close the returned `HANDLE` using `CloseHandle`. Repeated calls to this function will cause the handle count of the process to grow indefinitely, eventually leading to system instability or process termination when the handle limit is reached.

### macOS / iOS
The `thread_amount` function calls `task_threads` (via Mach kernel APIs) which allocates memory for the thread list. The function fails to deallocate this memory using `vm_deallocate`. Repeated calls will result in a steady memory leak, eventually causing the process to be killed by the OOM (Out of Memory) killer.

### Impact
Long-running applications (such as servers, daemons, or monitoring tools) that use this crate to periodically check thread counts will eventually crash due to resource exhaustion.

### Resources

- https://github.com/jzeuzs/thread-amount/pull/29
GitHub Security Advisory: GHSA-q428-6v73-fc4q
Package: sudo-rs (RUST)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 0.2.5, < 0.2.10
Patched in: 0.2.10

Summary: sudo-rs doesn't record authenticating user properly in timestamp

Details:
### Summary
When `Defaults targetpw` (or `Defaults rootpw`) is enabled, the password of the target account (or root account) instead of the invoking user is used for authentication. `sudo-rs` prior to 0.2.10 incorrectly recorded the invoking user’s UID instead of the authenticated-as user's UID in the authentication timestamp. Any later `sudo` invocation on the same terminal while the timestamp was still valid would use that timestamp, potentially bypassing new authentication even if the policy would have required it.

### Impact
A highly-privileged user (able to run commands as other users, or as root, through sudo) who knows one password of an account they are allowed to run commands as, would be able to run commands as any other account the policy permits them to run commands for, even if they don't know the password for those accounts.

A common instance of this would be that a user can still use their own password to run commands as root (the default behaviour of `sudo`), effectively negating the intended behaviour of the `targetpw` or `rootpw` options.

### Example

With this in /etc/sudoers:
```
Defaults targetpw
user ALL=(ALL:ALL) ALL
```
First run:
```
user@machine$ sudo -g root whoami
[sudo: authenticate] Password: <password for user>
user
```
Then run:
```
user@machine$ sudo -u root whoami
root
```

### Affected versions

sudo-rs prior to 0.2.5 are not affected, since they do not offer `Defaults targetpw` or `Defaults rootpw`.

### Credits

This issue was discovered and reported by @Pingasmaster.
GitHub Security Advisory: GHSA-c978-wq47-pvvw
Package: sudo-rs (RUST)
Severity: LOW (CVSS 3.8)
CWE: CWE-549: Missing Password Field Masking
Vulnerable versions: >= 0.2.7, < 0.2.10
Patched in: 0.2.10

Summary: sudo-rs: Partial password reveal is possible after timeout

Details:
### Summary
If a user begins entering a password but does not press return for an extended period, a password timeout may occur. When this happens, the keystrokes that were entered are echoed back to the console.

### Example
Using sudo-rs:
```
geiger@cerberus:~$ sudo -s
[sudo: authenticate] Password: sudo-rs: timed out
geiger@cerberus:~$ testtesttest
```

"testtesttest" was entered at the password prompt but not confirmed by pressing return and then waiting for the timeout.

### Impact
This could reveal partial password information, possibly exposing history files when not carefully handled by the user and on screen, usable for Social Engineering or Pass-By attacks.

### Versions affected
Passwords timeouts were added in sudo-rs 0.2.7 (with a default set to 5 minutes).

### Credits
This issue was discovered and reported by @DevLaTron.
GitHub Security Advisory: GHSA-x33c-7c2v-mrj9
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 2.0.0-alpha.0, < 2.8.1
Patched in: 2.8.1

Summary: Apollo Router Affected by an Access Control Bypass on Polymorphic Types

Details:
# Summary

A vulnerability in Apollo Router allowed for unauthenticated queries to access data that required additional access controls. Router incorrectly handled access control directives on interface types/fields and their implementing object types/fields, applying them to interface types/fields while ignoring directives on their implementing object types/fields when all implementations had the same requirements.

## Details

Apollo Federation allows users to specify access control directives ([`@authenticated`, `@requiresScopes`, and `@policy`](https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives)) to protect object and interface types and fields. However, the GraphQL specification does not define inheritance rules for directives from interfaces to their implementations. Apollo Router will enforce any directives on the interface types/fields but ignore any directives on the implementation object types/fields (as long as all implementations have the same requirements). This inconsistent enforcement behavior leads to unexpected runtime security gaps.

## Who is impacted

This vulnerability impacts Apollo Router customers defining `@authenticated`, `@requiresScopes`, or `@policy` directives inconsistently on polymorphic types (i.e., object types that implement interface types).  Specifically, if the same access control directives are applied to all implementing types/fields but not on their implemented interface types/fields, they could be impacted.

### Scope of Impact

This vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on the object types/fields by instead querying them via implemented interface types/fields that don't have the same access control requirements.

## Patches

This vulnerability has been fixed at runtime in Apollo Router. You may update Router to one of the following versions:

- 1.61.12+
- 2.8.1+

## Workarounds

- If you are not immediately updating Router to a patched version, you should apply any included access control requirements to *both* the appropriate interface types/fields and their implementations.
- Customers not using Apollo Router access control features (`@authenticated`, `@requiresScopes`, or `@policy` directives) or not specifying inconsistent access control requirements on polymorphic types/fields are not affected and do not need to take action.