Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

crates.io package

libp2p-quic

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.2crates.ioAmendedPublished

    libp2p-quic: Remote panic via certificate expiry race during QUIC handshake

    CVE-2026-61544 · GHSA-5hq8-qhww-jm7q

    Affected
    • crates.io libp2p-quic < 0.13.1
    Fixed in
    0.13.1· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →