deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-243v-98vx-264h
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 25.0.0, < 36.0.6
Patched in: 36.0.6

Summary: Wasmtime can panic when adding excessive fields to a `wasi:http/types.fields` instance

Details:
### Impact

Wasmtime's implementation of the `wasi:http/types.fields` resource is susceptible to panics when too many fields are added to the set of headers. Wasmtime's implementation in the `wasmtime-wasi-http` crate is backed by a data structure which panics when it reaches excessive capacity and this condition was not handled gracefully in Wasmtime. Panicking in a WASI implementation is a Denial of Service vector for embedders and is treated as a security vulnerability in Wasmtime.

### Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 patch this vulnerability and return a trap to the guest instead of panicking.

### Workarounds

There are no known workarounds at this time, embedders are encouraged to update to a patched version of Wasmtime.

### Resources

* [Limitations of `http::HeaderMap`](https://docs.rs/http/1.4.0/http/header/#limitations)
GitHub Security Advisory: GHSA-243v-98vx-264h
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 24.0.6
Patched in: 24.0.6

Summary: Wasmtime can panic when adding excessive fields to a `wasi:http/types.fields` instance

Details:
### Impact

Wasmtime's implementation of the `wasi:http/types.fields` resource is susceptible to panics when too many fields are added to the set of headers. Wasmtime's implementation in the `wasmtime-wasi-http` crate is backed by a data structure which panics when it reaches excessive capacity and this condition was not handled gracefully in Wasmtime. Panicking in a WASI implementation is a Denial of Service vector for embedders and is treated as a security vulnerability in Wasmtime.

### Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 patch this vulnerability and return a trap to the guest instead of panicking.

### Workarounds

There are no known workarounds at this time, embedders are encouraged to update to a patched version of Wasmtime.

### Resources

* [Limitations of `http::HeaderMap`](https://docs.rs/http/1.4.0/http/header/#limitations)
GitHub Security Advisory: GHSA-xjhv-v822-pf94
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: >= 41.0.0, < 41.0.4
Patched in: 41.0.4

Summary: Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future

Details:
The affected versions of Wasmtime can panic if the host embedder drops the future returned by `wasmtime::component::[Typed]Func::call_async` before it resolves.

### Details

Starting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions.  However, that implementation had a bug leading to a panic under certain circumstances:

1. The host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once.
2. The component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption.
3. The host embedding drops the `Future` after polling it once.  This leaves the component instance in a non-reenterable state since the call never had a chance to complete.
4. The host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`.  Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call.
5. The host embedding ignores the trap and drops the `Future`.  This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited.

### Impact
When a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected.

### Patches
Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected.

### Workarounds
If an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.

### Resources
This was first reported in https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29
GitHub Security Advisory: GHSA-xjhv-v822-pf94
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: >= 39.0.0, < 40.0.4
Patched in: 40.0.4

Summary: Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future

Details:
The affected versions of Wasmtime can panic if the host embedder drops the future returned by `wasmtime::component::[Typed]Func::call_async` before it resolves.

### Details

Starting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions.  However, that implementation had a bug leading to a panic under certain circumstances:

1. The host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once.
2. The component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption.
3. The host embedding drops the `Future` after polling it once.  This leaves the component instance in a non-reenterable state since the call never had a chance to complete.
4. The host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`.  Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call.
5. The host embedding ignores the trap and drops the `Future`.  This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited.

### Impact
When a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected.

### Patches
Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected.

### Workarounds
If an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.

### Resources
This was first reported in https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29
GitHub Security Advisory: GHSA-qhp6-635j-x7r2
Package: static-web-server (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 2.1.0, < 2.41.0
Patched in: 2.41.0

Summary: Static Web Server affected by timing-based username enumeration in Basic Authentication due to early response on invalid usernames

Details:
## Summary

A Timing-based username enumeration in Basic Authentication vulnerability due to early response on invalid usernames could allow attackers to identify valid users and focus their efforts on targeted brute-force or credential-stuffing attacks.

## Details

SWS validates the provided username before performing any password verification.
- **Invalid Username:** The server returns a `401 Unauthorized` response immediately.
- **Valid Username:** The server proceeds to verify the password (e.g., using `bcrypt`), which introduces a different execution path and measurable timing discrepancy.

This allows an attacker to distinguish between existing and non-existing accounts by analyzing response times.

## PoC

The following statistical results were obtained by measuring the mean response time over 100 iterations using a custom Rust script:

| User Type | Average Response Time |
| :--- | :--- |
| **Invalid User** | 0.409861 ms |
| **Valid User** | 0.250925 ms |
| **Difference** | **~0.158936 ms** |

While the valid user responded faster in this specific test environment, the statistically significant gap confirms that the authentication logic does not execute in constant time.

## Impact

Users using the SWS' Basic Authentication feature are primarily impacted.
GitHub Security Advisory: GHSA-hmh4-3xvx-q5hr
Package: deno (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 2.6.8
Patched in: 2.6.8

Summary: Deno has a Command Injection via Incomplete shell metacharacter blocklist in node:child_process

Details:
## Summary
A command injection vulnerability exists in Deno's `node:child_process` implementation. 

## Reproduction
```javascript
import { spawnSync } from "node:child_process";
import * as fs from "node:fs";

// Cleanup
try { fs.unlinkSync('/tmp/rce_proof'); } catch {}

// Create legitimate script
fs.writeFileSync('/tmp/legitimate.ts', 'console.log("normal");');

// Malicious input with newline injection
const maliciousInput = `/tmp/legitimate.ts\ntouch /tmp/rce_proof`;

// Vulnerable pattern
spawnSync(Deno.execPath(), ['run', '--allow-all', maliciousInput], {
  shell: true,
  encoding: 'utf-8'
});

// Verify
console.log('Exploit worked:', fs.existsSync('/tmp/rce_proof'));
```

Run: `deno run --allow-all poc.mjs`

The file `/tmp/rce_proof` is created, confirming arbitrary command execution.

## Mitigation

All users need to update to the patched version (Deno v2.6.8).
GitHub Security Advisory: GHSA-47qc-857f-7w7f
Package: pyo3 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 0.28.0, < 0.28.2
Patched in: 0.28.2

Summary: PyO3 has type confusion when accessing data from sublasses of subclasses of native types with `abi3` feature

Details:
PyO3 0.28.1 added support for `#[pyclass(extends=PyList)] struct NativeSub` (and other native types) when targeting Python 3.12 and up with the `abi3` feature.

It was discovered that subclasses of such classes would use the type of the subclass when attempting to access to data of `NativeSub` contained within Python objects, amounting to memory corruption.

PyO3 0.28.2 fixed the issue by using the type of (e.g.) `NativeSub` correctly.
GitHub Security Advisory: GHSA-3288-p39f-rqpv
Package: keccak (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Vulnerable versions: < 0.1.6
Patched in: 0.1.6

Summary: Unsoundness in opt-in ARMv8 assembly backend for `keccak`

Details:
### Summary

The `asm!` block enabled by the off-by-default `asm` feature, when enabled on ARMv8 targets, misspecified the operand
type for all of its operands, using `in` for pointers and values which were subsequently mutated by operations performed
within the assembly block.

### Impact

It's unclear what practical impact, if any, this actually had. Incorrect operand types are technically undefined
behavior, however changing them had no actual impact on the generated assembly for these targets. The possibility still
exists that it may lead to potential memory safety or other issues on hypothetical future versions of rustc.

### Mitigation

The operand types were changed from `in` to `inout`, and the impacted versions of the `keccak` crate were yanked.
GitHub Security Advisory: GHSA-2cgv-28vr-rv6j
Package: libcrux-ml-dsa (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-2cgv-28vr-rv6j
Package: libcrux-ml-kem (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-7v42-g35v-xrch
Package: httpsig-hyper (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-354: Improper Validation of Integrity Check Value, CWE-697: Incorrect Comparison
Vulnerable versions: < 0.0.23
Patched in: 0.0.23

Summary: Improper Digest Verification in httpsig-hyper May Allow Message Integrity Bypass

Details:
### Impact

An issue was discovered in `httpsig-hyper` where Digest header verification could incorrectly succeed due to misuse of Rust's `matches!` macro. Specifically, the comparison:

```rust
if matches!(digest, _expected_digest)
```

treated `_expected_digest` as a pattern binding rather than a value comparison, resulting in unconditional success of the match expression.

As a consequence, digest verification could incorrectly return success even when the computed digest did not match the expected value.

Applications relying on Digest verification as part of HTTP message signature validation may therefore fail to detect message body modification. The severity depends on how the library is integrated and whether additional signature validation layers are enforced.

---

### Patches

This issue has been fixed in:

- `httpsig-hyper` >= 0.0.23

The fix replaces the incorrect `matches!` usage with proper value comparison and additionally introduces constant-time comparison for digest verification as defense-in-depth.

Regression tests have also been added to prevent reintroduction of this issue. Users are strongly advised to upgrade to the patched version.

---

### Workarounds

There is no reliable workaround without upgrading. Users who cannot immediately upgrade should avoid relying solely on Digest verification for message integrity and ensure that full HTTP message signature verification is enforced at the application layer.

---

### References

- PR: https://github.com/junkurihara/httpsig-rs/pull/14
- Follow-up hardening and test additions: https://github.com/junkurihara/httpsig-rs/pull/15
GitHub Security Advisory: GHSA-4chv-4c6w-w254
Package: soroban-sdk-macros (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: <= 22.0.9
Patched in: 22.0.10

Summary: The rs-soroban-sdk #[contractimpl] macro calls inherent function instead of trait function when names collide

Details:
### Impact

The `#[contractimpl]` macro contains a bug in how it wires up function calls.

In Rust, you can define functions on a type in two ways:
- Directly on the type as an inherent function:
  ```rust
  impl MyContract {
      fn value() { ... }
  }
  ```
- Through a trait
  ```rust
  impl Trait for MyContract {
      fn value() { ... }
  }
  ```

These are two separate functions that happen to share the same name. Rust has rules for which one gets called. When you write `MyContract::value()`, Rust always picks the one defined directly on the type, not the trait version.

The bug is that `#[contractimpl]` generates code that uses `MyContract::value()` style calls even when it's processing the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function.

This means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously:
1. A `impl Trait for MyContract` block is defined with one or more functions, with `#[contractimpl]` applied.
2. A `impl MyContract` block is defined with one or more identically named functions, without `#[contractimpl]` applied.

If the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function.

For example:

```rust
#[contract]
pub struct Contract;

impl Contract {
    /// Inherent function — returns 1.
    /// Bug: The macro-generated WASM export is wired up to call this function.
    pub fn value() -> u32 {
        1
    }
}

pub trait Trait {
    fn value(env: Env) -> u32;
}

#[contractimpl]
impl Trait for MyContract {
    /// Trait implementation — returns 2.
    /// Fix: The macro-generated WASM export should call this function.
    fn value() -> u32 {
        2
    }
}
```

### Patches

The problem is patched in `soroban-sdk-macros` version **25.1.1**. The fix changes the generated call from `<Type>::func()` to `<Type as Trait>::func()` when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists.

Users should upgrade to `soroban-sdk-macros` **>= 25.1.1** and recompile their contracts.

### Workarounds

If upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.
GitHub Security Advisory: GHSA-4chv-4c6w-w254
Package: soroban-sdk-macros (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: >= 23.0.0, <= 23.5.1
Patched in: 23.5.2

Summary: The rs-soroban-sdk #[contractimpl] macro calls inherent function instead of trait function when names collide

Details:
### Impact

The `#[contractimpl]` macro contains a bug in how it wires up function calls.

In Rust, you can define functions on a type in two ways:
- Directly on the type as an inherent function:
  ```rust
  impl MyContract {
      fn value() { ... }
  }
  ```
- Through a trait
  ```rust
  impl Trait for MyContract {
      fn value() { ... }
  }
  ```

These are two separate functions that happen to share the same name. Rust has rules for which one gets called. When you write `MyContract::value()`, Rust always picks the one defined directly on the type, not the trait version.

The bug is that `#[contractimpl]` generates code that uses `MyContract::value()` style calls even when it's processing the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function.

This means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously:
1. A `impl Trait for MyContract` block is defined with one or more functions, with `#[contractimpl]` applied.
2. A `impl MyContract` block is defined with one or more identically named functions, without `#[contractimpl]` applied.

If the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function.

For example:

```rust
#[contract]
pub struct Contract;

impl Contract {
    /// Inherent function — returns 1.
    /// Bug: The macro-generated WASM export is wired up to call this function.
    pub fn value() -> u32 {
        1
    }
}

pub trait Trait {
    fn value(env: Env) -> u32;
}

#[contractimpl]
impl Trait for MyContract {
    /// Trait implementation — returns 2.
    /// Fix: The macro-generated WASM export should call this function.
    fn value() -> u32 {
        2
    }
}
```

### Patches

The problem is patched in `soroban-sdk-macros` version **25.1.1**. The fix changes the generated call from `<Type>::func()` to `<Type as Trait>::func()` when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists.

Users should upgrade to `soroban-sdk-macros` **>= 25.1.1** and recompile their contracts.

### Workarounds

If upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.