CVE-2026-34063
Panic-Inducing Connection Handling Bug in Nimiq network-libp2p Causes Remote Crash
Publication date: 2026-04-22
Last updated on: 2026-04-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| nimiq | nimiq_proof-of-stake | to 1.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-617 | The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Nimiq's network-libp2p implementation prior to version 1.3.0. The network-libp2p discovery uses a libp2p ConnectionHandler state machine that assumes there is at most one inbound and one outbound discovery substream per connection. If a remote peer opens or negotiates the discovery protocol substream a second time on the same connection, the handler triggers a panic instead of failing safely. This panic causes the networking task (swarm) to crash remotely, taking the node's peer-to-peer networking offline until it is restarted.
How can this vulnerability impact me? :
The impact of this vulnerability is a remote denial of service on the affected node's networking. An attacker can cause the networking task to crash by opening multiple discovery substreams on the same connection, which results in the node's peer-to-peer networking going offline until the node is restarted. This disrupts network availability and connectivity.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is fixed in network-libp2p version 1.3.0. The immediate step to mitigate this vulnerability is to upgrade to version 1.3.0 or later.
No known workarounds are available, so upgrading is the only effective mitigation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability primarily impacts the availability of the Nimiq network-libp2p node by causing a remote crash of the networking task, taking the node's peer-to-peer networking offline until restart.
There is no impact on confidentiality or integrity of data, as the vulnerability does not allow unauthorized data access or modification.
Since the vulnerability affects availability only and does not expose or compromise personal or sensitive data, it does not directly affect compliance with data protection regulations such as GDPR or HIPAA.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests when a remote peer opens or negotiates a second discovery protocol substream on the same connection, causing the networking task to panic and crash. Detection involves monitoring for panic messages such as "Inbound already connected" or "Outbound already connected" in the logs of the network-libp2p component.
Since the vulnerability causes a crash due to duplicate discovery substreams, you can detect attempts by observing logs or network behavior indicating repeated discovery substream negotiations on the same connection.
There are no specific commands provided in the resources to detect this vulnerability directly on your network or system.