This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate async-tls

Dependencies

(6 total, 4 outdated, 1 insecure)

CrateRequiredLatestStatus
 futures-core^0.3.50.3.34up to date
 futures-io^0.3.50.3.34up to date
 rustls^0.210.23.45out of date
 rustls-pemfile^1.02.2.0out of date
 rustls-webpki ⚠️^0.101.40.103.15insecure
 webpki-roots^0.22.31.0.9out of date

Dev dependencies

(4 total, all up-to-date)

CrateRequiredLatestStatus
 async-std^1.111.13.2up to date
 futures-executor^0.3.50.3.34up to date
 futures-util^0.3.50.3.34up to date
 lazy_static^11.5.0up to date

Security Vulnerabilities

rustls-webpki: Name constraints for URI names were incorrectly accepted

RUSTSEC-2026-0098

Name 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 name

RUSTSEC-2026-0099

Permitted 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 parsing

RUSTSEC-2026-0104

A 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.