nimiq-blockchain CVE-2026-46543
MEDIUMSeverity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Lifecycle Timeline
2DescriptionNVD
Impact
A remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block".
Patches
The patch for this vulnerability is formally released as part of v1.5.0.
Workarounds
No Workaround, although requesting the genesis batch set is not used during normal operation.
Resources
See PR.
AnalysisAI
Unauthenticated remote crash of Nimiq full nodes running nimiq-blockchain versions before 1.5.0 is achievable by any network peer sending a single crafted RequestBatchSet message referencing the genesis block hash. The node's batch set handler iterates backward through macro blocks without a lower-bound guard, causing a Rust panic in Policy::macro_block_before when iteration reaches genesis, immediately terminating the process. No CISA KEV listing and no public exploit code exist at time of analysis; however, the attack requires no authentication and trivially low complexity, posing a real availability threat to any reachable full node.
Technical ContextAI
The affected component is the nimiq-blockchain Rust crate (pkg:rust/nimiq-blockchain) within the Nimiq Albatross proof-of-stake consensus implementation (core-rs-albatross). The root cause is CWE-617 (Reachable Assertion): Rust's panic mechanism - invoked either via an explicit panic! or via .expect() on a Result - can be triggered by attacker-controlled input. The RequestBatchSet message handler calls get_epoch_chunks, which iterates backward through macro blocks via Policy::macro_block_before. That function unconditionally panics when called with the genesis block number, as there are no macro blocks before genesis. Additionally, two prove_num_leaves calls used .expect('Failed to prove history size') rather than proper Result propagation, meaning any failure in those paths also crashed the node process. PR #3745 applies two fixes visible in the diff: a boundary guard (if prev_macro_block_number <= Policy::genesis_block_number() { break; }) added to chain_store.rs to halt backward iteration at genesis, and conversion of .expect() calls in consensus/src/messages/handlers.rs to graceful error returns using the ? operator with the new BatchSetError::CouldntProduceHistorySizeProof variant.
RemediationAI
Upgrade nimiq-blockchain to version 1.5.0, the vendor-released patch confirmed in the GitHub advisory (GHSA-vghx-352f-93jm) and available at https://github.com/nimiq/core-rs-albatross/releases/tag/v1.5.0. The fix is delivered via commit 8e8b0abdb1b66f5e9b25b3833879f05c173a5596 (PR #3745). The vendor confirms no software workaround exists. As a partial operational mitigation, network-layer filtering or rate-limiting of RequestBatchSet messages from untrusted or unauthenticated peers - where the node's deployment architecture permits - could reduce exposure; however, this would also impair legitimate batch sync operations and is not a substitute for patching. The vendor notes that genesis batch set requests do not occur during normal network operation, so anomaly detection or logging on this specific message type is a viable detection signal while upgrade is pending.
Same weakness CWE-617 – Reachable Assertion
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-vghx-352f-93jm