CVE-2026-34062 Overview
nimiq-libp2p is a Nimiq network implementation based on libp2p. A resource exhaustion vulnerability exists in versions prior to 1.3.0 where the MessageCodec::read_request and read_response functions call read_to_end() on inbound substreams. This allows a remote peer to send only a partial frame and keep the substream open indefinitely, consuming server resources. The vulnerability is exacerbated by the Behaviour::new configuration that sets with_max_concurrent_streams(1000), exposing a much larger stalled-slot budget than the library default.
Critical Impact
Remote attackers can exhaust node resources by opening multiple partial substreams, leading to denial of service conditions affecting Nimiq network nodes.
Affected Products
- nimiq-libp2p versions prior to 1.3.0
- Nimiq core-rs-albatross prior to v1.3.0
Discovery Timeline
- 2026-04-22 - CVE CVE-2026-34062 published to NVD
- 2026-04-22 - Last updated in NVD database
Technical Details for CVE-2026-34062
Vulnerability Analysis
This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue lies in how the nimiq-libp2p implementation handles inbound network streams. When a remote peer initiates a connection, the MessageCodec::read_request and read_response methods use read_to_end() to consume data from inbound substreams. This blocking read operation waits indefinitely for the stream to complete, creating an opportunity for resource starvation attacks.
The attack surface is significantly expanded by the library's configuration choice to use with_max_concurrent_streams(1000), which is substantially higher than libp2p's conservative defaults. This design decision allows attackers to occupy up to 1000 connection slots simultaneously with minimal effort.
Root Cause
The vulnerability stems from two compounding issues: the use of unbounded read_to_end() operations that do not implement timeouts or partial read handling, combined with an overly permissive concurrent stream limit. The read_to_end() function blocks until the entire message is received or the connection is closed, meaning a malicious peer can hold resources hostage by simply not completing the message transmission.
Attack Vector
An attacker can exploit this vulnerability remotely over the network without authentication. The attack proceeds by establishing multiple connections to a target Nimiq node, initiating substream requests, sending partial message frames, and deliberately keeping these substreams open without completing the data transmission. Since the node allocates resources for each pending stream and waits indefinitely for completion, the attacker can exhaust available connection slots and memory resources, effectively denying service to legitimate peers.
The attack requires no special privileges and can be executed from any network position with connectivity to the target node.
Detection Methods for CVE-2026-34062
Indicators of Compromise
- Unusual accumulation of long-lived, idle substream connections from single or few IP addresses
- Memory consumption growth without corresponding legitimate network traffic
- Connection slot exhaustion with high counts of pending stream operations
- Network monitoring showing incomplete message frames followed by connection persistence
Detection Strategies
- Monitor for abnormal ratios of opened versus completed substream operations
- Implement connection rate limiting and alerting for peers opening many simultaneous streams
- Track substream duration metrics to identify streams exceeding normal completion times
- Deploy network flow analysis to detect partial frame patterns characteristic of this attack
Monitoring Recommendations
- Configure alerts for connection pool utilization approaching the 1000-stream limit
- Monitor per-peer connection counts and flag anomalous behavior
- Track memory utilization trends on Nimiq network nodes
- Review libp2p connection logs for patterns of incomplete handshakes
How to Mitigate CVE-2026-34062
Immediate Actions Required
- Upgrade nimiq-libp2p to version 1.3.0 or later immediately
- Review network node configurations for exposure to untrusted networks
- Consider implementing firewall rules to limit inbound connection rates during the upgrade window
- Monitor existing nodes for signs of active exploitation
Patch Information
The patch for this vulnerability is formally released as part of v1.3.0. The fix is available in GitHub commit c021a5337b808c73571b44999f9753051bac7508. The official release can be obtained from GitHub Release v1.3.0. For complete vulnerability details, refer to the GitHub Security Advisory GHSA-gh7r-qh4p-q4fr.
Workarounds
- No known workarounds are available according to the vendor advisory
- Consider temporarily reducing network exposure of affected nodes until patching is complete
- Implement external rate limiting at the firewall or load balancer level as a temporary measure
- Monitor nodes closely for resource exhaustion symptoms
# Upgrade to patched version
git fetch --tags
git checkout v1.3.0
cargo build --release
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
