CVE-2026-61544 in libp2p-rust
Summary
by MITRE • 09/15/2026
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 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The libp2p-rust project serves as the official Rust implementation of the decentralized networking stack known as libp2p, facilitating peer-to-peer communication across various protocols including QUIC and TLS. Within this ecosystem, the libp2p-quic transport layer relies on secure handshake procedures to establish trusted connections between peers. A critical flaw was identified in versions prior to 0.13.1 regarding the handling of inbound QUIC handshakes when utilizing short-lived Transport Layer Security certificates. This vulnerability stems from a logic error in how certificate validity is checked during different phases of the connection establishment process, specifically within the Quinn post-handshake upgrade path found in the source file transports/quic/src/connection/connecting.rs.
The technical root cause involves a redundant and temporally inconsistent validation check for peer identity certificates. During an inbound handshake, if a remote peer presents a valid but short-lived libp2p TLS certificate, the system initially validates it successfully. However, the code subsequently calls the function libp2p_tls::certificate::parse again within the remote_peer_id method to extract peer identification data. This second invocation performs a fresh wall-clock validity check against the current time rather than relying on the result of the initial validation or caching the verified state. If an attacker can delay the transmission of the final TLS 1.3 handshake fragment until after the certificate's expiration window, this secondary check will fail because it perceives the certificate as expired at that specific moment in time.
This logic flaw leads to a denial-of-service condition through application termination rather than a simple connection rejection. The code utilizes an expect macro on the result of the second parse call. When the certificate is deemed invalid due to expiration during this late-stage check, the expect macro triggers a panic, causing the entire Rust application exposing the affected libp2p-quic listener to crash abruptly. This represents a significant availability risk for nodes in a peer-to-peer network that rely on continuous uptime and stable connections. The vulnerability aligns with CWE-862 Missing Authorization or CWE-354 Improper Validation of Certificate Expiration, as it fails to maintain the validity state established during the initial handshake phase across subsequent processing steps within the same session context.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability can be categorized under T1499 Endpoint Denial of Service or more specifically related to resource exhaustion via application crashes in network services. It highlights the importance of stateful validation where once an object is verified as authentic and valid within a transactional context like a TLS handshake, subsequent checks should not re-evaluate temporal constraints unless explicitly required by security policy for long-lived sessions. The lack of caching or passing forward the validity status creates a race condition based on network latency and certificate lifetime settings.
The recommended mitigation involves upgrading to libp2p-rust version 0.13.1, which addresses this issue by correcting the validation logic in the Quinn post-handshake upgrade path. Developers should ensure that their dependency management systems are configured to pull this patched version automatically or manually update it if using static dependencies. Additionally, organizations running nodes with very short certificate lifetimes should review their network configurations and consider increasing certificate validity periods where feasible to provide a larger buffer against timing-related failures during handshake completion. Monitoring for unexpected process terminations in libp2p-based applications can also serve as an indicator of compromise or exploitation attempts targeting this specific flaw before patches are applied.