nimiq-primitives

Impact

A malicious peer acting as a state-sync source can crash a syncing node with a crafted TrieChunk whose proof contains a TrieNodeChild whose suffix, when concatenated with the parent key via KeyNibbles::Add, exceeds the fixed 63-byte backing array. Add (primitives/src/key_nibbles.rs:332 / :341) indexes bytes[self.bytes_len()..self.bytes_len() + other.bytes_len()] with no combined-length check, causing an out-of-bounds slice panic (both the even- and odd-length branches).

KeyNibbles deserialization validates only the individual length <= 126, not the combined parent + suffix length. The panic occurs at put_chunk → child.key() → is_stump() → +, i.e. before proof.verify(), so no valid proof is required. As with the related child_index issue, exploitation requires being the victim's sync peer during state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3790 (commit eabfc3e2), which guards key-nibble concatenation against exceeding the maximum length instead of indexing out of bounds.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A malicious peer acting as a state-sync source can crash a syncing node by sending a crafted TrieChunk whose proof contains two TrieProofNodes with identical keys. TrieProof::verify() calls TrieProofNode::child_index() (primitives/src/trie/trie_proof_node.rs:94), which unconditionally unwraps KeyNibbles::get(self.key.len()). Because is_prefix_of returns true for two equal keys, execution reaches get(len), which returns None, and the unwrap() panics.

The panic is reached from untrusted network input (ResponseChunk → commit_chunks → put_chunk → proof.verify()) before any cryptographic proof verification, so the attacker does not need to produce a valid proof. Exploitation requires the attacker to be selected as the victim's sync peer while the victim is performing state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3789 (commit 41d35ace). child_index now rejects equal-length keys and returns MerkleRadixTrieError::WrongPrefix instead of unwrapping.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes).

A malicious peer can respond to a RequestChunk with a ResponseChunk::Chunk whose first TrieItem.key is the empty (ROOT) key. The chunk passes sorting, range, and Merkle-proof validation, but when put_raw tries to store a value at the root node, it calls TrieNode::put_value(...).unwrap(), which returns Err(RootCantHaveValue) and panics, aborting the node process. The panic fires on the first malicious chunk the victim commits; no rate limit or authentication gate caps the attack.

Impacted: any node running state sync against untrusted peers — this includes fresh nodes performing initial download and existing nodes recovering from data loss. Honest nodes never construct ROOT-keyed items, so non-syncing operation is unaffected.

Patches

See PR.

Workarounds

There is no safe in-process workaround: any peer serving state-sync data can trigger the crash and the code path is not guarded by a feature flag.

Resources

• Fix commit: (link to the merged PR commit, once merged)
• Affected code: primitives/trie/src/trie.rs — put_chunk (around line 819) and put_raw (around line 351)

Impact

A logic flaw in BlockInclusionProof::is_block_proven causes the function to return true without performing any cryptographic verification when get_interlink_hops yields an empty hop list. This occurs when the target block is at the election block position immediately preceding the election head's epoch. An attacker providing transaction inclusion proofs can forge a MacroBlock header for that epoch position and have it accepted as "proven" without any hash or signature verification.

Patches

The patch for this vulnerability is formally released as part of v1.4.0.

Workarounds

No Workarounds

Resources

See PR.

Impact

An untrusted p2p peer can cause a node to panic by announcing an election macro block whose validators set contains an invalid compressed BLS voting key.

Hashing an election macro header hashes validators and reaches Validators::voting_keys(), which calls validator.voting_key.uncompress().unwrap() and panics on invalid bytes.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

Impact

A malicious peer acting as a state-sync source can crash a syncing node with a crafted TrieChunk whose proof contains a TrieNodeChild whose suffix, when concatenated with the parent key via KeyNibbles::Add, exceeds the fixed 63-byte backing array. Add (primitives/src/key_nibbles.rs:332 / :341) indexes bytes[self.bytes_len()..self.bytes_len() + other.bytes_len()] with no combined-length check, causing an out-of-bounds slice panic (both the even- and odd-length branches).

KeyNibbles deserialization validates only the individual length <= 126, not the combined parent + suffix length. The panic occurs at put_chunk → child.key() → is_stump() → +, i.e. before proof.verify(), so no valid proof is required. As with the related child_index issue, exploitation requires being the victim's sync peer during state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3790 (commit eabfc3e2), which guards key-nibble concatenation against exceeding the maximum length instead of indexing out of bounds.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A malicious peer acting as a state-sync source can crash a syncing node by sending a crafted TrieChunk whose proof contains two TrieProofNodes with identical keys. TrieProof::verify() calls TrieProofNode::child_index() (primitives/src/trie/trie_proof_node.rs:94), which unconditionally unwraps KeyNibbles::get(self.key.len()). Because is_prefix_of returns true for two equal keys, execution reaches get(len), which returns None, and the unwrap() panics.

The panic is reached from untrusted network input (ResponseChunk → commit_chunks → put_chunk → proof.verify()) before any cryptographic proof verification, so the attacker does not need to produce a valid proof. Exploitation requires the attacker to be selected as the victim's sync peer while the victim is performing state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3789 (commit 41d35ace). child_index now rejects equal-length keys and returns MerkleRadixTrieError::WrongPrefix instead of unwrapping.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes).

