CVE-2026-46539 Overview
CVE-2026-46539 is a logic flaw in Nimiq, a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. The vulnerability resides in the BlockInclusionProof::is_block_proven function, which returns true without performing cryptographic verification when get_interlink_hops yields an empty hop list. An attacker submitting transaction inclusion proofs can forge a MacroBlock header for the election block position immediately preceding the election head's epoch and have it accepted as proven. The flaw is tracked under [CWE-345: Insufficient Verification of Data Authenticity]. Nimiq patched the issue in version 1.4.0.
Critical Impact
Attackers can forge MacroBlock headers and have them accepted as cryptographically proven without any hash or signature verification, undermining integrity of the consensus layer.
Affected Products
- Nimiq core-rs-albatross prior to version 1.4.0
- Nimiq Proof-of-Stake protocol implementations relying on BlockInclusionProof
- Downstream nodes and clients consuming transaction inclusion proofs from affected versions
Discovery Timeline
- 2026-06-10 - CVE-2026-46539 published to NVD
- 2026-06-10 - Last updated in NVD database
Technical Details for CVE-2026-46539
Vulnerability Analysis
The vulnerability stems from a control-flow oversight in BlockInclusionProof::is_block_proven. The function is responsible for validating that a referenced block is included in the verified chain history through interlink hops. When get_interlink_hops returns an empty iterator, the verification loop never executes. The function then falls through to a success return, signaling proof validity to callers.
This condition arises specifically when the target block sits at the election block position immediately preceding the election head's epoch. In this case, no interlink hops are produced, and no hash or signature verification occurs. An attacker who can submit transaction inclusion proofs can therefore construct an arbitrary MacroBlock header for that epoch slot and have it accepted as proven.
The impact is limited to integrity: an attacker can convince a node that a forged macro block is part of canonical history for the purpose of transaction inclusion proofs. The flaw does not directly affect confidentiality or availability of node operations.
Root Cause
The root cause is a missing default-deny path in the proof verification logic. The function treats an empty hop list as a vacuously satisfied predicate rather than as an invalid or unprovable state. No cryptographic anchor is checked against the supplied MacroBlock header when no hops are traversed.
Attack Vector
Exploitation occurs over the network. An attacker crafts a transaction inclusion proof that references a block at the election position immediately before the election head's epoch. The forged MacroBlock header is submitted alongside the proof. Because get_interlink_hops yields an empty list for this boundary case, is_block_proven returns true, and the forged header is accepted. Exploitation requires precise alignment with the epoch boundary, which is reflected in the high attack complexity.
No verified proof-of-concept code is published. See the GitHub Security Advisory GHSA-799f-29jm-gr6c and the fix in pull request #3705 for technical details.
Detection Methods for CVE-2026-46539
Indicators of Compromise
- Transaction inclusion proofs that reference MacroBlock headers at the election position immediately preceding the election head's epoch.
- Acceptance of MacroBlock headers that do not match canonical block hashes produced by trusted nodes running version 1.4.0 or later.
- Divergence between local node state and peer consensus regarding macro block contents at epoch boundaries.
Detection Strategies
- Audit running Nimiq node versions and flag any instance below 1.4.0 as exposed to forged proof acceptance.
- Cross-validate inclusion proofs against a node patched to 1.4.0 and alert on discrepancies in accepted MacroBlock headers.
- Inspect application logs around BlockInclusionProof::is_block_proven calls for proofs that succeed with zero interlink hops traversed.
Monitoring Recommendations
- Monitor peer-to-peer traffic for transaction inclusion proof messages targeting epoch-boundary election blocks.
- Track consensus integrity metrics and alert when a node's accepted history diverges from majority peers.
- Log proof verification outcomes with hop counts to detect zero-hop acceptances at suspicious epoch positions.
How to Mitigate CVE-2026-46539
Immediate Actions Required
- Upgrade all Nimiq core-rs-albatross deployments to version 1.4.0 or later without delay.
- Reject and re-verify any transaction inclusion proofs accepted by unpatched nodes against a patched reference node.
- Restrict exposure of unpatched nodes to untrusted peers until the upgrade is complete.
Patch Information
The vendor released the fix in Nimiq core-rs-albatross v1.4.0. The corrective change is documented in pull request #3705, which adds explicit verification when get_interlink_hops returns an empty hop list so that BlockInclusionProof::is_block_proven no longer returns true without cryptographic checks.
Workarounds
- No supported workaround exists short of upgrading to version 1.4.0.
- Operators unable to upgrade immediately should validate proofs out-of-band against a patched node and discard any proof referencing election-boundary positions until upgrade.
# Upgrade Nimiq core-rs-albatross to the patched release
git fetch --tags
git checkout v1.4.0
cargo build --release
# Restart the node service after deploying the patched binary
systemctl restart nimiq-node
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
