CVE-2026-61544: libp2p-quic: Remote panic via certificate expiry race during QUIC handshake
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, libp2ptls::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.
Other sources
libp2p-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 libp2ptls::certificate::parse a second time in remotepeerid 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/libp2p-quicto a version that resolves this vulnerability.Fixed in 0.13.1 - Upgrade
Upgrade
libp2p-quicto a version that resolves this vulnerability.Fixed in 0.13.1 - Compensating control
Ensure the libp2p QUIC listener is not reachable from untrusted networks (e.g., restrict inbound access via firewall/ACL so only trusted peers can connect).
- Operational
After upgrading to 0.13.1, restart the application/services exposing the affected libp2p-quic listener to ensure the updated QUIC/TLS post-handshake certificate parsing logic is used.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Any application exposing an affected libp2p-quic listener is exposed to remote termination through an inbound QUIC handshake. The issue affects libp2p-quic versions before 0.13.1.
What does an attacker need to trigger the panic?
An attacker needs to present a valid short-lived libp2p TLS certificate during an inbound QUIC handshake and delay the final TLS 1.3 handshake fragment until after that certificate expires. The second certificate validation then fails in the post-handshake upgrade path, triggering an expect call.
What should operators do?
Upgrade libp2p-quic to version 0.13.1, which fixes the vulnerability. The provided information does not describe a mitigation for deployments that cannot immediately upgrade.