deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-j4xf-2g29-59ph
Package: tar (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 0.4.44
Patched in: 0.4.45

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

Details:
## Summary

When unpacking a tar archive, the `tar` crate's `unpack_dir` function uses `fs::metadata()` to check whether a path that already exists is a directory. Because `fs::metadata()` follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory — and subsequently apply `chmod` to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

## Reproducer

A malicious tarball contains two entries: (1) a symlink `foo` pointing to an arbitrary external directory, and (2) a directory entry `foo/.` (or just `foo`). When unpacked, `create_dir("foo")` fails with `EEXIST` because the symlink is already on disk. The `fs::metadata()` check then follows the symlink, sees a directory at the target, and allows processing to continue. The directory entry's mode bits are then applied via `chmod`, which also follows the symlink — modifying the permissions of the external target directory.

## Fix 

The fix is very simple, we now use `fs::symlink_metadata()` in `unpack_dir`, so symlinks are detected and rejected rather than followed.

## Credit

This issue was reported by @xokdvium - thank you!
GitHub Security Advisory: GHSA-gc42-3jg7-rxr2
Package: libp2p-gossipsub (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.49.3
Patched in: 0.49.3

Summary: Gossipsub PRUNE.backoff Duration Overflow

Details:
### Summary
The Rust libp2p Gossipsub implementation accepts attacker-controlled PRUNE backoff values and may perform unchecked time arithmetic when storing backoff state.
A specially crafted PRUNE control message with an extremely large backoff (e.g. u64::MAX) can lead to Duration/Instant overflow during backoff update logic, triggering a panic in the networking state machine. This is remotely reachable over a normal libp2p connection and does not require authentication.

### Attack Scenario
An attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending a single crafted PRUNE control message:
1. Establish a standard libp2p transport session and negotiate a stream multiplexer.
2. Open a Gossipsub stream and negotiate the meshsub protocol.
3. Send one protobuf RPC containing ControlPrune with a very large backoff value (e.g.[PII_REDACTED][PII_REDACTED] / u64::MAX).
When processed, the oversized backoff can reach time-update logic that adds Duration::from_secs(backoff) to Instant::now(), causing overflow and panic.

### Impact
Remote unauthenticated denial of service.
Any application exposing a libp2p Gossipsub listener and using the affected backoff-handling path can be crashed by a network attacker that can reach the service port. The attack can be repeated by reconnecting and replaying the crafted control message.
### Patches
Users should upgrade to a release that hardens Gossipsub backoff handling.

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program
GitHub Security Advisory: GHSA-6gx3-4362-rf54
Package: astral-tokio-tar (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: <= 0.5.6
Patched in: 0.6.0

Summary: astral-tokio-tar insufficiently validates PAX extensions during extraction

Details:
## Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

## Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them. 

## Workarounds

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

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

## Attribution

- Sergei Zimmerman (@xokdvium)
GitHub Security Advisory: GHSA-vvp9-7p8x-rfvv
Package: lz4_flex (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data, CWE-823: Use of Out-of-range Pointer Offset
Vulnerable versions: >= 0.12.0, < 0.12.1
Patched in: 0.12.1

Summary: lz4_flex's decompression can leak information from uninitialized memory or reused output buffer

Details:
### Summary
Decompressing invalid LZ4 data can leak data from uninitialized memory, or can leak content from previous decompression operations when reusing an output buffer.

### Details
The LZ4 block format defines a "match copy operation" which duplicates previously written data or data from the user-supplied dict. The position of that data is defined by an _offset_. The data is copied within the output buffer from the _offset_ to the current output position.
However, lz4_flex did not properly detect invalid and out-of-bounds _offset_ values properly, causing it to copy uninitialized data from the output buffer.

Only the block based API functions are affected: 
`lz4_flex::block::{decompress_into, decompress_into_with_dict}`

When safe-decode is disabled _additionally_ these functions are affected
`lz4_flex::block::{decompress, decompress_with_dict, decompress_size_prepended, decompress_size_prepended_with_dict}`

All `frame` APIs are _not_ affected.

There are two affected use cases:
- decompressing LZ4 data with the `unsafe` implementation (`safe-decode` feature flag disabled, which is enabled by default):
can leak content of uninitialized memory as decompressed result
- decompressing LZ4 data into a reused, user-supplied `output` buffer (affects the `safe-decode` feature as well):
can leak the previous contents of the output buffer as decompressed result

### Impact
Leakage of data from uninitialized memory or content from previous decompression operations, possibly revealing sensitive information and secrets.

### Mitigation
lz4_flex 0.12.1 and 0.11.6 fixes this issue without requiring changes in user code.

If you cannot upgrade, you can mitigate this vulnerability by zeroing the output buffer before calling `block::decompress_into` or  `block::decompress_into_with_dict` (only block based API is affected, frame API is not affected). Additionally the the `safe-decode` feature flag should be enabled.
GitHub Security Advisory: GHSA-vvp9-7p8x-rfvv
Package: lz4_flex (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data, CWE-823: Use of Out-of-range Pointer Offset
Vulnerable versions: < 0.11.6
Patched in: 0.11.6

Summary: lz4_flex's decompression can leak information from uninitialized memory or reused output buffer

Details:
### Summary
Decompressing invalid LZ4 data can leak data from uninitialized memory, or can leak content from previous decompression operations when reusing an output buffer.

### Details
The LZ4 block format defines a "match copy operation" which duplicates previously written data or data from the user-supplied dict. The position of that data is defined by an _offset_. The data is copied within the output buffer from the _offset_ to the current output position.
However, lz4_flex did not properly detect invalid and out-of-bounds _offset_ values properly, causing it to copy uninitialized data from the output buffer.

Only the block based API functions are affected: 
`lz4_flex::block::{decompress_into, decompress_into_with_dict}`

When safe-decode is disabled _additionally_ these functions are affected
`lz4_flex::block::{decompress, decompress_with_dict, decompress_size_prepended, decompress_size_prepended_with_dict}`

All `frame` APIs are _not_ affected.

There are two affected use cases:
- decompressing LZ4 data with the `unsafe` implementation (`safe-decode` feature flag disabled, which is enabled by default):
can leak content of uninitialized memory as decompressed result
- decompressing LZ4 data into a reused, user-supplied `output` buffer (affects the `safe-decode` feature as well):
can leak the previous contents of the output buffer as decompressed result

### Impact
Leakage of data from uninitialized memory or content from previous decompression operations, possibly revealing sensitive information and secrets.

### Mitigation
lz4_flex 0.12.1 and 0.11.6 fixes this issue without requiring changes in user code.

If you cannot upgrade, you can mitigate this vulnerability by zeroing the output buffer before calling `block::decompress_into` or  `block::decompress_into_with_dict` (only block based API is affected, frame API is not affected). Additionally the the `safe-decode` feature flag should be enabled.
GitHub Security Advisory: GHSA-vxx9-2994-q338
Package: yamux (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception, CWE-617: Reachable Assertion
Vulnerable versions: < 0.13.10
Patched in: 0.13.10

Summary: Yamux vulnerable to remote Panic via malformed Data frame with SYN set and len = 262145

Details:
### Summary
The Rust implementation of Yamux can panic when processing a crafted inbound Data frame that sets SYN and uses a body length greater than DEFAULT_CREDIT (e.g. 262145).
On the first packet of a new inbound stream, stream state is created and a receiver is queued before oversized-body validation completes. When validation fails, the temporary stream is dropped and cleanup may call remove(...).expect("stream not found"), triggering a panic in the connection state machine.
This is remotely reachable over a normal Yamux session and does not require authentication. kind of vulnerability is it? Who is 
#### Attack Scenario  
An attacker that can establish a Yamux session with a target node can crash the target by sending a single validly encoded Yamux Data|SYN frame with an oversized body:
1. Establish a standard authenticated transport session that negotiates Yamux.
2. Send one Yamux frame with:
   - Tag = Data
   - Flags = SYN
   - StreamId = 1 (or any new inbound stream id)
   - Length = DEFAULT_CREDIT + 1 (e.g. 262145)
   - Body of matching size
This can trigger a panic (stream not found) and terminate the process, depending on host application panic policy.
### Patches
Users should upgrade to `yamux` `v0.13.10`

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program
GitHub Security Advisory: GHSA-4c96-w8v2-p28j
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.7.0, < 2.7.2
Patched in: 2.7.2

Summary: Deno vulnerable to command Injection via incomplete shell metacharacter blocklist in node:child_process

Details:
## Summary

  A command injection vulnerability exists in Deno's `node:child_process` polyfill (`shell: true` mode) that bypasses the fix
  for CVE-2026-27190 (GHSA-hmh4-3xvx-q5hr). An attacker who controls arguments passed to `spawnSync` or `spawn` with `shell:
  true` can execute arbitrary OS commands, bypassing Deno's permission system.

  **Affected versions:** Deno v2.7.0, v2.7.1

  ## Details

  The two-stage argument sanitization in `transformDenoShellCommand` (`ext/node/polyfills/internal/child_process.ts`) has a
  priority bug: when an argument contains a `$VAR` pattern, it is wrapped in double quotes (L1290) instead of single quotes
  (L1293). Double quotes in POSIX sh do not suppress backtick command substitution, allowing injected commands to execute.

  Attack chain:
  1. `escapeShellArg` wraps the argument in single quotes (safe)
  2. `op_node_parse_shell_args` strips the single-quote delimiters during tokenization (raw argument exposed)
  3. Re-quoting detects `$VAR` pattern → applies double quotes
  4. Backtick payload inside double quotes executes via `/bin/sh`

  ## Impact

  **OS Command Injection (CWE-78)**. Any application using `node:child_process` `spawn`/`spawnSync` with `shell: true` and
  user-controlled arguments is vulnerable. Injected commands execute at the OS process level, outside Deno's permission
  sandbox. Only `--allow-run` is required.

  ## Mitigation

  Avoid passing user-controlled input as arguments to `spawn`/`spawnSync` with `shell: true`. Use `shell: false` (the default)
  instead, or validate/sanitize inputs before passing them.
GitHub Security Advisory: GHSA-4w32-2493-32g7
Package: yamux (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.13.0, < 0.13.9
Patched in: 0.13.9

Summary: Yamux vulnerable to remote Panic via malformed WindowUpdate credit

Details:
### Sumary
The Rust implementation of Yamux accepts `WindowUpdate` credit values from the remote peer and applies them to per-stream send-window state.  
A specially crafted `WindowUpdate` can cause arithmetic overflow in send-window accounting, which triggers a panic in the connection state machine. This is remotely reachable over a normal network connection and does not require authentication.
#### Attack Scenario  
An attacker that can establish a Yamux session with a target node can crash the target by sending two validly encoded Yamux frames:
1. Open a stream (e.g. DATA + SYN) so the stream exists with initial send-window state (`DEFAULT_CREDIT`).
2. Send a WindowUpdate on that stream with a very large credit value (e.g. 0xFFFF_0000) such that adding credit to the current send-window overflows u32.
### Impact
Remote unauthenticated denial of service.  
An attacker can repeatedly trigger panics by reconnecting and replaying the crafted frame sequence.
### Patches
Users should upgrade to `yamux` `v0.13.9`

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program
GitHub Security Advisory: GHSA-g2p6-hh5v-7hfm
Package: soroban-poseidon (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-328: Use of Weak Hash
Vulnerable versions: < 25.0.1
Patched in: 25.0.1

Summary: Poseidon V1 variable-length input collision via implicit zero-padding

Details:
## Impact

Poseidon V1 (`PoseidonSponge`) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (`inputs.len() < T - 1`), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector `[m1, ..., mk]` hashed with a sponge of rate > k, `hash([m1, ..., mk])` equals `hash([m1, ..., mk, 0])` because both produce identical pre-permutation states.

This affects any use of `PoseidonSponge` or `poseidon_hash` where the number of inputs is less than `T - 1` (e.g., hashing 1 input with `T=3`).

Poseidon2 (`Poseidon2Sponge`) is **not affected** — it encodes the input length in the capacity element (`IV = input_len << 64`), making different-length inputs produce distinct states.

## Patches

Fixed by enforcing `inputs.len() == RATE` in `PoseidonSponge::compute_hash`, matching circom's invariant that `nInputs` always equals `T - 1`. Users should upgrade to the next release containing this fix.

## Workarounds

If upgrading is not immediately possible:

- Ensure callers **always** use `T = inputs.len() + 1` (full-rate), which is how circom uses Poseidon. For example, to hash 2 inputs, use `T=3`; to hash 1 input, use `T=2`. Never use a sponge with more rate capacity than the number of inputs.
- Alternatively, migrate to `Poseidon2Sponge`, which is safe for variable-length inputs due to its length-encoding IV.

## References
- [circom Poseidon implementation](https://github.com/iden3/circomlib/blob/master/circuits/poseidon.circom) — reference implementation where `nInputs` determines `T`
- [Poseidon paper](https://eprint.iacr.org/2019/458) — Section 4 discusses sponge construction and padding requirements
GitHub Security Advisory: GHSA-2m67-cxxq-c3h8
Package: zeptoclaw (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-62: UNIX Hard Link
Vulnerable versions: <= 0.7.5
Patched in: 0.7.6

Summary: ZeptoClaw: Path boundary checks bypass via symlink, TOCTOU, and hardlink

Details:
### Summary
Workspace boundary enforcement currently has three related bypass risks. This issue tracks fixing all three in one pull request.

### Details

#### R1 - Dangling Symlink Component Bypass
- What happens: Path validation can miss dangling symlink components during traversal checks.
- Why it matters: A symlink that is unresolved at validation time can later resolve to an external location.
- Impact: Read and write operations may escape workspace boundaries.
- Affected area: src/security/path.rs (check_symlink_escape).

#### R2 - TOCTOU Between Validation and Use
- What happens: The path is validated first, then used later for filesystem operations.
- Why it matters: A concurrent filesystem change can swap path components after validation but before open/write.
- Impact: Race-based workspace escape is possible.
- Affected area: Filesystem and file-consuming tools that call validate_path_in_workspace before I/O.

#### R3 - Hardlink Alias Bypass
- What happens: A file inside workspace can be a hardlink to an inode outside the intended workspace trust boundary.
- Why it matters: Prefix and symlink checks can pass while data access still mutates or reads external content.
- Impact: Policy bypass for read/write operations.
- Affected area: Any tool that reads or writes via validated paths.

#### Risk Matrix

| ID | Risk | Severity | Likelihood | Impact |
|---|---|---|---|---|
| R1 | Dangling symlink component bypass | High | Medium | Workspace boundary escape for read/write |
| R2 | Validate/use TOCTOU race | High | Medium | Race-based boundary escape during file I/O |
| R3 | Hardlink alias bypass | Medium | Low-Medium | External inode read/write through in-workspace path |

### PoC

#### R1 - Dangling symlink component bypass
1. Create a symlink inside workspace pointing to a missing target.
2. Validate a path traversing that symlink.
3. Create the target directory outside workspace after validation.
4. Perform file operation and observe potential boundary escape if not fail-closed.

#### R2 - TOCTOU between validation and use
1. Validate a candidate in-workspace path.
2. Before open/write, replace an intermediate component with a link to external location.
3. Continue with the file operation.
4. Observe boundary escape if operation trusts only stale validation result.

#### R3 - Hardlink alias bypass
1. Place a hardlink inside workspace that points to an external inode.
2. Validate the in-workspace hardlink path.
3. Read or write through this path.
4. Observe external inode access through a path that appears in-scope.

### Impacts
Unauthorized cross path boundary

## Credit
[@zpbrent](https://github.com/zpbrent)

### Patch
[f50c17e11ae3e2d40c96730abac41974ef2ee2a8](https://github.com/qhkm/zeptoclaw/commit/f50c17e11ae3e2d40c96730abac41974ef2ee2a8)
GitHub Security Advisory: GHSA-vhj5-x93p-67jw
Package: actix-web-lab (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 0.25.0
Patched in: 0.26.0

Summary: actix-web-lab has host header poisoning in redirect middleware can generate attacker-controlled absolute redirects

Details:
### Summary
`actix-web-lab` redirect middleware uses request-derived host information to construct absolute redirect URLs (for example, `https://{hostname}{path}`). In deployments without strict host allowlisting, an attacker can supply a malicious Host header and poison the `Location` response header, causing open redirect/phishing behavior.

### CVE
Assigned CVE ID:  CVE-2025-63762

### Details
The issue is in redirect middleware paths that construct absolute URLs from `req.connection_info()`:

1. `actix-web-lab/src/redirect_to_https.rs` (around lines 119-132)
   - `let host = conn_info.host();`
   - `format!("https://{hostname}{path}")`
   - `format!("https://{hostname}:{port}{path}")`

2. `actix-web-lab/src/redirect_to_www.rs` (around lines 30-35)
   - `format!("{scheme}://www.{host}{path}")`

3. `actix-web-lab/src/redirect_to_non_www.rs` (around lines 30-34)
   - `format!("{scheme}://{host_no_www}{path}")`

Because host values come from request connection metadata, untrusted Host input can influence redirect targets when deployment-side host validation is missing.

### PoC
Environment used for validation:
- Local minimal Actix apps using `actix-web-lab` middleware
- RedirectHttps: `http://127.0.0.1:18080`
- redirect_to_www: `http://127.0.0.1:18081`
- redirect_to_non_www: `http://127.0.0.1:18082`

Reproduction (RedirectHttps):
```bash
curl.exe -i -s "http://127.0.0.1:18080/test" -H "Host: attacker.example"
```

Observed response:
```http
HTTP/1.1 307 Temporary Redirect
location: https://attacker.example/test
```

Additional verification:
```bash
curl.exe -i -s "http://127.0.0.1:18080/abc/def" -H "Host: evil.example:9999"
```

Observed response:
```http
HTTP/1.1 307 Temporary Redirect
location: https://evil.example/abc/def
```

Reproduction (redirect_to_www):
```bash
curl.exe -i -s "http://127.0.0.1:18081/hello" -H "Host: attacker.example"
```

Observed response:
```http
HTTP/1.1 307 Temporary Redirect
location: http://www.attacker.example/hello
```

Reproduction (redirect_to_non_www):
```bash
curl.exe -i -s "http://127.0.0.1:18082/path" -H "Host: www.attacker.example"
```

Observed response:
```http
HTTP/1.1 307 Temporary Redirect
location: http://attacker.example/path
```

### Impact
This is a Host header poisoning / open redirect issue. Users can be redirected to attacker-controlled domains, enabling phishing and trust-boundary abuse. Any application using these middleware paths without strict host validation (proxy/app allowlisting) is impacted.