deardaniel/secdata-raw huggingface dataset:
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: < 1.61.12
Patched in: 1.61.12

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.
GitHub Security Advisory: GHSA-g8jh-vg5j-4h3f
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 2.0.0-alpha.0, < 2.8.1
Patched in: 2.8.1

Summary: Apollo Router Improperly Enforces Renamed Access Control Directives

Details:
# Summary 
A vulnerability in Apollo Router allowed for unauthorized access to protected data through schema elements with access control directives (`@authenticated`, `@requiresScopes`, and `@policy`) that were renamed via `@link` imports. Router did not enforce renamed access control directives on schema elements (e.g. fields and types), allowing queries to bypass those element-level access controls.

## 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 schema data access at the element level. These directives can optionally be renamed via the [`imports` argument to the `@link` directive](https://www.apollographql.com/docs/graphos/schema-design/federated-schemas/reference/directives#renaming-directives), which can be useful if their default names match an existing user-defined directive in their subgraph schema. However, Apollo Router's access control logic ignored the `imports` argument, and would accordingly ignore access control directives that were renamed in this way.

## Who Is Impacted

This vulnerability impacts Apollo Router customers defining `@authenticated`, `@requiresScopes`, or `@policy` directives on schema elements that were renamed via `@link` imports are impacted.

### Scope of Impact

The vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on schema elements protected by renamed access control directives.

## Patches

This vulnerability has been fixed in Apollo Router by updating the access control logic to handle the `imports` argument in `@link` directives. You will need to 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 remove any renames of access control directives in the `imports` argument to the `@link` directive.
- Customers not using Apollo Router with renamed access control directives (`@authenticated`, `@requiresScopes`, and `@policy`) are not affected and do not need to take action.
GitHub Security Advisory: GHSA-g8jh-vg5j-4h3f
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.61.12
Patched in: 1.61.12

Summary: Apollo Router Improperly Enforces Renamed Access Control Directives

Details:
# Summary 
A vulnerability in Apollo Router allowed for unauthorized access to protected data through schema elements with access control directives (`@authenticated`, `@requiresScopes`, and `@policy`) that were renamed via `@link` imports. Router did not enforce renamed access control directives on schema elements (e.g. fields and types), allowing queries to bypass those element-level access controls.

## 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 schema data access at the element level. These directives can optionally be renamed via the [`imports` argument to the `@link` directive](https://www.apollographql.com/docs/graphos/schema-design/federated-schemas/reference/directives#renaming-directives), which can be useful if their default names match an existing user-defined directive in their subgraph schema. However, Apollo Router's access control logic ignored the `imports` argument, and would accordingly ignore access control directives that were renamed in this way.

## Who Is Impacted

This vulnerability impacts Apollo Router customers defining `@authenticated`, `@requiresScopes`, or `@policy` directives on schema elements that were renamed via `@link` imports are impacted.

### Scope of Impact

The vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on schema elements protected by renamed access control directives.

## Patches

