CVE-2026-46539: Nimiq BlockInclusionProof Logic Flaw Enables Forged Block Headers

Technical summary

CVE-2026-46539 describes a logic flaw in the BlockInclusionProof::is_block_proven function within Nimiq's Albatross consensus implementation. When get_interlink_hops returns an empty list (occurring when the target block is positioned at the election block immediately preceding the election head's epoch), the function returns true without executing any cryptographic verification. This allows an attacker to forge MacroBlock headers for that epoch position, and these forged headers will be accepted as cryptographically proven despite lacking valid hash or signature verification. The vulnerability affects the proof-of-stake protocol's core validation layer.

Business impact

For Nimiq network participants and exchanges supporting the platform, this vulnerability could undermine transaction finality and block consensus. An attacker capable of forging block headers at specific epoch positions could introduce invalid transactions into the ledger, create forks, or double-spend assets. While the CVSS score reflects medium severity and exploitation requires specific network conditions, the integrity impact on a blockchain network is severe because it compromises the cryptographic guarantees that blockchain security rests upon. Users and custodians relying on Nimiq for value settlement face degraded assurance of transaction validity.

Affected systems

Nimiq versions prior to 1.4.0 are vulnerable. This includes all Nimiq nodes and clients running earlier versions that validate block proofs. Any service or exchange using Nimiq for transaction settlement or blockchain interaction is affected until upgraded. The vulnerability is specific to Nimiq's implementation and does not affect other blockchain platforms or consensus protocols.

Exploitability

Exploitation requires an attacker to construct a malicious transaction inclusion proof and trigger validation at the specific blockchain position where interlink hops are empty. This means exploitation is not trivial—it depends on precise timing relative to election block epochs and requires network-level access to propagate forged blocks. The CVSS vector (AC:H) reflects this elevated complexity, making attacks possible but not straightforward. However, once the conditions are met, no cryptographic material is needed; the proof is accepted purely by logic, making it deterministic if conditions align.

Remediation

Upgrade to Nimiq version 1.4.0 or later, which corrects the BlockInclusionProof::is_block_proven logic to perform cryptographic verification regardless of whether the interlink hop list is empty. All node operators and service providers should prioritize this patch to restore full proof validation integrity.

Patch guidance

Apply version 1.4.0 of Nimiq as soon as feasible. Review your deployment method (whether running from source, package managers, or container images) and follow Nimiq's official release documentation to ensure a clean upgrade. For production networks, coordinate upgrades across validator and full-node operators to prevent consensus splits during the transition. Verify that the upgraded version is genuinely 1.4.0 by checking release signatures and hashes against official Nimiq repositories.

Detection guidance

Monitor for rejected or suspicious MacroBlock headers during election block epochs, particularly at positions where block validation logs show no cryptographic verification steps executed. Review node consensus logs for forks or validation disputes at election boundaries. Implement monitoring for BlockInclusionProof validation calls; a high rate of accepted proofs with empty interlink hops in a short timeframe may indicate exploitation attempts. Network-level observation of block header propagation anomalies during epoch transitions can also surface attack attempts.

Why prioritize this

While the CVSS score is medium (5.9), the vulnerability targets the blockchain's consensus layer, where integrity failures have outsized consequences. The logic flaw is deterministic and does not require sophisticated cryptanalysis—it is a simple code path that bypasses validation. For any organization running Nimiq infrastructure, this should be treated as a high-priority integrity issue despite the moderate numerical score. The window of vulnerability is bounded to specific epoch positions, which limits attack surface but does not eliminate risk. Patch immediately if you operate Nimiq nodes or accept Nimiq transactions.

Risk score, explained

The CVSS 3.1 score of 5.9 (MEDIUM) reflects a network-accessible attack with no privileges required, but elevated complexity due to the need to trigger the vulnerability at the correct blockchain position. The integrity impact is high (forged blocks), but there is no confidentiality or availability impact in the classic sense—the attack does not leak data or crash nodes, it compromises transaction validity. From a blockchain-specific perspective, integrity compromise at the consensus layer warrants treating this as a critical business risk despite the numeric MEDIUM rating. Security teams should not anchor decisions solely on CVSS; context matters significantly.

Frequently asked questions