libp2p-quic: Remote panic via certificate expiry race during QUIC handshake
Collected exploitation and prediction evidence
Risk source coverageCISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
cve-program · CVE-2026-61544
Publishedlibp2p-rust is the official Rust language implementation of the libp2p networking stack. Prior to 0.13.1, libp2p-quic could panic during an inbound QUIC handshake when a remote peer presented a valid short-lived libp2p TLS certificate and delayed the final TLS 1.3 handshake fragment until after the certificate expired. In the Quinn post-handshake upgrade path, transports/quic/src/connection/connecting.rs called libp2p_tls::certificate::parse a second time in remote_peer_id and used expect on the result. The repeated wall-clock validity check could reject the now-expired certificate, causing the expect call to terminate any application exposing an affected libp2p-quic listener. This vulnerability is fixed in 0.13.1.
- Source published
- 15 Sep 2026 19:46:13 UTC
- Source modified
- 17 Sep 2026 16:48:19 UTC
- Observed here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 4.0 · 8.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
euvd · EUVD-2026-79501
Publishedlibp2p-rust is the official Rust language implementation of the libp2p networking stack. Prior to 0.13.1, libp2p-quic could panic during an inbound QUIC handshake when a remote peer presented a valid short-lived libp2p TLS certificate and delayed the final TLS 1.3 handshake fragment until after the certificate expired. In the Quinn post-handshake upgrade path, transports/quic/src/connection/connecting.rs called libp2p_tls::certificate::parse a second time in remote_peer_id and used expect on the result. The repeated wall-clock validity check could reject the now-expired certificate, causing the expect call to terminate any application exposing an affected libp2p-quic listener. This vulnerability is fixed in 0.13.1.
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Sep 15, 2026, 7:46:13 PM
dateUpdated: Sep 17, 2026, 4:48:19 PM
- Source published
- Sep 15, 2026, 7:46:13 PM (timezone not stated)
- Source modified
- Sep 17, 2026, 4:48:19 PM (timezone not stated)
- Observed here
- 11 Nov 2026 15:02:38 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.
EUVD CVSS 4.0 · 8.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
nvd · CVE-2026-61544
Publishedlibp2p-rust is the official Rust language implementation of the libp2p networking stack. Prior to 0.13.1, libp2p-quic could panic during an inbound QUIC handshake when a remote peer presented a valid short-lived libp2p TLS certificate and delayed the final TLS 1.3 handshake fragment until after the certificate expired. In the Quinn post-handshake upgrade path, transports/quic/src/connection/connecting.rs called libp2p_tls::certificate::parse a second time in remote_peer_id and used expect on the result. The repeated wall-clock validity check could reject the now-expired certificate, causing the expect call to terminate any application exposing an affected libp2p-quic listener. This vulnerability is fixed in 0.13.1.
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Awaiting Analysis
Weakness classifications: CWE-248
Original publisher date fields
published: 2026-09-15T20:17:35.147
lastModified: 2026-09-30T17:51:36.337
- Source published
- 15 Sep 2026 20:17:35 UTC
- Source modified
- 30 Sep 2026 17:51:36 UTC
- Observed here
- 25 Oct 2026 14:19:22 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 4.0 · [email protected] · Secondary · 8.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
osv · GHSA-5hq8-qhww-jm7q
Published### Summary `libp2p-quic` can panic on an inbound QUIC handshake if a malicious peer presents a valid, short lived libp2p TLS certificate and delays the final TLS 1.3 handshake fragment until the certificate expires. This is remotely reachable by a network peer and can crash applications exposing a libp2p QUIC listener. ### Details During the TLS handshake, `libp2p-tls` parses and validates the peer certificate. After Quinn reports handshake completion, `libp2p-quic` re-parses the same certificate in the post-handshake upgrade path and assumes this cannot fail: https://github.com/libp2p/rust-libp2p/blob/969b707bf1177ebebd1febc285c3fd22793b95c5/transports/quic/src/connection/connecting.rs#L65-L66 However, `libp2p_tls::certificate::parse()` re-runs certificate verification on every call, including a wall-clock validity check. A certificate that was valid during the first handshake time parse can expire before the second post-handshake parse, causing the `expect(...)` to panic. ### PoC A malicious peer can trigger this by: 1. Opening a QUIC connection to a libp2p QUIC listener. 2. Presenting a valid libp2p TLS certificate with a very short lifetime. 3. Allowing the initial handshake-time certificate validation to succeed. 4. Withholding the final client handshake fragment packet until after the certificate expires, but before the QUIC handshake timeout elapses. 5. The listener completes the handshake and hits the post-handshake certificate re-parse, which panics. ### Impact Remote unauthenticated denial of service. Any application exposing an affected `libp2p-quic` listener can be crashed by a network peer that performs a valid-looking QUIC/TLS handshake with attacker-controlled timing. No malformed packets are required.
- Source published
- 15 Sep 2026 20:01:17 UTC
- Source modified
- 15 Sep 2026 20:15:04 UTC
- Observed here
- 24 Oct 2026 13:19:54 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS_V4 · CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Publisher rating · HIGH