Rustls-webpki panic in CRL parsing can crash TLS verification services

A Rust TLS stack can stay memory-safe and still fall over hard. RustSec RUSTSEC-2026-0104 flagged a reachable panic in rustls-webpki’s certificate revocation list parser, and that means a hostile or malformed CRL could crash certificate verification before signature validation ever finishes.

The bug landed on April 22, 2026 and GitHub classified it as high severity under GHSA-82j2-j2ch-gfr8. The panic was reachable through the public API BorrowedCertRevocationList::from_der, with the same issue also affecting OwnedCertRevocationList::from_der. The trigger was subtle: a syntactically valid empty BIT STRING in the onlySomeReasons field of an IssuingDistributionPoint CRL extension. In other words, this was not junk input that obviously belonged in a trash heap. It was valid-looking ASN.1 that exposed a parser edge case.

That is what makes the advisory operationally important. rustls-webpki does not enable CRL checking by default, so services that never opt into revocation logic are not affected. But the moment an application passes RevocationOptions to verify_for_usage and loads CRL bytes from a source an attacker can influence, the parser becomes reachable. A panic at that point is not a correctness quibble. It is a denial-of-service path in a service that is supposed to decide whether a peer certificate can be trusted.

The first practical check is simple: look in Cargo.lock for rustls-webpki. If it is present, verify whether the dependency is pulled in through a TLS stack that actually enables CRLs, not just through rustls transitively. The patched releases are rustls-webpki 0.103.13 and 0.104.0-alpha.7, and both upstream release notes explicitly call out the fix for a reachable panic in CRL parsing. If you ship a service that does certificate validation, upgrade and then re-test malformed CRL handling rather than assuming the panic is gone because the code is written in Rust.

The standards angle matters too. RFC 5280 defines IssuingDistributionPoint as part of the Internet X.509 certificate revocation list profile, and onlySomeReasons is a legitimate optional field. That means the bug lived in a standards-compliant corner of the parser, the kind of place where security bugs hide in plain sight. Reported by tynus3, the issue is another reminder that Rust’s safety guarantees do not remove the need to harden TLS and PKI plumbing against attacker-controlled input.