CVE-2026-46540
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk18th percentile - higher than 18% of all known CVEs
Summary
Nimiq (Rust implementation) prior to version 1.4.0 has a bug in LightBlockchain::rebranch() – when switching to a chain with a macro block, it does not update macro_head, election_head, or current_validators. This causes incorrect verification of subsequent blocks and stalls the light client's chain progression.
Risk Assessment
An attacker can exploit this to stall the light client's synchronization or force acceptance of invalid blocks, compromising chain integrity.
Recommendation
Upgrade Nimiq to version 1.4.0. Light client users should apply the patch immediately.
Other vulnerabilities in Nimiq
See all- CVE-2026-46369High
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Through 1.5.0, the validity store uses a strict lower-bound comparison that expires a stored transaction too early relative to Transaction::is_valid_at, allowing a remote attacker to replay the same signed transaction during a blocks_per_batch minus one block window and cause the sender and recipient balances to be updated twice. This issue is fixed in version 1.5.1.
- CVE-2026-46545High
A remote, unauthenticated denial-of-service vulnerability in Nimiq prior to version 1.5.0 allows any state-sync peer to crash any node performing state synchronization via MerkleRadixTrie::put_chunk.
- CVE-2026-46543Medium
In Nimiq prior to version 1.5.0, 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 and panics when reaching the genesis block number.
- CVE-2026-46542Medium
In Nimiq (Rust implementation of Nimiq Proof-of-Stake protocol) before version 1.4.0, a denial-of-service vulnerability exists in the Ed25519 multisig delinearization code. An invalid public key can cause a panic and crash the process. Fixed in version 1.4.0.
- CVE-2026-46541High
A vulnerability in the Rust implementation of Nimiq before version 1.4.0 causes the DhtResults accumulator in handle_dht_get() to be initialized only after the first DHT record passes verification. If the first record fails (from a malicious node), all subsequent valid records are discarded.
- CVE-2026-46539Medium
In Nimiq before version 1.4.0, a logic flaw in BlockInclusionProof::is_block_proven causes it to return true without cryptographic verification when the hop list is empty. An attacker can forge a MacroBlock header for a specific epoch position and have it accepted as proven.
- CVE-2026-44505Medium
Nimiq before version 1.4.0 has a vulnerability in DHT GET query handling in the network-libp2p component. When a peer returns a found record and DHT verification fails, handle_dht_get returns without completing the oneshot and without cleaning up query state, causing Network::dht_get to hang indefinitely.
Original NVD description (English source)
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, when LightBlockchain::rebranch() adopts a fork chain whose tip is a macro block (checkpoint or election), it only updates self.head but fails to update self.macro_head, self.election_head, self.current_validators, or store the election header in the chain_store. This is in direct contrast with the full Blockchain::rebranch() at blockchain/src/blockchain/push.rs:504-518, which correctly updates all macro/election state when the new head is a macro block. After a rebranch to a macro block, the stale macro_head causes subsequent macro blocks pushed via push() to be verified against the wrong predecessor via verify_macro_successor(&this.macro_head). If the rebranch target was an election block, the stale current_validators causes every subsequent block to fail verify_validators(), completely stalling the light client's chain progression. This issue has been patched in version 1.4.0.