Nimiq network-libp2p CVE-2026-44505

The kad feature must be compiled into the network-libp2p crate (non-default feature flag). The victim node must be actively executing a Network::dht_get call at the time the malicious peer returns a FoundRecord. The attacker must be an established peer in the victim's Kademlia routing table or able to respond to the specific query ID. Exploitation is unauthenticated (CVSS PR:N) and requires no user interaction (UI:N), but depends on the timing of an in-flight DHT query. A node not performing any DHT lookups at the time of the malformed response is not affected. The hang affects only the individual future awaiting that query, not the entire network stack; other operations continue unless callers share executor resources with the stalled future.

CVSS 5.3 Medium with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L indicates network-exploitable, low-complexity availability impact requiring no authentication or user interaction. The NVD tag of 'Information Disclosure' conflicts with the actual CVSS impact vector (C:N/I:N/A:L) and the description, which describes only a hanging future - no data exfiltration path is described or evidenced in the PR diff. This tag discrepancy should be treated as mislabeled metadata; security teams should rely on the CVSS vector and description. No EPSS score was provided in the input data. The issue is not in CISA KEV, and no public exploit code exists. The real-world impact is a targeted availability degradation against Nimiq nodes performing DHT lookups, not a broad exploitation scenario. A malicious peer can selectively stall a victim node's DHT operations but cannot gain code execution, exfiltrate data, or affect blockchain consensus directly. Risk priority is low for patched deployments; unpatched nodes actively querying DHT are the realistic exposure surface.

An attacker operates a malicious Nimiq peer that connects to a target node and waits for the target to initiate a DHT get-record query. When the target queries for a record the malicious peer claims to have, the peer returns a FoundRecord response containing a record with an invalid or forged signature. The target's dht_verifier.verify() call fails, the error path exits without completing the oneshot, and the awaiting Network::dht_get future hangs indefinitely, potentially blocking any application logic depending on the DHT lookup result. No public POC code is known at time of analysis, but the regression test added in PR #3716 (dht_get_with_verifier_failure_returns_error) demonstrates the exact triggering condition.