Description

Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to 1.6.0, a malicious state-sync peer can crash a syncing node by sending a crafted TrieChunk proof containing two TrieProofNode values with identical keys. TrieProof::verify calls TrieProofNode::child_index in primitives/src/trie/trie_proof_node.rs, where is_prefix_of accepts equal keys and KeyNibbles::get is called at the key length, returns None, and is unconditionally unwrapped. Untrusted ResponseChunk data reaches commit_chunks, put_chunk, and proof.verify before cryptographic proof validation, so the attacker does not need a valid proof. Exploitation requires the attacker to be selected as the victim's sync peer during state sync, and the resulting panic is transient because the node restarts and resynchronizes. This issue is fixed in version 1.6.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-14T16:17:12.217Z",
  "pubdate": "2026-09-14T16:17:12.217Z",
  "executiveSummary": "A denial-of-service (DoS) vulnerability exists in the Nimiq Proof-of-Stake Rust implementation prior to version 1.6.0. The vulnerability stems from improper input validation during the state synchronization process, allowing a remote, unauthenticated peer to trigger a process panic.\nThe flaw resides in the handling of TrieChunk proofs, where crafted malicious data can cause a node to crash. Because the validation occurs before cryptographic verification of the proof itself, an attacker does not require valid credentials or legitimate network authority to exploit the system.\nThe impact is limited to a transient node crash, forcing the target to restart and re-initiate the synchronization process. While this does not lead to remote code execution or data corruption, it allows a malicious state-sync peer to disrupt the availability of Nimiq nodes actively participating in the network's consensus or synchronization protocols. The risk is elevated by the low barrier to entry for exploitation, as the attacker merely needs to be selected as a sync peer for the target node.",
  "technicalDetails": "The vulnerability is situated within the `TrieProof::verify` function located in the Nimiq protocol's trie handling logic. The root cause is an unsafe handling of `TrieProofNode` structures when processing untrusted `TrieChunk` data during node synchronization.\nSpecifically, the file `primitives/src/trie/trie_proof_node.rs` contains the vulnerable logic in `TrieProofNode::child_index`. When a malicious peer sends a crafted `TrieChunk` containing two `TrieProofNode` entries with identical keys, the `is_prefix_of` check incorrectly evaluates the equality of these keys.\nThe flaw is triggered when `KeyNibbles::get` is invoked at a key length index that results in an out-of-bounds access. The function returns `None` in these scenarios; however, the code proceeds to perform an unconditional `.unwrap()` on this result. This operation forces a panic in the Rust runtime when the expected data is absent, effectively crashing the syncing node.\nThe attack flow proceeds as follows: 1) An attacker connects to a victim node as a peer during the state synchronization phase. 2) The attacker transmits a maliciously crafted `TrieChunk` payload containing the problematic duplicate keys. 3) The target node executes `commit_chunks`, which invokes `put_chunk` and subsequently `proof.verify`. 4) The `TrieProof::verify` method attempts to process the node structure before verifying the cryptographic signatures or validity of the proof data. 5) The `child_index` function encounters the identical keys and hits the invalid index, causing the `KeyNibbles::get` method to return `None`. 6) The subsequent `unwrap()` triggers a panic, causing the node process to terminate.\nBecause this validation logic executes prior to any cryptographic proof validation, the attacker is not required to provide a valid proof, significantly lowering the complexity of the exploit. The vulnerability affects all versions of the Nimiq implementation prior to 1.6.0. Post-exploitation, the crash is transient; the node's monitoring or supervisor processes typically restart the node, causing it to re-attempt synchronization, where it may be subjected to the same attack again if the attacker maintains the peer connection."
}