This vulnerability has been fixed in Apollo Router by updating the access control logic to handle the `imports` argument in `@link` directives. You will need to 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 remove any renames of access control directives in the `imports` argument to the `@link` directive.
- Customers not using Apollo Router with renamed access control directives (`@authenticated`, `@requiresScopes`, and `@policy`) are not affected and do not need to take action.
GitHub Security Advisory: GHSA-vf95-55w6-qmrf
Package: youki (RUST)
Severity: HIGH (CVSS 10.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following, CWE-363: Race Condition Enabling Link Following
Vulnerable versions: < 0.5.7
Patched in: 0.5.7

Summary: youki container escape and denial of service due to arbitrary write gadgets and procfs write redirects

Details:
### Impact ###

youki’s apparmor handling performs insufficiently strict write-target validation, which—combined with path substitution during pathname resolution—can allow writes to unintended procfs locations.

**Weak write-target check**
youki only verifies that the destination lies somewhere under procfs. As a result, a write intended for `/proc/self/attr/apparmor/exec` can succeed even if the path has been redirected to `/proc/sys/kernel/hostname`(which is also in procfs).

**Path substitution**
While resolving a path component-by-component, a shared-mount race can substitute intermediate components and redirect the final target.

This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems.
https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm

### Credits ###

Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering runc's original vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.
GitHub Security Advisory: GHSA-4g74-7cff-xcv8
Package: youki (RUST)
Severity: HIGH (CVSS 10.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following, CWE-363: Race Condition Enabling Link Following
Vulnerable versions: < 0.5.7
Patched in: 0.5.7

Summary: youki container escape via "masked path" abuse due to mount race conditions

Details:
### Impact ###

youki utilizes bind mounting the container's `/dev/null` as a file mask. When performing this operation, the initial validation of the source `/dev/null` was insufficient. Specifically, we initially failed to verify whether `/dev/null` was genuinely present. However, we did perform validation to ensure that the `/dev/null` path existed within the container, including checking for symbolic links. Additionally, there was a vulnerability in the timing between validation and the actual mount operation.

As a result, by replacing `/dev/null` with a symbolic link, we can bind-mount arbitrary files from the host system.

This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems.
https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2

### Credits

Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original runc's vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector in runc (Attack 2) based on @ssst0n3's initial findings.

Also, @cyphar helped youki in finding the problem.
GitHub Security Advisory: GHSA-7vjm-6qgq-3mrq
Package: shaman (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: Shaman has soundness issues and is unmaintained

Details:
`shaman::cryptoutil::write_u64v_le` and other functions mentioned above cannot garantee memory safety of get_unchecked later if both length are zero.

`shaman` is unmaintained.
GitHub Security Advisory: GHSA-wwxp-hxh6-8gf8
Package: binary_vec_io (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: <= 0.1.12
Patched in: unpatched

Summary: binary_vec_io access memory out-of-bounds in binary_read_to_ref and binary_write_from_ref

Details:
Safe functions accept a single `&T` or `&mut T` but multiply by `n` to create slices extending beyond allocated memory when `n > 1`.

These functions use `from_raw_parts` to create slices larger than the underlying allocation, violating memory safety.

The binary_vec_io repository is archived and unmaintained.
GitHub Security Advisory: GHSA-x77x-7mmh-cxv3
Package: ncurses (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: <= 6.0.1
Patched in: unpatched

Summary: ncurses exposes uninitialized memory in string reading functions

Details:
Multiple string reading functions expose uninitialized memory by setting length to capacity when no null terminator is found.

This allows reading uninitialized memory which may contain sensitive data from previous allocations.

The ncurses-rs repository is archived and unmaintained.
GitHub Security Advisory: GHSA-xcpm-76hf-c9cc
Package: borrowck_sacrifices (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-824: Access of Uninitialized Pointer
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Borrowck Scarifices exposes uninitialized memory in any_as_u8_slice

Details:
The safe function `any_as_u8_slice` can create byte slices that reference uninitialized memory when used with types containing padding bytes.

The function uses `slice::from_raw_parts` to create a `&[u8]` covering the entire size of a type, including padding bytes. According to Rust's documentation, `from_raw_parts` requires all bytes to be properly initialized, but padding bytes in structs are not guaranteed to be initialized. This violates the safety contract and causes undefined behavior.
GitHub Security Advisory: GHSA-fp5x-7m4q-449f
Package: direct_ring_buffer (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 0.2.2
Patched in: 0.2.2

Summary: Direct Ring Buffer has uninitialized memory exposure in create_ring_buffer

Details:
The safe function `create_ring_buffer` allocates a buffer using `Vec::with_capacity` followed by `set_len`, creating a `Box<[T]>` containing uninitialized memory.

This leads to undefined behavior when functions like `write_slices` create typed slices (e.g., `&mut [bool]`) over the uninitialized memory, violating Rust's validity invariants. The issue has been confirmed using Miri.

Fixed in version 0.2.2 by using `resize_with` to properly initialize the buffer with `T::default()`, adding a `T: Default` bound to ensure sound initialization.
GitHub Security Advisory: GHSA-h5j3-crg5-8jqm
Package: orx-pinned-vec (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-191: Integer Underflow (Wrap or Wraparound)
Vulnerable versions: < 3.21.0
Patched in: 3.21.0

Summary: orx-pinned-vec has undefined behavior in index_of_ptr with empty slices

Details:
The safe function `index_of_ptr` causes undefined behavior when called with an empty slice.

The issue occurs in the line `ptr.add(slice.len() - 1)` which underflows when `slice.len()` is 0, creating a pointer with a massive offset. According to Rust's safety rules, creating such a pointer causes immediate undefined behavior.
GitHub Security Advisory: GHSA-pgp9-98jm-wwq2
Package: alloy-dyn-abi (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-248: Uncaught Exception
Vulnerable versions: >= 1.0.0, < 1.4.1
Patched in: 1.4.1

Summary: alloy-dyn-abi has DoS vulnerability on `alloy_dyn_abi::TypedData` hashing

Details:
### Impact

An uncaught panic triggered by malformed input to `alloy_dyn_abi::TypedData` could lead to a denial-of-service (DoS) via `eip712_signing_hash()`.

Software with high availability requirements such as network services may be particularly impacted. If in use, external auto-restarting mechanisms can partially mitigate the availability issues unless repeated attacks are possible.

### Patches

The vulnerability was patched by adding a check to ensure the element is not empty before accessing its first element; an error is returned if it is empty. The fix is included in version [`v1.4.1`](https://crates.io/crates/alloy-dyn-abi/1.4.1) and backported to [`v0.8.26`](https://crates.io/crates/alloy-dyn-abi/0.8.26).

### Workarounds

There is no known workaround that mitigates the vulnerability. Upgrading to a patched version is the recommended course of action.

### Reported by

Christian Reitter & Zeke Mostov from [Turnkey](https://www.turnkey.com/)
GitHub Security Advisory: GHSA-pgp9-98jm-wwq2
Package: alloy-dyn-abi (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-248: Uncaught Exception
Vulnerable versions: < 0.8.26
Patched in: 0.8.26

Summary: alloy-dyn-abi has DoS vulnerability on `alloy_dyn_abi::TypedData` hashing

Details:
### Impact

An uncaught panic triggered by malformed input to `alloy_dyn_abi::TypedData` could lead to a denial-of-service (DoS) via `eip712_signing_hash()`.

Software with high availability requirements such as network services may be particularly impacted. If in use, external auto-restarting mechanisms can partially mitigate the availability issues unless repeated attacks are possible.

### Patches

The vulnerability was patched by adding a check to ensure the element is not empty before accessing its first element; an error is returned if it is empty. The fix is included in version [`v1.4.1`](https://crates.io/crates/alloy-dyn-abi/1.4.1) and backported to [`v0.8.26`](https://crates.io/crates/alloy-dyn-abi/0.8.26).

### Workarounds

There is no known workaround that mitigates the vulnerability. Upgrading to a patched version is the recommended course of action.

### Reported by

Christian Reitter & Zeke Mostov from [Turnkey](https://www.turnkey.com/)
GitHub Security Advisory: GHSA-3p6w-gv5g-xjw9
Package: mongodb (RUST)
Severity: HIGH (CVSS 8.0)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 3.2.5
Patched in: 3.2.5

Summary: MongoDB Rust Driver has certificate validation disabled when `tlsInsecure=False` appears in connection string

Details:
When tlsInsecure=False appears in a connection string, certificate validation is disabled.

This vulnerability affects MongoDB Rust Driver versions prior to v3.2.5.
GitHub Security Advisory: GHSA-6fgx-x7m2-74qm
Package: tracexec (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: < 0.14.0
Patched in: 0.14.0

Summary: tracexec has `env` command argument injection via environment variables starting with dash in traced exec events

Details:
### Impact

For tracexec's command line reconstruction feature, when a traced process executes another process with a environment variable where the key starts with a dash, tracexec incorrectly shows its commandline where such environment variables could cause argument injection for the `env` command.
Such an injection is completely at the UI level unless the user tries to copy the command line with the injection and paste it into a terminal to execute it.

A minimal POC is executing `env -- -a=b bash --norc` in tracexec's TUI mode. The resulting command line of `env` executing bash would be `env -a bash -a=b  _=/usr/bin/env /usr/bin/bash --norc` in tracexec's TUI, which injects `-a=b` into `env`'s arguments.

This has very limited effect for security.  A local adversarial could leverage this to make tracexec show an inaccurate reconstructed commandline for their executed command. If the user of tracexec decides to copy and run the reconstructed commandline,
there could be injection for `env`'s `--block-signal`, `--default-signal`, `--ignore-signal`, `--split-string`, `--unset`, `--chdir`, `--argv0` arguments.

### Patches
The fix is https://github.com/kxxt/tracexec/pull/118. Users are advised to upgrade to 0.14.0.

### Workarounds

Don't blindly paste and execute commands copied from tracexec that contains environment variable where the key starts with a dash.
GitHub Security Advisory: GHSA-m2gf-x3f6-8hq3
Package: deno (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 2.5.2
Patched in: 2.5.2

Summary: Deno is Vulnerable to Command Injection on Windows During Batch File Execution

Details:
### Summary
Deno versions up to 2.5.1 are vulnerable to Command Line Injection attacks on Windows when batch files are executed.

### Details
In Windows, ``CreateProcess()`` always implicitly spawns ``cmd.exe`` if a batch file (.bat, .cmd, etc.) is being executed even if the application does not specify it via the command line. This makes Deno vulnerable to a command injection attack on Windows as demonstrated by the two proves-of-concept below.

### PoC
Using `node:child_process` (with the `env` and `run` permissions):
```JS
const { spawn } = require('node:child_process');
const child = spawn('./test.bat', ['&calc.exe']);
```
Using `Deno.Command.spawn()` (with the `run` permission):
```JS
const command = new Deno.Command('./test.bat', {
  args: ['&calc.exe'],
});
const child = command.spawn();
```

### Impact
Both of these scripts result in opening calc.exe on Windows, thus allowing a Command Line Injection attack when user-provided arguments are passed if the script being executed by the child process is a batch script.
GitHub Security Advisory: GHSA-2pgj-5cv2-6xxw
Package: fuel-vm (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.60.0, < 0.60.1
Patched in: 0.60.1

Summary: FuelVM is vulnerable to heap memory allocation re-use bug

Details:
### Impact

A memory safety vulnerability was present in the Fuel Virtual Machine (FuelVM), where memory reads could bypass expected access controls. Specifically, when a smart contract performed a `mload` (or other opcodes which access memory) on memory that had been deallocated using `ret`, it was still able to access the old memory contents. This occurred because the memory region was not zeroed out or otherwise marked as invalid. As a result, smart contracts could potentially read sensitive data left over from other contracts if the same memory was reallocated, violating isolation guarantees between contracts and enabling unintended data leakage.

All users running affected versions of FuelVM that relied on strict memory isolation between smart contracts were impacted.

### Patches

The vulnerability was patched by modifying the FuelVM to ensure that memory deallocated with `ret` was zeroed out or made inaccessible. The fix was included in FuelVM version `v0.60.1` and back-ported to `v0.59.3`. This patch was released to the Fuel network on Friday, April 18th, 2025.

### Workarounds

There were no reliable workarounds that fully mitigated the vulnerability. While developers could manually zero out sensitive memory regions before returning from a function, this approach was error-prone and could not be enforced at the VM level. Upgrading to a patched version remained the recommended course of action.

### References

- Fix implemented in the FuelVM GitHub repository (https://github.com/FuelLabs/fuel-vm/pull/941)