deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-x5m4-43jf-hh65
Package: soroban-fixed-point-math (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: = 1.4.0
Patched in: 1.4.1

Summary: soroban-fixed-point-math has Incorrect Rounding and Overflow Handling in Signed Fixed-Point Math with Negatives

Details:
### Impact

#### Incorrect rounding direction for signed mul and div operations

The `mulDiv(x, y, z)` function incorrectly handled cases where both the intermediate product $x * y$ and the divisor $z$ were negative. The logic assumed that if the intermediate product was negative, the final result must also be negative, neglecting the sign of $z$.

This resulted in rounding being applied in the wrong direction for cases where both $x * y$ and $z$ were negative. The functions most at risk are `fixed_div_floor` and `fixed_div_ceil`, as they often use non-constant numbers as the divisor $z$ in `mulDiv`. 

This error is present in all signed `FixedPoint` and `SorobanFixedPoint` implementations, including `i64`, `i128`, and `I256`.

#### Negative Overflow in `i64`

The `mulDiv(x, y, z)` function for `i64` used the `i128` type to handle "phantom overflows". These are overflows that occur intermediately during a calculation, like when computing the intermediate product $x * y$. When the final result of `mulDiv` was computed in `i128`, it was scaled back down to `i64` before returning. While the code verified that the result did not exceed `i64::MAX`, it did not check against `i64::MIN`.

This caused negative results smaller than `i64:MIN` to wrap around to a large positive number instead of being caught as an overflow.

This error only exists for the `FixedPoint` implementation of `i64`. 

### Patches

* v1.3.0 users should upgrade to patch v1.3.1
* v1.4.0 users should upgrade to patch v1.4.1

All versions `>=v1.4.1` contain the patch. 

### Workarounds
There are no known workarounds. Upgrade to the patched version.

### Credits

soroban-fixed-point-math would like to thank the team at [Certora](https://www.certora.com/) for discovering and reporting the issue.
GitHub Security Advisory: GHSA-5w5r-mf82-595p
Package: capnp (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Vulnerable versions: < 0.24.0
Patched in: 0.24.0

Summary: Cap'n Proto has Undefined Behavior in constant::Reader and StructSchema

Details:
The safe API functions `constant::Reader::get` and `StructSchema::new` rely on `PointerReader::get_root_unchecked`, which can cause undefined behavior (UB) by constructing arbitrary words or schemas.

## `Reader::get`

```rust
pub fn get(&self) -> Result<<T as Owned>::Reader<'static>> {
    // ...
    // UNSAFE: access `words` without validation
}
```

## `StructSchema::new`

```rust
pub fn new(builder: RawBrandedStructSchema) -> StructSchema {
    // ...
    // UNSAFE: access encoded nodes without validation
}
```

This vulnerability allows safe Rust code to trigger UB, which violates Rust's safety guarantees.

The issue is resolved in version `0.24.0` by making constructor functions unsafe and mark the fields of struct as visible only in the crate.
GitHub Security Advisory: GHSA-8rgq-m2pm-jvmg
Package: gix-date (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: Duplicate Advisory: gix-date can create non-utf8 string with `TimeBuf::as_str`

Details:
### Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-6mw6-mj76-grwc. This link is maintained to preserve external references.

### Original Description
A flaw was found in gix-date. The `gix_date::parse::TimeBuf::as_str` function can generate strings containing invalid non-UTF8 characters. This issue violates the internal safety invariants of the `TimeBuf` component, leading to undefined behavior when these malformed strings are subsequently processed. This could potentially result in application instability or other unforeseen consequences.
GitHub Security Advisory: GHSA-rvr2-r3pv-5m4p
Package: oneshot (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), CWE-416: Use After Free
Vulnerable versions: < 0.1.12
Patched in: 0.1.12

Summary: oneshot has potential Use After Free when used asynchronously

Details:
There is a race condition that can lead to a use-after-free if a `oneshot::Receiver` is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar.

When the `Receiver` is polled (`Future::poll`) it writes a waker to the channel and sets it to the `RECEIVING` state. If the `Receiver` was then dropped (instead of polled to completion), the `Drop` implementation on `Receiver` unconditionally swapped the channel state to `DISCONNECTED` and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the `DISCONNECTED` state could be observed by the `Sender`, which would lead to it deallocating the channel heap memory. If the `Sender` manage to free the channel before the `Receiver` managed to proceed to dropping the waker, then the `Receiver` would read from the freed channel memory (Use After Free).

The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of `oneshot` version `0.1.12`.
GitHub Security Advisory: GHSA-796p-j2gh-9m2q
Package: dcap-qvl (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-295: Improper Certificate Validation, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.3.9
Patched in: 0.3.9

Summary: dcap-qvl has Missing Verification for QE Identity

Details:
## Impact
This vulnerability involves a critical gap in the cryptographic verification process within the dcap-qvl.

The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report.

## Consequences
An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes.

## Who is impacted
All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected.

## Patches
The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report.

Users of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`.

## Workarounds
There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified.

## Credit
This bug was reported by Rahul Saxena <saxenism@bluethroatlabs.com>.
GitHub Security Advisory: GHSA-mxc8-4jqf-368q
Package: miniserve (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 0.32.0
Patched in: 0.32.0

Summary: miniserve affected by a TOCTOU and symlink race vulnerability

Details:
A TOCTOU and symlink race in svenstaro/miniserve 0.32.0 upload finalization (when uploads are enabled) can allow an attacker to overwrite arbitrary files outside the intended upload/document root in deployments where the attacker can create/replace filesystem entries in the upload destination directory (e.g., shared writable directory/volume).
GitHub Security Advisory: GHSA-rjr4-v43m-pxq6
Package: triton-vm (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-330: Use of Insufficiently Random Values
Vulnerable versions: >= 0.41.0, < 2.0.0
Patched in: 2.0.0

Summary: Triton VM has a Soundness Vulnerability due to Improper Sampling of Randomness

Details:
In affected versions of Triton VM, the verifier failed to correctly sample randomness in the FRI sub-protocol.

Malicious provers can exploit this to craft proofs for arbitrary statements that this verifier accepts as valid, undermining soundness.

Protocols that rely on proofs and the supplied verifier of the affected versions of Triton VM are completely broken. Protocols implementing their own verifier might be unaffected.

The flaw was corrected in commit 3a045d63, where the relevant randomness is sampled correctly.
GitHub Security Advisory: GHSA-m3c4-prhw-mrx6
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.6
Patched in: 2.5.6

Summary: Deno has an incomplete fix for command-injection prevention on Windows — case-insensitive extension bypass

Details:
### Summary
A prior patch aimed to block spawning Windows batch/shell files by returning an error when a spawned path’s extension matched `.bat` or `.cmd`. That check performs a case-sensitive comparison against lowercase literals and therefore can be bypassed when the extension uses alternate casing (for example `.BAT, .Bat`, etc.).

### POC
```javascript
const command = new Deno.Command('./test.BAT', {
  args: ['&calc.exe'],
});
const child = command.spawn();
```
This causes `calc.exe` to be launched; see the attached screenshot for evidence.

**Patched in `CVE-2025-61787` — prevents execution of `.bat` and `.cmd` files:**
![photo_2025-10-10 02 27 23](https://github.com/user-attachments/assets/43df25e2-e2e1-48aa-8060-cb0a22637f1f)

**Bypass of the patched vulnerability:**
![photo_2025-10-10 02 27 25](https://github.com/user-attachments/assets/2be1afb4-84a1-4883-8e18-6a174fdd3615)


### Impact
The script launches calc.exe on Windows, demonstrating that passing user-controlled arguments to a spawned batch script can result in command-line injection.

### Mitigation

Users should update to Deno v2.5.6 or newer.
GitHub Security Advisory: GHSA-5379-f5hf-w38v
Package: deno (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-325: Missing Cryptographic Step
Vulnerable versions: <= 2.5.6
Patched in: 2.6.0

Summary: Deno node:crypto doesn't finalize cipher

Details:
### Summary

The vulnerability allows an attacker to have infinite encryptions. 

This can lead to naive attempts at brute forcing, as well as more refined attacks with the goal to learn the server secrets.

### PoC
```js
import crypto from "node:crypto";

const key = crypto.randomBytes(32);
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipheriv("aes-256-cbc", key, iv);
cipher.final()

console.log(cipher);
```

### Expected Output
```js
Cipheriv {
  _decoder: null,
  _options: undefined,
  Symbol(kHandle): CipherBase {}
}
```

### Actual Output
```js
Cipheriv {
  _events: {
    close: undefined,
    error: undefined,
    prefinish: [Function: prefinish],
    finish: undefined,
    drain: undefined,
    data: undefined,
    end: undefined,
    readable: undefined
  },
  _readableState: ReadableState {
    highWaterMark: 65536,
    buffer: [],
    bufferIndex: 0,
    length: 0,
    pipes: [],
    awaitDrainWriters: null,
    [Symbol(kState)]: 1048844
  },
  _writableState: WritableState {
    highWaterMark: 65536,
    length: 0,
    corked: 0,
    onwrite: [Function: bound onwrite],
    writelen: 0,
    bufferedIndex: 0,
    pendingcb: 0,
    [Symbol(kState)]: 17580812,
    [Symbol(kBufferedValue)]: null
  },
  allowHalfOpen: true,
  _final: [Function: final],
  _maxListeners: undefined,
  _transform: [Function: transform],
  _eventsCount: 1,
  [Symbol(kCapture)]: false,
  [Symbol(kCallback)]: null
}
```

### Mitigations

All users should upgrade to Deno v2.6.0 or newer.
GitHub Security Advisory: GHSA-333v-68xh-8mmq
Package: rustfs (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 1.0.0-alpha.1, <= 1.0.0-alpha.79
Patched in: 1.0.0-alpha.80

Summary: RustFS's RPC signature verification logs shared secret

Details:
### Summary
Invalid RPC signatures cause the server to log the shared HMAC secret (and expected signature), which exposes the secret to log readers and enables forged RPC calls.

### Details
In [`crates/ecstore/src/rpc/http_auth.rs:115-122`](https://github.com/rustfs/rustfs/blob/9e162b6e9ebb874cc1d06a7b33bc4a05786578aa/crates/ecstore/src/rpc/http_auth.rs#L115-L122) , the invalid signature branch logs sensitive data:
```rs
if signature != expected_signature {
    error!(
        "verify_rpc_signature: Invalid signature: secret {}, url {}, method {}, timestamp {}, signature {}, expected_signature {}",
        secret, url, method, timestamp, signature, expected_signature
    );

    return Err(std::io::Error::other("Invalid signature"));
}
```

This log line includes `secret` and `expected_signature`, both derived from the shared HMAC key. Any invalidly signed request triggers this path. The function is reachable from RPC and admin request handlers.

### PoC
1. Run RustFS with error logging enabled.
1. Send a request with an invalid signature:
    ```
     ts=$(date +%s)
     curl -v \
       -H "x-rustfs-timestamp: $ts" \
       -H "x-rustfs-signature: invalid-signature" \
       "http://localhost:9000/rustfs/rpc/read_file_stream?disk=foo&volume=bar&path=baz&offset=0&length=1"
    ```
1. Observed output:
    ```
     HTTP 403 AccessDenied: Invalid signature
     verify_rpc_signature: Invalid signature: secret rustfsadmin, url /rustfs/rpc/read_file_stream?disk=foo&volume=bar&path=baz&offset=0&length=1, method GET, timestamp[PII_REDACTED], signature invalid-signature, expected_signature oisNxNRTb80GXf97s/PGdScJzu8QB9Oxs+uOwf8RiK8=
    ```
### Impact

- Exposes the shared RPC HMAC secret to log readers.
- Enables attackers with log access to forge valid RPC signatures and make unauthorized RPC calls.
GitHub Security Advisory: GHSA-2gqc-6j2q-83qp
Package: cmov (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-203: Observable Discrepancy, CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 0.4.4
Patched in: 0.4.4

Summary: RustCrypto Utilities cmov: `thumbv6m-none-eabi` compiler emits non-constant time assembly when using `cmovnz`

Details:
### Summary

`thumbv6m-none-eabi` (Cortex M0, M0+ and M1) compiler emits non-constant time assembly when using `cmovnz` (portable version). I did not found any other target with the same behaviour but I did not go through all targets supported by Rust. 

### Details

It seems that, [during `mask` computation](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L78), an LLVM optimisation pass is detecting that [`bitnz`](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L13) is returning 0 or 1, that can be interpreted as a boolean. This intermediate value is not masked by a call to `black_box` and thus the subsequent [`.wrapping_sub(1)`](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L78C1-L78C84) can be interpreted as a conditional bitwise conditional not.

### PoC

This is an attempt at having a minimal faulty code. In a library crate with an up-to-date `cmov` as only dependency, the content of `src/lib.rs` is:

```rust
#![no_std]
use cmov::Cmov;

#[inline(never)]
pub fn test_ct_cmov(a: &mut u8, b: u8, c: u8) {
    a.cmovnz(&b, c);
}
```


The resulting assembly emitted (shown using `cargo asm --release --target thumbv6m-none-eabi` that uses [`cargo-show-asm`](https://crates.io/crates/cargo-show-asm)):

<details>
<summary>Collapsed assembly</summary>

```asm
.section .text.not_ct::test_ct_cmov,"ax",%progbits
	.globl	not_ct::test_ct_cmov
	.p2align	1
	.type	not_ct::test_ct_cmov,%function
	.code	16
	.thumb_func
not_ct::test_ct_cmov:
	.fnstart
	.cfi_sections .debug_frame
	.cfi_startproc
	.save	{r7, lr}
	push {r7, lr}
	.cfi_def_cfa_offset 8
	.cfi_offset lr, -4
	.cfi_offset r7, -8
	.setfp	r7, sp
	add r7, sp, #0
	.cfi_def_cfa_register r7
	.pad	#8
	sub sp, #8
	movs r3, #0
	lsls r2, r2, #24
	bne .LBB0_2
	mvns r3, r3
.LBB0_2:
	ldrb r2, [r0]
	str r3, [sp, #4]
	str r3, [sp]
	mov r3, sp
	@APP
	@NO_APP
	ldr r3, [sp]
	bics r1, r3
	ands r2, r3
	adds r1, r2, r1
	strb r1, [r0]
	add sp, #8
	pop {r7, pc}
```

</details>

The non-constant time assembly is:

```asm
    bne  .LBB0_2
    mvns r3, r3
.LBB0_2:
```

### Impact

The exact impact is unclear, especially since `cmov` clearly warns users that the portable version is best-effort.
GitHub Security Advisory: GHSA-mjjp-xjfg-97wg
Package: lief (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-404: Improper Resource Shutdown or Release, CWE-476: NULL Pointer Dereference
Vulnerable versions: < 0.17.2
Patched in: 0.17.2

Summary: LIEF is vulnerable to segmentation fault

Details:
A security flaw has been discovered in lief-project LIEF up to 0.17.1. Affected by this issue is the function Parser::parse_binary of the file src/ELF/Parser.tcc of the component ELF Binary Parser. The manipulation results in null pointer dereference. The attack must be initiated from a local position. The exploit has been released to the public and may be used for attacks. Upgrading to version 0.17.2 can resolve this issue. The patch is identified as 81bd5d7ea0c390563f1c4c017c9019d154802978. It is recommended to upgrade the affected component.
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-xray (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.90.0
Patched in: 1.90.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-workspacesweb (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.95.0
Patched in: 1.95.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html