Nimiq
by Nimiq
CVEs (6)
| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-33471 | Cri | 0.55 | 9.6 | 0.00 | Apr 22, 2026 | nimiq-block contains block primitives to be used in Nimiq's Rust implementation. `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. Prior to version 1.3.0, 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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available. | |
| CVE-2026-34065 | Hig | 0.42 | 7.5 | 0.00 | Apr 22, 2026 | nimiq-primitives contains primitives (e.g., block, account, transaction) to be used in Nimiq's Rust implementation. Prior to version 1.3.0, 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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available. | |
| CVE-2026-40092 | hig | 0.38 | — | — | May 15, 2026 | ### Impact A malicious network peer can crash any Nimiq full node by publishing a crafted Kademlia DHT record containing a `TaggedSigned<ValidatorRecord, KeyPair>` with a signature field whose byte length is not exactly 64. When the victim node's DHT verifier calls `TaggedSigned::verify`, execution reaches `Ed25519Signature::from_bytes(sig).unwrap()` in the `TaggedPublicKey` implementation for `Ed25519PublicKey`. The `from_bytes` call fails because `ed25519_zebra::Signature::try_from` rejects slices not 64 bytes, and the `unwrap()` panics. The BLS `TaggedPublicKey` implementation correctly returns `false` on error; only the Ed25519 implementation panics. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3708) is formally released as part of [v1.4.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.4.0). ### Workarounds No known workarounds. ### Resources See [PR](https://github.com/nimiq/core-rs-albatross/pull/3708). | |
| CVE-2026-34066 | Med | 0.27 | 5.3 | 0.00 | Apr 22, 2026 | nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. Prior to version 1.3.0, `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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available. | |
| CVE-2026-34064 | Med | 0.27 | 5.3 | 0.00 | Apr 22, 2026 | nimiq-account contains account primitives to be used in Nimiq's Rust implementation. Prior to version 1.3.0, `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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available. | |
| CVE-2026-34062 | Med | 0.27 | 5.3 | 0.00 | Apr 22, 2026 | nimiq-libp2p is a Nimiq network implementation based on libp2p. Prior to version 1.3.0, `MessageCodec::read_request` and `read_response` call `read_to_end()` on inbound substreams, so a remote peer can send only a partial frame and keep the substream open. because `Behaviour::new` also sets `with_max_concurrent_streams(1000)`, the node exposes a much larger stalled-slot budget than the library default. The patch for this vulnerability is formally released as part of v1.3.0. No known workarounds are available. |
- risk 0.55cvss 9.6epss 0.00
nimiq-block contains block primitives to be used in Nimiq's Rust implementation. `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. Prior to version 1.3.0, 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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.
- risk 0.42cvss 7.5epss 0.00
nimiq-primitives contains primitives (e.g., block, account, transaction) to be used in Nimiq's Rust implementation. Prior to version 1.3.0, 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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.
- risk 0.38cvss —epss —
### Impact A malicious network peer can crash any Nimiq full node by publishing a crafted Kademlia DHT record containing a `TaggedSigned<ValidatorRecord, KeyPair>` with a signature field whose byte length is not exactly 64. When the victim node's DHT verifier calls `TaggedSigned::verify`, execution reaches `Ed25519Signature::from_bytes(sig).unwrap()` in the `TaggedPublicKey` implementation for `Ed25519PublicKey`. The `from_bytes` call fails because `ed25519_zebra::Signature::try_from` rejects slices not 64 bytes, and the `unwrap()` panics. The BLS `TaggedPublicKey` implementation correctly returns `false` on error; only the Ed25519 implementation panics. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3708) is formally released as part of [v1.4.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.4.0). ### Workarounds No known workarounds. ### Resources See [PR](https://github.com/nimiq/core-rs-albatross/pull/3708).
- risk 0.27cvss 5.3epss 0.00
nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. Prior to version 1.3.0, `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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.
- risk 0.27cvss 5.3epss 0.00
nimiq-account contains account primitives to be used in Nimiq's Rust implementation. Prior to version 1.3.0, `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. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.
- risk 0.27cvss 5.3epss 0.00
nimiq-libp2p is a Nimiq network implementation based on libp2p. Prior to version 1.3.0, `MessageCodec::read_request` and `read_response` call `read_to_end()` on inbound substreams, so a remote peer can send only a partial frame and keep the substream open. because `Behaviour::new` also sets `with_max_concurrent_streams(1000)`, the node exposes a much larger stalled-slot budget than the library default. The patch for this vulnerability is formally released as part of v1.3.0. No known workarounds are available.