deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wh8p-h9hw-x2mc
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-252: Unchecked Return Value
Vulnerable versions: <= 0.8.0
Patched in: unpatched

Summary: uutils coreutils has an Unchecked Return Value Issue

Details:
The dd utility in uutils coreutils suppresses errors during file truncation operations by unconditionally calling Result::ok() on truncation attempts. While intended to mimic GNU behavior for special files like /dev/null, the uutils implementation also hides failures on regular files and directories caused by full disks or read-only file systems. This can lead to silent data corruption in backup or migration scripts, as the utility may report a successful operation even when the destination file contains old or garbage data.
GitHub Security Advisory: GHSA-xf75-659h-cgg5
Package: coreutils (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: <= 0.8.0
Patched in: unpatched

Summary: uutils coreutils has a Link Following Issue

Details:
A vulnerability in the tail utility of uutils coreutils allows for the exfiltration of sensitive file contents when using the --follow=name option. Unlike GNU tail, the uutils implementation continues to monitor a path after it has been replaced by a symbolic link, subsequently outputting the contents of the link's target. In environments where a privileged user (e.g., root) monitors a log directory, a local attacker with write access to that directory can replace a log file with a symlink to a sensitive system file (such as /etc/shadow), causing tail to disclose the contents of the sensitive file.
GitHub Security Advisory: GHSA-hwhf-8p2f-45wr
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-176: Improper Handling of Unicode Encoding
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: coreutils' comm utility silently corrupts data by performing lossy UTF-8 conversion on all output lines

Details:
The comm utility in uutils coreutils silently corrupts data by performing lossy UTF-8 conversion on all output lines. The implementation uses String::from_utf8_lossy(), which replaces invalid UTF-8 byte sequences with the Unicode replacement character (U+FFFD). This behavior differs from GNU comm, which processes raw bytes and preserves the original input. This results in corrupted output when the utility is used to compare binary files or files using non-UTF-8 legacy encodings.
GitHub Security Advisory: GHSA-hj9r-8pfm-rmjj
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: uutils coreutils has an Issue With its Always-Incorrect Control Flow Implementation

Details:
The cut utility in uutils coreutils incorrectly handles the -s (only-delimited) option when a newline character is specified as the delimiter. The implementation fails to verify the only_delimited flag in the cut_fields_newline_char_delim function, causing the utility to print non-delimited lines that should have been suppressed. This can lead to unexpected data being passed to downstream scripts that rely on strict output filtering.
GitHub Security Advisory: GHSA-2cxp-xq3c-mjxx
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-377: Insecure Temporary File
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: uutils coreutils' mktemp utility doesn't properly handle an empty TMPDIR environment variable

Details:
The mktemp utility in uutils coreutils fails to properly handle an empty TMPDIR environment variable. Unlike GNU mktemp, which falls back to /tmp when TMPDIR is an empty string, the uutils implementation treats the empty string as a valid path. This causes temporary files to be created in the current working directory (CWD) instead of the intended secure temporary directory. If the CWD is more permissive or accessible to other users than /tmp, it may lead to unintended information disclosure or unauthorized access to temporary data.
GitHub Security Advisory: GHSA-w8m4-4v35-v6x3
Package: coreutils (RUST)
Severity: HIGH (CVSS 7.1)
CWE: CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: <= 0.8.0
Patched in: unpatched

Summary: uutils coreutils allows unauthorized modification of permissions on existing files

Details:
A vulnerability in uutils coreutils mkfifo allows for the unauthorized modification of permissions on existing files. When mkfifo fails to create a FIFO because a file already exists at the target path, it fails to terminate the operation for that path and continues to execute a follow-up set_permissions call. This results in the existing file's permissions being changed to the default mode (often 644 after umask), potentially exposing sensitive files such as SSH private keys to other users on the system.
GitHub Security Advisory: GHSA-vp6q-mv9j-j428
Package: coreutils (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-253: Incorrect Check of Function Return Value
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: uutils coreutils incorrectly handles exit codes when processing multiple files

Details:
The recursive mode (-R) of the chmod utility in uutils coreutils incorrectly handles exit codes when processing multiple files. The final return value is determined solely by the success or failure of the last file processed. This allows the command to return an exit code of 0 (success) even if errors were encountered on previous files, such as 'Operation not permitted'. Scripts relying on these exit codes may proceed under a false sense of success while sensitive files remain with restrictive or incorrect permissions.
GitHub Security Advisory: GHSA-88ch-q68x-36v7
Package: coreutils (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-253: Incorrect Check of Function Return Value
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: uutils coreutils has an Incorrect Check of Function Return Value

Details:
A flaw in the ChownExecutor used by uutils coreutils chown and chgrp causes the utilities to return an incorrect exit code during recursive operations. The final exit code is determined only by the last file processed. If the last operation succeeds, the command returns 0 even if earlier ownership or group changes failed due to permission errors. This can lead to security misconfigurations where administrative scripts incorrectly assume that ownership has been successfully transferred across a directory tree.
GitHub Security Advisory: GHSA-9gqx-53gp-c8g3
Package: coreutils (RUST)
Severity: HIGH (CVSS 7.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: uutils coreutils allows users to bypass the --preserve-root safety mechanism

Details:
A vulnerability in the chmod utility of uutils coreutils allows users to bypass the --preserve-root safety mechanism. The implementation only validates if the target path is literally / and does not canonicalize the path. An attacker or accidental user can use path variants such as /../ or symbolic links to execute destructive recursive operations (e.g., chmod -R 000) on the entire root filesystem, leading to system-wide permission loss and potential complete system breakdown.
GitHub Security Advisory: GHSA-38c5-483c-4qqp
Package: grid (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.17.0, <= 1.0.0
Patched in: 1.0.1

Summary: Grid: Integer Overflow in Grid::expand_rows Leads to Safe-API Undefined Behavior

Details:
### Summary
An integer overflow in `Grid::expand_rows()` can corrupt the relationship between the grid’s logical dimensions and its backing storage. After the internal invariant is broken, the safe API get() may invoke get_unchecked() with an invalid index, resulting in Undefined Behavior.

### Details
Tested Version: grid = "1.0.0"

expand_rows() computes the new backing length using unchecked arithmetic:

`self.data.len() + rows * self.cols
`

If rows * self.cols or the subsequent addition overflows usize, the result wraps in release builds and self.data may be resized to a length much smaller than logically required.

After that, if the grid is in ColumnMajor order, the function performs in-place rotation using indices derived from:

```
let total_rows = self.rows + row_added;
let col_idx = i * total_rows;
self.data[col_idx..col_idx + total_rows + i].rotate_right(i);
```

These computations also rely on the assumption that the backing storage has been resized to the correct length. Once the earlier length computation has wrapped, this assumption no longer holds, so the function may operate on invalid ranges or otherwise enter an inconsistent state.

Finally, the function updates logical metadata with:

`self.rows += rows;
`

As a result, the grid can end up with logical dimensions that no longer match the actual backing storage. Subsequent safe API calls such as get() may then rely on corrupted metadata and reach unsafe internal accesses, resulting in invalid unchecked access and Undefined Behavior.

### PoC
```rust
#![forbid(unsafe_code)]

use grid::Grid;

fn main() {
    let mut g = Grid::from_vec(vec![1u8, 2u8], 2);

    g.expand_rows(usize::MAX / 2);

    g.get(0, 0); // triggers UB in get_unchecked
}
```

### Impact
- Invalid unchecked access (`get_unchecked`) reached via safe API
- Confirmed by Miri (release-mode):

```
error: Undefined Behavior: `assume` called with `false`
   --> ..../grid-1.0.0/src/lib.rs:527:9
    |
527 |         self.data.get_unchecked(index)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here

```
- Potential crash / denial of service in release-builds (e.g., SIGSEGV, Illegal instruction)
- Violates Rust’s safety guarantees despite using only safe code
GitHub Security Advisory: GHSA-pqf5-4pqq-29f5
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-131: Incorrect Calculation of Buffer Size, CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.9.27, < 0.10.78
Patched in: 0.10.78

Summary: rust-openssl: Deriver::derive and PkeyCtxRef::derive can overflow short buffers on OpenSSL 1.1.1

Details:
`Deriver::derive` (and `PkeyCtxRef::derive`) sets `len = buf.len()` and passes it as the in/out length to `EVP_PKEY_derive`, relying on OpenSSL to honor it. On OpenSSL 1.1.x, X25519, X448, DH and HKDF-extract  ignore the incoming `*keylen`, unconditionally writing the full shared secret (32/56/prime-size bytes). A caller passing a short slice gets a heap/stack overflow from safe code. OpenSSL 3.x providers do check, so this only impacts older OpenSSL.
GitHub Security Advisory: GHSA-xmgf-hq76-4vx2
Package: openssl (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: >= 0.9.0, < 0.10.78
Patched in: 0.10.78

Summary: rust-opennssl has an Out-of-bounds read in PEM password callback when returning an oversized length

Details:
The `*_from_pem_callback` APIs did not validate the length returned by the user's callback. A password callback that returns a value larger than the buffer it was given can cause some versions of OpenSSL to over-read this buffer. OpenSSL 3.x is not affected by this.
GitHub Security Advisory: GHSA-8c75-8mhr-p7r9
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.10.24, < 0.10.78
Patched in: 0.10.78

Summary: rust-openssl has incorrect bounds assertion in aes key wrap

Details:
### Summary
``aes::unwrap_key()`` has an incorrect bounds assertion on the out buffer size, which can lead to out-of-bounds write.

### Details
``aes::unwrap_key()`` contains an incorrect assertion: it checks that `out.len() + 8 <= in_.len()`, but this condition is reversed. The intended invariant is `out.len() >= in_.len() - 8`, ensuring the output buffer is large enough.

Because of the inverted check, the function only accepts buffers at or below the minimum required size and rejects larger ones. If a smaller buffer is provided the function will write past the end of `out` by `in_.len() - 8 - out.len()` bytes, causing an out-of-bounds write from a safe public function.

### Impact
Vulnerable applications using AES keywrap and allowing attacker controlled buffer sizes could have an attacker trigger an out-of-bounds write.
GitHub Security Advisory: GHSA-ghm9-cr32-g9qj
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-121: Stack-based Buffer Overflow
Vulnerable versions: >= 0.10.39, < 0.10.78
Patched in: 0.10.78

Summary: rust-openssl: rustMdCtxRef::digest_final() writes past caller buffer with no length check

Details:
`EVP_DigestFinal()` always writes `EVP_MD_CTX_size(ctx)` to the `out` buffer. If `out` is smaller than that, `MdCtxRef::digest_final()` writes past its end, usually corrupting the stack. This is reachable from safe Rust.
GitHub Security Advisory: GHSA-hppc-g8h3-xhp3
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-126: Buffer Over-read, CWE-130: Improper Handling of Length Parameter Inconsistency
Vulnerable versions: >= 0.9.24, < 0.10.78
Patched in: 0.10.78

Summary: rust-openssl: Unchecked callback length in PSK/cookie trampolines leaks adjacent memory to peer

Details:
The FFI trampolines behind `SslContextBuilder::set_psk_client_callback`, `set_psk_server_callback`, `set_cookie_generate_cb`,  and `set_stateless_cookie_generate_cb` forwarded the user closure's returned usize directly to OpenSSL without checking it against the `&mut [u8]` that was handed to the closure. This can lead to buffer overflows and other unintended consequences.
GitHub Security Advisory: GHSA-cq8v-f236-94qc
Package: rand (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.7.0, < 0.8.6
Patched in: 0.8.6

Summary: Rand is unsound with a custom logger using rand::rng()

Details:
It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:

- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed

`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
GitHub Security Advisory: GHSA-cq8v-f236-94qc
Package: rand (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.9.0, < 0.9.3
Patched in: 0.9.3

Summary: Rand is unsound with a custom logger using rand::rng()

Details:
It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:

- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed

`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
GitHub Security Advisory: GHSA-j99g-7rqw-q9jg
Package: nimiq-blockchain (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-617: Reachable Assertion, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-blockchain: Peer-triggerable panic during history sync

Details:
### Impact
`HistoryStore::put_historic_txns` uses an `assert!` to enforce invariants about `HistoricTransaction.block_number` (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the `history: &[HistoricTransaction]` input passed into `Blockchain::push_history_sync`, and a malformed history list can violate these invariants and trigger a panic.

`extend_history_sync` calls `this.history_store.add_to_history(..)` before comparing the computed history root against the macro block header (`block.history_root()`), so the panic can happen before later rejection checks run.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/6f5511309c199d84b012fe6b9aba7e5582892c50) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.
GitHub Security Advisory: GHSA-pf4j-pf3w-95f9
Package: nimiq-transaction (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-transaction: UpdateValidator transactions allows voting key change without proof-of-knowledge

Details:
### Impact
The staking contract accepts `UpdateValidator` transactions that set `new_voting_key=Some(...)` while omitting `new_proof_of_knowledge`. this skips the proof-of-knowledge requirement that is needed to prevent BLS rogue-key attacks when public keys are aggregated.

Because tendermint macro block justification verification aggregates validator voting keys and verifies a single aggregated BLS signature against that aggregate public key, a rogue-key voting key in the validator set can allow an attacker to forge a quorum-looking justification while only producing a single signature.

While the impact is critical, the exploitability is low: The voting keys are fixed for the epoch, so the attacker would need to know the next epoch validator set (chosen through VRF), which is unlikely.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/e7f0ab7d2115e17d6e5548ddc60f10df1a5d645f) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.
GitHub Security Advisory: GHSA-264v-m8fm-76jm
Package: nimiq-transaction (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-transaction: Panic via `HistoryTreeProof` length mismatch

Details:
### Impact
`HistoryTreeProof::verify` panics on a malformed proof where `history.len() != positions.len()` due to `assert_eq!(history.len(), positions.len())`. 

The proof object is derived from untrusted p2p responses (`ResponseTransactionsProof.proof`) and is therefore attacker-controlled at the network boundary until validated. A malicious peer could trigger a crash by returning a crafted inclusion proof with a length mismatch.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/6ff0800e8e031363e787c827d8d033e5694e4e6a) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds know.
GitHub Security Advisory: GHSA-7c4j-2m43-2mgh
Package: nimiq-primitives (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-252: Unchecked Return Value, CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-primitives: Node crash due to missing interlink validation in election macro block proposals

Details:
### Impact
An untrusted p2p peer can cause a node to panic by announcing an election macro block whose `validators` set contains an invalid compressed BLS voting key.

Hashing an election macro header hashes `validators` and reaches `Validators::voting_keys()`, which calls `validator.voting_key.uncompress().unwrap()` and panics on invalid bytes.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/e10eaebcd7774e5da6d0ff5e88ed13503474f0ff) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.
GitHub Security Advisory: GHSA-vc34-39q2-m6q3
Package: nimiq-account (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-191: Integer Underflow (Wrap or Wraparound)
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-account: Vesting insufficient funds error can panic

Details:
### Impact
`VestingContract::can_change_balance` returns `AccountError::InsufficientFunds` when `new_balance < min_cap`, but it constructs the error using `balance: self.balance - min_cap`. `Coin::sub` panics on underflow, so if an attacker can reach a state where `min_cap > balance`, the node crashes while trying to return an error.

The `min_cap > balance` precondition is attacker-reachable because the vesting contract creation data (32-byte format) allows encoding `total_amount` without validating `total_amount <= transaction.value` (the real contract balance). After creating such a vesting contract, the attacker can broadcast an outgoing transaction to trigger the panic during mempool admission and block processing.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/4d01946f0b3d6c6e31786f91cdfb3eb902908da0) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.
GitHub Security Advisory: GHSA-6973-8887-87ff
Package: nimiq-block (RUST)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-20: Improper Input Validation, CWE-190: Integer Overflow or Wraparound, CWE-345: Insufficient Verification of Data Authenticity, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: nimiq-block has skip block quorum bypass via out-of-range BitSet indices & u16 truncation

Details:
### Impact
`SkipBlockProof::verify` computes its quorum check using `BitSet.len()`, then iterates `BitSet` indices and casts each `usize` index to `u16` (`slot as u16`) for slot lookup. If an attacker can get a `SkipBlockProof` verified where `MultiSignature.signers` contains out-of-range indices spaced by 65536, these indices inflate `len()` but collide onto the same in-range `u16` slot during aggregation.

This makes it possible for a malicious validator with far fewer than `2f+1` real signer slots to pass skip block proof verification by multiplying a single BLS signature by the same factor.

### Patches
[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3657) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.