A malicious peer can respond to a RequestChunk with a ResponseChunk::Chunk whose first TrieItem.key is the empty (ROOT) key. The chunk passes sorting, range, and Merkle-proof validation, but when put_raw tries to store a value at the root node, it calls TrieNode::put_value(...).unwrap(), which returns Err(RootCantHaveValue) and panics, aborting the node process. The panic fires on the first malicious chunk the victim commits; no rate limit or authentication gate caps the attack.

Impacted: any node running state sync against untrusted peers — this includes fresh nodes performing initial download and existing nodes recovering from data loss. Honest nodes never construct ROOT-keyed items, so non-syncing operation is unaffected.

Patches

See PR.

Workarounds

There is no safe in-process workaround: any peer serving state-sync data can trigger the crash and the code path is not guarded by a feature flag.

Resources

• Fix commit: (link to the merged PR commit, once merged)
• Affected code: primitives/trie/src/trie.rs — put_chunk (around line 819) and put_raw (around line 351)

Impact

A logic flaw in BlockInclusionProof::is_block_proven causes the function to return true without performing any cryptographic verification when get_interlink_hops yields an empty hop list. This occurs when the target block is at the election block position immediately preceding the election head's epoch. An attacker providing transaction inclusion proofs can forge a MacroBlock header for that epoch position and have it accepted as "proven" without any hash or signature verification.

Patches

The patch for this vulnerability is formally released as part of v1.4.0.

Workarounds

No Workarounds

Resources

See PR.

Impact

An untrusted p2p peer can cause a node to panic by announcing an election macro block whose validators set contains an invalid compressed BLS voting key.

Hashing an election macro header hashes validators and reaches Validators::voting_keys(), which calls validator.voting_key.uncompress().unwrap() and panics on invalid bytes.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

Impact

A malicious peer acting as a state-sync source can crash a syncing node with a crafted TrieChunk whose proof contains a TrieNodeChild whose suffix, when concatenated with the parent key via KeyNibbles::Add, exceeds the fixed 63-byte backing array. Add (primitives/src/key_nibbles.rs:332 / :341) indexes bytes[self.bytes_len()..self.bytes_len() + other.bytes_len()] with no combined-length check, causing an out-of-bounds slice panic (both the even- and odd-length branches).

KeyNibbles deserialization validates only the individual length <= 126, not the combined parent + suffix length. The panic occurs at put_chunk → child.key() → is_stump() → +, i.e. before proof.verify(), so no valid proof is required. As with the related child_index issue, exploitation requires being the victim's sync peer during state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3790 (commit eabfc3e2), which guards key-nibble concatenation against exceeding the maximum length instead of indexing out of bounds.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A malicious peer acting as a state-sync source can crash a syncing node by sending a crafted TrieChunk whose proof contains two TrieProofNodes with identical keys. TrieProof::verify() calls TrieProofNode::child_index() (primitives/src/trie/trie_proof_node.rs:94), which unconditionally unwraps KeyNibbles::get(self.key.len()). Because is_prefix_of returns true for two equal keys, execution reaches get(len), which returns None, and the unwrap() panics.

The panic is reached from untrusted network input (ResponseChunk → commit_chunks → put_chunk → proof.verify()) before any cryptographic proof verification, so the attacker does not need to produce a valid proof. Exploitation requires the attacker to be selected as the victim's sync peer while the victim is performing state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3789 (commit 41d35ace). child_index now rejects equal-length keys and returns MerkleRadixTrieError::WrongPrefix instead of unwrapping.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Impact

A remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes).

A malicious peer can respond to a RequestChunk with a ResponseChunk::Chunk whose first TrieItem.key is the empty (ROOT) key. The chunk passes sorting, range, and Merkle-proof validation, but when put_raw tries to store a value at the root node, it calls TrieNode::put_value(...).unwrap(), which returns Err(RootCantHaveValue) and panics, aborting the node process. The panic fires on the first malicious chunk the victim commits; no rate limit or authentication gate caps the attack.

Impacted: any node running state sync against untrusted peers — this includes fresh nodes performing initial download and existing nodes recovering from data loss. Honest nodes never construct ROOT-keyed items, so non-syncing operation is unaffected.

Patches

See PR.

Workarounds

There is no safe in-process workaround: any peer serving state-sync data can trigger the crash and the code path is not guarded by a feature flag.

Resources

• Fix commit: (link to the merged PR commit, once merged)
• Affected code: primitives/trie/src/trie.rs — put_chunk (around line 819) and put_raw (around line 351)

Impact

A logic flaw in BlockInclusionProof::is_block_proven causes the function to return true without performing any cryptographic verification when get_interlink_hops yields an empty hop list. This occurs when the target block is at the election block position immediately preceding the election head's epoch. An attacker providing transaction inclusion proofs can forge a MacroBlock header for that epoch position and have it accepted as "proven" without any hash or signature verification.

Patches

The patch for this vulnerability is formally released as part of v1.4.0.

Workarounds

No Workarounds

Resources

See PR.

Impact

An untrusted p2p peer can cause a node to panic by announcing an election macro block whose validators set contains an invalid compressed BLS voting key.

Hashing an election macro header hashes validators and reaches Validators::voting_keys(), which calls validator.voting_key.uncompress().unwrap() and panics on invalid bytes.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.