deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g88p-r42r-ppp9
Package: github.com/argoproj/argo-cd/v3 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: = 3.2.0-rc1
Patched in: 3.2.0-rc2

Summary: Repository Credentials Race Condition Crashes Argo CD Server

Details:
### Summary

A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL.

### Details
The vulnerability is located in numerous repository related handlers in the `util/db/repository_secrets.go` file. For example, in the `secretToRepoCred` function. The issue manifests as a concurrent map access panic:

```
concurrent map read and map write
...
goroutine 1104 [running]:
github.com/argoproj/argo-cd/v2/util/db.(*secretsRepositoryBackend).secretToRepoCred(0xc000e50ea8?, 0xc000c65540)
        /go/src/github.com/argoproj/argo-cd/util/db/repository_secrets.go:404 +0x31e
```

The race condition occurs due to:
1. Concurrent repository credential operations (create/update/delete) accessing the same map
2. Kubernetes informer re-syncs happening simultaneously
3. Background watchers updating the same secret data
4. No mutex protection for map access

A valid API token with `repositories` resource permissions (`create`, `update`, or `delete` actions) is required to trigger the race condition.

### Impact

This vulnerability causes the entire Argo CD server to crash and become unavailable. Attackers can repeatedly and continuously trigger the race condition to maintain a denial-of-service state, disrupting all GitOps operations. Default ArgoCD configuration is vulnerable.

