This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
libp2p-tls(11 total, 10 outdated, 3 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| futures | ^0.3.29 | 0.3.34 | up to date |
| futures-rustls | ^0.24.0 | 0.26.0 | out of date |
| libp2p-core | ^0.41.0 | 0.44.0 | out of date |
| libp2p-identity | ^0.2.7 | 0.3.0 | out of date |
| rcgen | ^0.11.3 | 0.14.10 | out of date |
| ring ⚠️ | ^0.16.20 | 0.17.14 | out of date |
| rustls ⚠️ | ^0.21.8 | 0.23.45 | out of date |
| thiserror | ^1.0.50 | 2.0.20 | out of date |
| rustls-webpki ⚠️ | ^0.101.4 | 0.103.15 | out of date |
| x509-parser | ^0.15.1 | 0.18.1 | out of date |
| yasna | ^0.5.2 | 0.6.0 | out of date |
(7 total, 5 outdated)
| Crate | Required | Latest | Status |
|---|---|---|---|
| hex | ^0.4.3 | 0.4.3 | up to date |
| hex-literal | ^0.4.1 | 1.1.0 | out of date |
| libp2p-core | ^0.41.0 | 0.44.0 | out of date |
| libp2p-identity | ^0.2.7 | 0.3.0 | out of date |
| libp2p-swarm | ^0.44.0 | 0.48.0 | out of date |
| libp2p-yamux | ^0.45.0 | 0.48.0 | out of date |
| tokio | ^1.33.0 | 1.53.1 | up to date |
rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network inputIf a close_notify alert is received during a handshake, complete_io
does not terminate.
Callers which do not call complete_io are not affected.
rustls-tokio and rustls-ffi do not call complete_io
and are not affected.
rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.
ring: Some AES functions may panic when overflow checking is enabled.ring::aead::quic::HeaderProtectionKey::new_mask() may panic when overflow
checking is enabled. In the QUIC protocol, an attacker can induce this panic by
sending a specially-crafted packet. Even unintentionally it is likely to occur
in 1 out of every 2**32 packets sent and/or received.
On 64-bit targets operations using ring::aead::{AES_128_GCM, AES_256_GCM} may
panic when overflow checking is enabled, when encrypting/decrypting approximately
68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols
like TLS and SSH are not affected by this because those protocols break large
amounts of data into small chunks. Similarly, most applications will not
attempt to encrypt/decrypt 64GB of data in one chunk.
Overflow checking is not enabled in release mode by default, but
RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml
profile can override this. Overflow checking is usually enabled by default in
debug mode.
rustls-webpki: Name constraints for URI names were incorrectly acceptedName constraints for URI names were ignored and therefore accepted.
Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as GHSA-965h-392x-2mh5. Thank you to @1seal for the report.
rustls-webpki: Name constraints were accepted for certificates asserting a wildcard namePermitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.
This was incorrect because, given a name constraint of accept.example.com, *.example.com could feasibly allow a name of reject.example.com which is outside the constraint.
This is very similar to CVE-2025-61727.
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as GHSA-xgp8-3hg3-c2mh. Thank you to @1seal for the report.
rustls-webpki: Reachable panic in certificate revocation list parsingA panic was reachable when parsing certificate revocation lists via [BorrowedCertRevocationList::from_der]
or [OwnedCertRevocationList::from_der]. This was the result of mishandling a syntactically valid empty
BIT STRING appearing in the onlySomeReasons element of a IssuingDistributionPoint CRL extension.
This panic is reachable prior to a CRL's signature being verified.
Applications that do not use CRLs are not affected.
Thank you to @tynus3 for the report.