CVE-2026-34066: Nimiq Blockchain DOS Vulnerability

CVE-2026-34066 Overview

CVE-2026-34066 is an improper input validation vulnerability in nimiq-blockchain, the persistent block storage component for Nimiq's Rust implementation. Prior to version 1.3.0, the HistoryStore::put_historic_txns function uses an assert! macro to enforce invariants about HistoricTransaction.block_number, requiring it to be within the macro block being pushed and within the same epoch. During history sync operations, a malicious peer can influence the history: &[HistoricTransaction] input passed into Blockchain::push_history_sync. By supplying a malformed history list that violates these invariants, an attacker can trigger a panic and crash the node.

Critical Impact

A remote attacker can cause a denial of service condition by crashing Nimiq blockchain nodes during history synchronization, potentially disrupting network consensus and availability.

Affected Products

• nimiq-blockchain (core-rs-albatross) versions prior to 1.3.0
• Nimiq Rust implementation nodes performing history sync

Discovery Timeline

• April 22, 2026 - CVE-2026-34066 published to NVD
• April 22, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34066

Vulnerability Analysis

This vulnerability stems from improper input validation in the history synchronization workflow. The extend_history_sync function calls this.history_store.add_to_history(..) before comparing the computed history root against the macro block header (block.history_root()). This ordering means the assert! macro checking block number invariants can trigger a panic before the later rejection checks have an opportunity to run.

The vulnerability is exploitable over the network during peer-to-peer history synchronization, though successful exploitation requires user interaction in the form of connecting to or accepting connections from a malicious peer. The impact is limited to availability—there is no confidentiality or integrity compromise, but the denial of service can disrupt node operations.

Root Cause

The root cause is the use of assert! for enforcing input invariants rather than returning an error result. In Rust, assert! panics when its condition is false, which is appropriate for internal logic errors but not for validating untrusted external input. The HistoricTransaction.block_number field must be within the macro block being pushed and within the same epoch, but this check occurs via assertion before the history root validation can reject invalid data.

Attack Vector

The attack is network-based and targets the history synchronization mechanism. An attacker operating a malicious peer can craft a HistoricTransaction list with block numbers that fall outside the expected ranges. When a victim node initiates history sync with the malicious peer:

1. The victim calls Blockchain::push_history_sync with attacker-controlled history data
2. extend_history_sync processes the data and calls history_store.add_to_history(..)
3. HistoryStore::put_historic_txns invokes assert! on the block number invariants
4. The malformed block numbers cause the assertion to fail, triggering a panic
5. The node crashes before subsequent validation checks can reject the malicious input

The vulnerability requires the attacker to be a network peer during history sync, which introduces some complexity but remains achievable in a public blockchain network.

Detection Methods for CVE-2026-34066

Indicators of Compromise

• Unexpected node crashes or panics during history synchronization operations
• Panic messages in logs referencing HistoryStore::put_historic_txns or assertion failures
• Repeated connection attempts from the same peer IP addresses followed by node failures
• Pattern of node restarts coinciding with history sync attempts

Detection Strategies

• Monitor node logs for panic messages containing assertion failure references in the history store module
• Implement alerting on repeated node crashes during synchronization phases
• Track peer connections and correlate with crash events to identify potentially malicious peers
• Review historical crash dumps for stack traces pointing to put_historic_txns or extend_history_sync

Monitoring Recommendations

• Enable detailed logging for history synchronization operations
• Deploy watchdog processes to detect and alert on unexpected node terminations
• Implement peer reputation scoring to identify and blacklist peers associated with crash events
• Set up automated restart with incremental backoff for affected nodes

How to Mitigate CVE-2026-34066

Immediate Actions Required

• Upgrade nimiq-blockchain (core-rs-albatross) to version 1.3.0 or later immediately
• Review node logs for evidence of exploitation attempts or unexplained crashes
• Consider temporarily disabling history sync with untrusted peers if upgrade is not immediately possible
• Monitor network for suspicious peer behavior during synchronization

Patch Information

The fix for this vulnerability is included in version 1.3.0 of core-rs-albatross. The patch replaces the assert! macro with proper error handling that returns a result rather than panicking on invalid input. Technical details of the fix can be reviewed in the GitHub commit and the pull request discussion. The security advisory GHSA-j99g-7rqw-q9jg provides additional context.

Workarounds

• No official workarounds are available for this vulnerability
• Upgrading to version 1.3.0 or later is the only supported remediation
• Operators may consider network-level filtering of untrusted peers as a temporary measure, though this may impact functionality
• Running nodes in supervised environments with automatic restart can reduce downtime impact but does not prevent exploitation

# Upgrade to patched version
cd core-rs-albatross
git fetch --tags
git checkout v1.3.0
cargo build --release