Cyber Resilience

CVE-2026-34063

Nimiq Proof-Of-Stake ≤ 1.3.0

Published
22 April 2026
Modified
24 April 2026
Patch / advisory
CVSS Score v3.1 7.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0035 28th percentile
Risk Priority 57 floored blend · peak EPSS

Summary

CVE-2026-34063 is a high-severity Reachable Assertion (CWE-617) vulnerability in Nimiq Nimiq Proof-Of-Stake. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 28th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.

Deeper analysis AI-assisted summary

Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.

CVE-2026-34063 affects Nimiq's network-libp2p, a Nimiq network implementation based on libp2p, in versions prior to 1.3.0. The vulnerability resides in the discovery mechanism, which uses a libp2p ConnectionHandler state machine that assumes 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! with messages such as "Inbound already connected" or "Outbound already connected" instead of failing closed, leading to a crash of the networking task (swarm) and taking the node's P2P networking offline until restart. This issue is classified under CWE-617 (Reachable Assertion) with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Any remote peer capable of establishing a connection to the vulnerable node can exploit this flaw with low complexity and no privileges or user interaction required. By simply negotiating a duplicate discovery substream, the attacker triggers the panic, resulting in a denial-of-service that disables the node's P2P networking functionality until manual restart.

The patch is formally released in network-libp2p version 1.3.0, as detailed in the Nimiq core-rs-albatross GitHub commit e0d4e01994f061bf41d3c2835bc74040d3c084f5, pull request #3666, release tag v1.3.0, and security advisory GHSA-74hp-mhfx-m45h. No known workarounds are available.

EU & UK References

Vulnerability Data

Nimiq's network-libp2p is a Nimiq network implementation based on libp2p. Prior to version 1.3.0, `network-libp2p` discovery uses a libp2p `ConnectionHandler` state machine. the handler assumes there is at most one inbound and one outbound discovery substream per connection. if a…

more

remote peer opens/negotiate the discovery protocol substream a second time on the same connection, the handler hits a `panic!(\"Inbound already connected\")` / `panic!(\"Outbound already connected\")` path instead of failing closed. This causes a remote crash of the networking task (swarm), taking the node's p2p networking offline until restart. The patch for this vulnerability is formally released as part of v1.3.0. No known workarounds are available.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-34069Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-34067Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-34066Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-40093Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-34065Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-34062Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-33471Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-35468Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-33184Same product: Nimiq Nimiq Proof-Of-Stake
CVE-2026-34061Same product: Nimiq Nimiq Proof-Of-Stake

Affected Assets

nimiq
nimiq proof-of-stake
≤ 1.3.0

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation finds reachable assertions during development.

Security engineering principles discourage use of assertions for handling untrusted input.

Validating untrusted inputs structurally prevents attacker data from reaching and triggering assertions.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly prevent unsafe assertions from being coded in reachable paths.

DE.CM-09 partial match
prevents

Runtime monitoring of software can detect assertion-triggered crashes as adverse events.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover and record reachable-assertion flaws before deployment.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development can detect reachable assertions before release, reducing the likelihood of exploitation.

prevents

Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.

prevents

Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.

prevents

Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.

prevents

Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.

References