CVE-2026-35468: Nimiq Core-rs-albatross DOS Vulnerability

CVE-2026-35468 Overview

CVE-2026-35468 is a Denial of Service vulnerability in nimiq/core-rs-albatross, a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.3.0, two peer-facing consensus request handlers incorrectly assume that the history index is always available, directly calling blockchain.history_store.history_index().unwrap() without proper error handling. This assumption is fundamentally incorrect because HistoryStoreProxy::history_index() explicitly returns None for the valid HistoryStoreProxy::WithoutIndex state.

When a full node is syncing or otherwise running without the history index, a remote attacker can send RequestTransactionsProof or RequestTransactionReceiptsByAddress messages to trigger an Option::unwrap() panic on the request path, causing the node to crash.

Critical Impact

Remote attackers can crash Nimiq full nodes during synchronization or when running without history index by sending specially crafted consensus requests, potentially disrupting blockchain network operations.

Affected Products

• nimiq core-rs-albatross versions prior to 1.3.0
• Nimiq full nodes operating in sync mode or without history index enabled

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-35468 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-35468

Vulnerability Analysis

This vulnerability stems from unsafe handling of an optional return value in Rust code. The HistoryStoreProxy type has two valid states: one with an available history index and one without (WithoutIndex). The history_index() method correctly returns Option<&HistoryIndex>, returning None when the proxy is in the WithoutIndex state.

However, two peer-facing request handlers—those processing RequestTransactionsProof and RequestTransactionReceiptsByAddress messages—call .unwrap() on this Option without checking for None. In Rust, calling .unwrap() on a None value causes an immediate panic, terminating the current thread or process.

This vulnerability can be exploited remotely over the network without authentication. An attacker simply needs to identify a Nimiq full node that is currently syncing or configured without the history index, then send one of the vulnerable request types to trigger the panic. The attack requires no special privileges and no user interaction.

Root Cause

The root cause is CWE-252: Unchecked Return Value. The consensus request handlers fail to properly handle the None case returned by HistoryStoreProxy::history_index(). Rather than gracefully handling nodes operating in WithoutIndex mode by returning an appropriate error response or simply not providing the requested data, the code uses .unwrap() which panics on None values. This is a common pattern error in Rust where developers assume certain conditions will always be true without properly validating those assumptions.

Attack Vector

The attack vector is network-based and requires no authentication. An attacker can exploit this vulnerability by:

1. Identifying a Nimiq node running core-rs-albatross prior to version 1.3.0
2. Determining if the target node is in a vulnerable state (syncing or running without history index)
3. Sending a RequestTransactionsProof or RequestTransactionReceiptsByAddress message to the node
4. The vulnerable code path calls history_store.history_index().unwrap() which panics when the history index is unavailable
5. The panic causes the node process to crash, achieving denial of service

The vulnerability mechanism is straightforward—the panic occurs within the request handler path, meaning any peer on the network can trigger it by sending the appropriate message type. For detailed technical analysis, refer to the GitHub Security Advisory GHSA-xr78-2jhh-9wf9.

Detection Methods for CVE-2026-35468

Indicators of Compromise

• Unexpected Nimiq node crashes or restarts, particularly during synchronization periods
• Panic messages in node logs referencing Option::unwrap() failures in history store operations
• Increased network traffic containing RequestTransactionsProof or RequestTransactionReceiptsByAddress messages from unknown peers
• Patterns of node instability correlating with external connection attempts

Detection Strategies

• Monitor node process stability and implement alerting for unexpected terminations
• Analyze crash dumps for panic traces originating from consensus request handler code paths
• Implement network intrusion detection rules to identify suspicious patterns of consensus request messages
• Review node logs for panic messages containing called Option::unwrap() on a None value in the history store module

Monitoring Recommendations

• Configure process monitoring to track Nimiq node uptime and automatically alert on crashes
• Implement centralized logging for all node instances to correlate crash events across the network
• Monitor peer connection patterns for anomalous request behavior targeting transaction proof endpoints
• Set up network traffic analysis to baseline normal consensus request patterns and detect deviations

How to Mitigate CVE-2026-35468

Immediate Actions Required

• Upgrade all nimiq/core-rs-albatross installations to version 1.3.0 or later immediately
• If immediate upgrade is not possible, consider temporarily restricting network access to affected nodes
• Monitor node stability and implement automatic restart mechanisms as a temporary measure
• Review peer connections and consider temporarily disconnecting from untrusted peers until patched

Patch Information

This vulnerability has been patched in nimiq/core-rs-albatross version 1.3.0. The fix is available in commit 0e5c90a6c75b722f3d6091769776a4040e694dba, which was introduced via Pull Request #3667. Users should update to the latest release to remediate this vulnerability.

Workarounds

• Implement network-level filtering to restrict which peers can send consensus requests to vulnerable nodes
• Run nodes behind a reverse proxy or firewall that can rate-limit or block suspicious request patterns
• Consider running nodes with full history index enabled when possible, though this does not fully mitigate the issue during sync
• Deploy monitoring and automatic restart scripts to minimize downtime from potential exploitation

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