CVE-2026-93602: rustls-webpki Information Disclosure Flaw

CVE-2026-93602 Overview

CVE-2026-93602 affects rustls-webpki, a Rust-based X.509 certificate verification library used by the rustls TLS implementation. Versions before 0.103.10 and 0.104.0-alpha.5 contain faulty Certificate Revocation List (CRL) authority-matching logic. The library compares only the first distributionPoint in a certificate against each CRL's IssuingDistributionPoint, ignoring additional distribution points. An attacker with a compromised trusted issuing authority can present revoked certificates that pass revocation checks under UnknownStatusPolicy::Allow, or cause incorrect errors under the default deny policy. The flaw is tracked under CWE-299: Improper Check for Certificate Revocation.

Critical Impact
Revoked certificates issued by a compromised trusted authority may be accepted as valid, undermining TLS revocation guarantees for applications relying on rustls-webpki CRL enforcement.

Affected Products

rustls-webpki versions prior to 0.103.10
rustls-webpki versions in the 0.104.0-alpha series prior to 0.104.0-alpha.5
Downstream rustls consumers that enable CRL-based revocation checking

Discovery Timeline

2026-09-18 - CVE-2026-93602 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93602

Vulnerability Analysis

The rustls-webpki library validates certificate revocation by matching a certificate's CRL Distribution Points (CDP) extension against candidate CRLs and their IssuingDistributionPoint (IDP) extension. RFC 5280 permits certificates to declare multiple distribution points, each potentially pointing at a distinct CRL partition. The vulnerable revocation code inspects only the first distributionPoint entry when matching against a CRL's IDP.

When a certificate legitimately declares several distribution points, the matcher can conclude that no CRL applies, or that the wrong CRL applies. Under UnknownStatusPolicy::Allow, a revoked certificate whose matching CRL is skipped will be treated as having unknown status and accepted. Under the default deny policy, valid certificates may incorrectly fail verification with a revocation error.

Exploitation requires control of a trusted issuing authority, so the attack surface is limited to environments where an intermediate CA has been compromised or misused. However, the outcome directly nullifies the CRL layer of PKI defense in depth.

Root Cause

The root cause is incomplete iteration in the CRL authority-matching function. The routine returns after evaluating the first entry of the certificate's CRLDistributionPoints sequence rather than iterating across every declared distribution point. This narrow comparison violates the RFC 5280 requirement that revocation status be resolved against any distribution point authorized by the issuer.

Attack Vector

An attacker who controls a trusted issuing authority mints a certificate declaring multiple CRL distribution points, then arranges for the effective revocation CRL to be published under a distribution point other than the first. Because the vulnerable matcher only inspects the first entry, the revocation record is never consulted. The revoked certificate is then presented over TLS to a client using rustls-webpki with CRL checking enabled, and the connection succeeds. No user interaction is required beyond initiating a normal TLS handshake.

See the GitHub Security Advisory GHSA-pwjx-qhcg-rvj4 and the VulnCheck Advisory on Rustls for further technical background. No public proof-of-concept code is available at this time.

Detection Methods for CVE-2026-93602

Indicators of Compromise

TLS sessions completed with peer certificates that carry multiple CRLDistributionPoints entries where later entries reference CRLs listing the certificate as revoked.
Application or rustls audit logs showing successful handshakes against certificates that other TLS stacks (OpenSSL, BoringSSL) reject with certificate revoked.
Unexpected revocation errors in applications using the default deny policy when validating legitimate multi-CDP certificates.

Detection Strategies

Inventory all Rust binaries and services that link rustls-webpki and compare resolved versions to 0.103.10 or 0.104.0-alpha.5.
Perform differential revocation checks by validating the same certificate chains through both rustls-webpki and an independent library, then alerting on divergent verdicts.
Parse observed X.509 leaf certificates in TLS telemetry and flag those with more than one distributionPoint when presented to hosts running affected library versions.

Monitoring Recommendations

Ingest TLS handshake and certificate metadata into a centralized data lake and correlate against published CRLs to identify accepted-but-revoked certificates.
Alert on newly issued intermediate certificates from private or partner CAs, particularly those authorized to issue with multiple distribution points.
Track dependency manifests (Cargo.lock) in CI/CD and fail builds that pin vulnerable rustls-webpki versions.

How to Mitigate CVE-2026-93602

Immediate Actions Required

Upgrade rustls-webpki to 0.103.10 or later on the 0.103.x line, or to 0.104.0-alpha.5 or later on the 0.104.x pre-release line.
Rebuild and redeploy every downstream binary that statically links the library; runtime patching is not applicable to Rust crates.
Audit trust stores and remove any issuing authorities that are no longer required, reducing exposure if a CA is compromised.

Patch Information

The rustls maintainers released fixed versions 0.103.10 and 0.104.0-alpha.5, which iterate across every distributionPoint entry when matching against a CRL's IssuingDistributionPoint. Details are published in the GitHub Security Advisory GHSA-pwjx-qhcg-rvj4.

Workarounds

Where upgrading is not immediately feasible, disable CRL-based revocation and switch to OCSP stapling or short-lived certificates so that revocation is not the primary trust decision.
Avoid configuring UnknownStatusPolicy::Allow in production, since it converts matcher failures into silent acceptance of revoked certificates.
Restrict trusted issuing authorities to a minimal set and monitor certificate issuance logs for CAs authorized to your environment.

bash

# Update the rustls-webpki dependency in Cargo.toml, then refresh Cargo.lock
cargo update -p rustls-webpki --precise 0.103.10
cargo tree -i rustls-webpki   # verify no vulnerable versions remain
cargo build --release