The affected code was originally introduced in [PR #6103](https://github.com/argoproj/argo-cd/pull/6103) and released in [v2.1.0](https://github.com/argoproj/argo-cd/releases/tag/v2.1.0).

This data race was addressed by deep-copying the `Secret` objects before reading/writing.

### Credits

This vulnerability was found, reported and fixed by:

@thevilledev

The Argo team would like to thank him for his responsible disclosure and constructive communications during the resolve of this issue.
GitHub Security Advisory: GHSA-g88p-r42r-ppp9
Package: github.com/argoproj/argo-cd/v2 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 2.1.0, <= 2.14.19
Patched in: 2.14.20

Summary: Repository Credentials Race Condition Crashes Argo CD Server

Details:
### Summary

A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL.

### Details
The vulnerability is located in numerous repository related handlers in the `util/db/repository_secrets.go` file. For example, in the `secretToRepoCred` function. The issue manifests as a concurrent map access panic:

```
concurrent map read and map write
...
goroutine 1104 [running]:
github.com/argoproj/argo-cd/v2/util/db.(*secretsRepositoryBackend).secretToRepoCred(0xc000e50ea8?, 0xc000c65540)
        /go/src/github.com/argoproj/argo-cd/util/db/repository_secrets.go:404 +0x31e
```

The race condition occurs due to:
1. Concurrent repository credential operations (create/update/delete) accessing the same map
2. Kubernetes informer re-syncs happening simultaneously
3. Background watchers updating the same secret data
4. No mutex protection for map access

A valid API token with `repositories` resource permissions (`create`, `update`, or `delete` actions) is required to trigger the race condition.

### Impact

This vulnerability causes the entire Argo CD server to crash and become unavailable. Attackers can repeatedly and continuously trigger the race condition to maintain a denial-of-service state, disrupting all GitOps operations. Default ArgoCD configuration is vulnerable.

The affected code was originally introduced in [PR #6103](https://github.com/argoproj/argo-cd/pull/6103) and released in [v2.1.0](https://github.com/argoproj/argo-cd/releases/tag/v2.1.0).

This data race was addressed by deep-copying the `Secret` objects before reading/writing.

### Credits

This vulnerability was found, reported and fixed by:

@thevilledev

The Argo team would like to thank him for his responsible disclosure and constructive communications during the resolve of this issue.
GitHub Security Advisory: GHSA-vmg3-7v43-9g23
Package: github.com/NVIDIA/mig-parted (GO)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-426: Untrusted Search Path
Vulnerable versions: < 0.12.2
Patched in: 0.12.2

Summary: NVIDIA Container Toolkit for all platforms contains an Untrusted Search Path

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in some hooks used to initialize the container, where an attacker could execute arbitrary code with elevated permissions. A successful exploit of this vulnerability might lead to escalation of privileges, data tampering, information disclosure, and denial of service.
GitHub Security Advisory: GHSA-vmg3-7v43-9g23
Package: github.com/NVIDIA/gpu-operator (GO)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-426: Untrusted Search Path
Vulnerable versions: < 25.3.2
Patched in: 25.3.2

Summary: NVIDIA Container Toolkit for all platforms contains an Untrusted Search Path

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in some hooks used to initialize the container, where an attacker could execute arbitrary code with elevated permissions. A successful exploit of this vulnerability might lead to escalation of privileges, data tampering, information disclosure, and denial of service.
GitHub Security Advisory: GHSA-vmg3-7v43-9g23
Package: github.com/NVIDIA/k8s-device-plugin (GO)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-426: Untrusted Search Path
Vulnerable versions: < 0.17.3
Patched in: 0.17.3

Summary: NVIDIA Container Toolkit for all platforms contains an Untrusted Search Path

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in some hooks used to initialize the container, where an attacker could execute arbitrary code with elevated permissions. A successful exploit of this vulnerability might lead to escalation of privileges, data tampering, information disclosure, and denial of service.
GitHub Security Advisory: GHSA-vmg3-7v43-9g23
Package: github.com/NVIDIA/nvidia-container-toolkit (GO)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-426: Untrusted Search Path
Vulnerable versions: < 1.17.8
Patched in: 1.17.8

Summary: NVIDIA Container Toolkit for all platforms contains an Untrusted Search Path

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in some hooks used to initialize the container, where an attacker could execute arbitrary code with elevated permissions. A successful exploit of this vulnerability might lead to escalation of privileges, data tampering, information disclosure, and denial of service.
GitHub Security Advisory: GHSA-g588-cjg3-6g78
Package: steamworks (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.13.1
Patched in: 0.13.1

Summary: Steamworks game clients/servers using P2P authentication vulnerable to denial of service

Details:
Processing the raw `ValidateAuthTicketResponse_t` callback data panics when the `m_eAuthSessionResponse` field is `k_EAuthSessionResponseAuthTicketNetworkIdentityFailure`. This can lead to denial of service in game clients and servers using the `begin_authentication_session` API to authenticate players if a malicious game client sends an authentication ticket with a network identity that does not match that of the verifier.
GitHub Security Advisory: GHSA-97wc-2hqc-cjgr
Package: smallbitvec (RUST)
Severity: HIGH (CVSS 7.3)
CWE: CWE-122: Heap-based Buffer Overflow, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 1.0.1, <= 2.6.0
Patched in: unpatched

Summary: smallbitvec: Integer overflow in safe API leads to heap buffer overflow

Details:
### Summary
An integer overflow in the internal capacity calculation of `smallbitvec` can lead to an undersized heap allocation, resulting in a heap buffer overflow through safe APIs only. This allows memory corruption without requiring `unsafe` code from the caller.

### Details
The issue originates from unchecked arithmetic in the internal helper function responsible for computing the required buffer size:

```
(cap + bits_per_storage() - 1) / bits_per_storage()
```

When `cap` is close to `usize::MAX`, the addition:

```
cap + bits_per_storage() - 1
```

can overflow in release builds and wrap around due to Rust’s default wrapping semantics for integer overflow in optimized builds.

As a result:
- `buffer_len(cap)` may return a value significantly smaller than required.
- The backing storage is allocated with insufficient size.
- Internal metadata (logical length/capacity) reflects a much larger size than the actual allocation.

Subsequent safe API calls (e.g., `set`, `push`, `reserve`) rely on this corrupted metadata and perform index computations that assume sufficient backing storage. These operations eventually reach unsafe internal code paths (e.g., pointer arithmetic and unchecked indexing), leading to out-of-bounds memory access.

Summary of the issue:
integer overflow
→ undersized allocation
→ inconsistent metadata (len/cap vs actual buffer)
→ unsafe internal access using corrupted metadata
→ heap buffer overflow (UB)
### PoC
#### PoC 1: Out-of-bounds write via `from_elem`
```rust
#![forbid(unsafe_code)]

use smallbitvec::SmallBitVec;

fn main() {
    // Triggers overflow in buffer_len(cap)
    let mut v = SmallBitVec::from_elem(usize::MAX, false);

    // Logical length is large, but backing storage is undersized
    // This leads to out-of-bounds write in unsafe internals
    v.set(0, true);
}
```
#### PoC 2: Overflow via `reserve`
```rust
#![forbid(unsafe_code)]

use smallbitvec::SmallBitVec;

fn main() {
    let mut v = SmallBitVec::new();
    v.push(true);

    // Triggers overflow in capacity computation
    v.reserve(usize::MAX - 10);
}
```

### Impact
- Heap buffer overflow via safe API only
- ASAN-observable heap-buffer-overflow
- Undefined Behavior detectable with Miri (e.g., out-of-bounds indexing due to corrupted metadata)

### Tested on
- rustc 1.96.0-nightly (9602bda1d 2026-04-05)
- Target: x86_64-unknown-linux-gnu
- Build: release
- ASAN: `RUSTFLAGS="-Z sanitizer=address" cargo +nightly run --release`
- Miri: `cargo +nightly miri run --release`
GitHub Security Advisory: GHSA-2f9f-gq7v-9h6m
Package: thrift (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: <= 0.22.0
Patched in: unpatched

Summary: Apache Thrift has a Memory Allocation with Excessive Size Value Vulnerability

Details:
Memory Allocation with Excessive Size Value vulnerability in Apache Thrift.

This issue affects Apache Thrift: before 0.23.0.

Users are recommended to upgrade to version [0.23.0](https://github.com/apache/thrift/releases/tag/v0.23.0), which fixes the issue.
GitHub Security Advisory: GHSA-h9hm-m2xj-4rq9
Package: zebrad (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.4.0
Patched in: 4.4.0

Summary: Zebra has Permanent Block Discovery Halt via Gossip Queue Saturation and Syncer Poisoning

Details:
## Summary

A composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals.

## Severity

**Critical** — This is a Denial of Service vulnerability that requires no authentication, no special privileges, and only a single peer connection. The halt is permanent: the node will never recover without operator intervention.

## Affected Versions

All Zebra versions prior to 4.4.0.

## Description

Zebra discovers new blocks through two complementary paths: a gossip path (peers announce blocks via `inv` messages, triggering individual block downloads) and a syncer path (Zebra periodically queries peers with `FindBlocks`/`FindHeaders` to discover chains of missing blocks). Both paths must function for normal operation.

The gossip path was vulnerable because there was no per-connection rate limit on `inv` messages. A single connection could send enough sequential `inv` messages with fake block hashes to fill the entire gossip download queue in under a millisecond. The `FullQueue` return value was silently ignored, so legitimate block announcements from honest peers were dropped with no warning.

The syncer backup path could be degraded by responding with empty `inv` to `FindBlocks` requests and with `NotFound` to block download requests. Both are valid protocol responses that carried zero misbehavior penalty. The attacker's connection was never banned and never disconnected, allowing the degradation to persist indefinitely.

Combining these two vectors, an attacker could suppress both block discovery paths simultaneously from a single connection, causing the node to fall permanently behind the chain tip.

## Impact

**Denial of Service**

* **Attack Vector:** Network, unauthenticated. Requires only a single TCP peer connection.
* **Effect:** Permanent halt of block discovery. The targeted node falls behind the chain tip and never recovers without operator intervention.
* **Scope:** Any Zebra node reachable by the attacker over the peer-to-peer network.

## Fixed Versions

This issue is fixed in Zebra 4.4.0.

The fix drops connections that send empty responses to `FindBlocks` and `FindHeaders` messages, preventing attackers from degrading the syncer path without consequence.

## Mitigation

Users should upgrade to Zebra 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to protect against this attack.

## Credits

Zebra the researcher who reported this issue through the coordinated disclosure process.
GitHub Security Advisory: GHSA-xv59-967r-8726
Package: openssl (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: >= 0.10.0, < 0.10.79
Patched in: 0.10.79

Summary: rust-openssl vulnerable to heap buffer overflow when encrypting with AES key-wrap-with-padding

Details:
`CipherCtxRef::cipher_update`, `CipherCtxRef::cipher_update_vec`, and `symm::Crypter::update` incorrectly sized output buffers when used with AES key-wrap-with-padding ciphers (`EVP_aes_{128,192,256}_wrap_pad`). For a non-multiple-of-8 input, OpenSSL writes up to 7 bytes past the end of the caller's buffer or Vec, producing attacker-controllable heap corruption when the plaintext length is attacker-influenced.

This only impacts users using AES key-wrap-with-padding ciphers.
GitHub Security Advisory: GHSA-jv4h-j224-23cc
Package: zebrad (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 4.4.0
Patched in: 4.4.0

Summary: Zebra's Block Validator Undercounts Coinbase and P2SH Sigops

Details:
Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (`MAX_BLOCK_SIGOPS`), allowing it to accept blocks that `zcashd` rejects with `bad-blk-sigops`. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while `zcashd` nodes do not.

Two distinct undercounts:

#### A: Coinbase Hidden Legacy Sigops

`zcashd`'s `GetLegacySigOpCount()` includes the coinbase input's `scriptSig`. Zebra's `Sigops` impl skipped the coinbase input entirely, so up to ~98 sigops (the 100-byte coinbase script length cap, less the height prefix) could be hidden inside the coinbase `scriptSig` without being charged against the block limit.

#### B: Aggregate P2SH Sigops.

`zcashd`'s `GetP2SHSigOpCount()` parses each P2SH input's redeem script with `accurate=true` and sums those sigops into the block-wide total via `ConnectBlock`. The check is per-block, not per-transaction, and the limit applies regardless of who mines the offending block — a miner just needs to include enough P2SH-spending transactions whose redeem scripts together exceed 20000 sigops. Zebra computed P2SH sigops only on the mempool-acceptance path (used for ZIP-317 weighting) and never accumulated them during block validation. A block whose aggregate redeem-script sigops exceed 20000 (e.g. 1334 P2SH spends × 15 sigops = 20010) would be accepted by Zebra and rejected by `zcashd`.

### Patches

Fixed in this release:  https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0.

### Workarounds

None. Operators relying on Zebra for consensus should upgrade.

### Resources

- `MAX_BLOCK_SIGOPS` constant inherited from Bitcoin via the Zcash protocol spec's §7.6 catch-all "Other rules inherited from Bitcoin", tracked for explicit documentation in [zcash/zips#568](https://github.com/zcash/zips/issues/568).
- `zcashd` `GetLegacySigOpCount`: <https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L826-L836>
- `zcashd` `GetP2SHSigOpCount`: <https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L840-L852>
- `zcashd` `ConnectBlock` aggregates per-tx sigops and compares against `MAX_BLOCK_SIGOPS`.
GitHub Security Advisory: GHSA-w5p8-4jcx-2j6r
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: imageproc: integer overflow in kernel size check leads to out-of-bounds read

Details:
A bounds verification of a slice storage of a 2-dimensional matrix's coefficients (a kernel) would compare the total size against the product of individual dimensions. This would erroneously cast *after* the multiplication and consequently fail to detect possible violations when overflow occurs.

Afterwards, the individual sizes were trusted to properly constrain coordinates within the matrix to indices valid for the underlying storage. With a crafted `Kernel` object, certain combinations of coordinates could then cause an out-of-bounds access in an `unsafe` function while fulfilling its documented preconditions. The kernel value could be passed to library functions that trusted the preconditions and then performed such reads.
GitHub Security Advisory: GHSA-w5p8-4jcx-2j6r
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.25.0
Patched in: 0.25.1

Summary: imageproc: integer overflow in kernel size check leads to out-of-bounds read

Details:
A bounds verification of a slice storage of a 2-dimensional matrix's coefficients (a kernel) would compare the total size against the product of individual dimensions. This would erroneously cast *after* the multiplication and consequently fail to detect possible violations when overflow occurs.

Afterwards, the individual sizes were trusted to properly constrain coordinates within the matrix to indices valid for the underlying storage. With a crafted `Kernel` object, certain combinations of coordinates could then cause an out-of-bounds access in an `unsafe` function while fulfilling its documented preconditions. The kernel value could be passed to library functions that trusted the preconditions and then performed such reads.
GitHub Security Advisory: GHSA-w5p8-4jcx-2j6r
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.24.0
Patched in: 0.24.1

Summary: imageproc: integer overflow in kernel size check leads to out-of-bounds read

Details:
A bounds verification of a slice storage of a 2-dimensional matrix's coefficients (a kernel) would compare the total size against the product of individual dimensions. This would erroneously cast *after* the multiplication and consequently fail to detect possible violations when overflow occurs.

Afterwards, the individual sizes were trusted to properly constrain coordinates within the matrix to indices valid for the underlying storage. With a crafted `Kernel` object, certain combinations of coordinates could then cause an out-of-bounds access in an `unsafe` function while fulfilling its documented preconditions. The kernel value could be passed to library functions that trusted the preconditions and then performed such reads.
GitHub Security Advisory: GHSA-w5p8-4jcx-2j6r
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.23.1
Patched in: 0.23.1

Summary: imageproc: integer overflow in kernel size check leads to out-of-bounds read

Details:
A bounds verification of a slice storage of a 2-dimensional matrix's coefficients (a kernel) would compare the total size against the product of individual dimensions. This would erroneously cast *after* the multiplication and consequently fail to detect possible violations when overflow occurs.

Afterwards, the individual sizes were trusted to properly constrain coordinates within the matrix to indices valid for the underlying storage. With a crafted `Kernel` object, certain combinations of coordinates could then cause an out-of-bounds access in an `unsafe` function while fulfilling its documented preconditions. The kernel value could be passed to library functions that trusted the preconditions and then performed such reads.
GitHub Security Advisory: GHSA-qg8r-f7x3-25f7
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: imageproc: Out-of-bounds read via NaN coordinates in bilinear/bicubic sampling

Details:
A bounds check was performed in floating points before a cast to the index passed to an unchecked access function. This checked considered `NaN` cases improperly, causing them to succeed the check instead of failing it. The floating point coordinate is under caller control by passing a selected projection matrix.

Carefully controlling the coordinates of an image with no data and one non-zero dimension provides an arbitrary read primitive in the first 32-bits of address space with a Bilinear sampling method.

Using bicubic sampling can result in a read of a few bytes beyond an allocation.

Other out-of-bounds reads may be possible.
GitHub Security Advisory: GHSA-qg8r-f7x3-25f7
Package: imageproc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: = 0.25.0
Patched in: 0.25.1

Summary: imageproc: Out-of-bounds read via NaN coordinates in bilinear/bicubic sampling

Details:
A bounds check was performed in floating points before a cast to the index passed to an unchecked access function. This checked considered `NaN` cases improperly, causing them to succeed the check instead of failing it. The floating point coordinate is under caller control by passing a selected projection matrix.

Carefully controlling the coordinates of an image with no data and one non-zero dimension provides an arbitrary read primitive in the first 32-bits of address space with a Bilinear sampling method.

Using bicubic sampling can result in a read of a few bytes beyond an allocation.

Other out-of-bounds reads may be possible.