Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/keynibbles.rs:332 / :341) indexes bytes[self.byteslen()..self.byteslen() + other.byteslen()] 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 putchunk → child.key() → isstump() → +, i.e. before proof.verify(), so no valid proof is required. As with the related childindex 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…
Recommended action: Upgrade to 1.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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::childindex() (primitives/src/trie/trieproofnode.rs:94), which unconditionally unwraps KeyNibbles::get(self.key.len()). Because isprefixof 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 → commitchunks → putchunk → 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…
Recommended action: Upgrade to 1.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::putchunk 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 putraw tries to store a value at the root node, it calls TrieNode::putvalue(...).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…
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.