CVE-2026-33184
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk38th percentile - higher than 38% of all known CVEs
Summary
In nimiq/core-rs-albatross (a Rust implementation of the Nimiq Proof-of-Stake protocol) prior to version 1.3.0, the handshake handler accepts a peer-supplied limit of 0 and stores it unchanged. In the HandshakeAck path, limit 0 returns zero contacts, appearing benign. Later, in the Established state, computing self.peer_list_limit.unwrap() as usize - 1 with limit 0 wraps to usize::MAX, causing a panic when attempting memory allocation.
Risk Assessment
An attacker can remotely crash a Nimiq node, causing network disruption and potential loss of funds or consensus failure.
Recommendation
Upgrade nimiq/core-rs-albatross to version 1.3.0, which contains the fix.
Other vulnerabilities in nimiq/core-rs-albatross
See all- CVE-2026-28402High
In versions prior to 1.2.2, the nimiq/core-rs-albatross library has a vulnerability that allows a malicious or compromised validator to publish a macro block proposal with a mismatched `header.body_root`. This can lead to validator crashes due to verification mismatches.
- CVE-2026-34061Medium
nimiq/core-rs-albatross prior to version 1.3.0 contains a vulnerability where an elected validator proposer can send an election macro block whose header.interlink does not match the canonical next interlink. Honest validators accept the proposal because verify_macro_block_proposal() does not check the interlink binding for election blocks. The same finalized block is later rejected by verify_block() with InvalidInterlink, but this happens after Tendermint decides, potentially causing consensus issues.
Original NVD description (English source)
nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.3.0, the discovery handler accepts a peer-controlled limit during handshake and stores it unchanged. The immediate HandshakeAck path then honors limit = 0 and returns zero contacts, which makes the session look benign. Later, after the same session reaches Established, the periodic update path computes self.peer_list_limit.unwrap() as usize - 1. With limit = 0, that wraps to usize::MAX and then in rand 0.9.2, choose_multiple() immediately attempts Vec::with_capacity(amount), which deterministically panics with capacity overflow. This issue has been patched in version 1.3.0.