webpki: CRLs not considered authoritative by Distribution Point due to faulty matching logicGHSA-pwjx-qhcg-rvj4
MEDIUMGHSA-pwjx-qhcg-rvj4 is a medium-severity (CVSS 4.4) CWE-299 vulnerability in rustls-webpki. A fix is available for rustls-webpki — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-pwjx-qhcg-rvj4.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
rustls-webpki🦀rustls-webpkiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
If a certificate had more than one distributionPoint, then only the first distributionPoint would be considered against each CRL's IssuingDistributionPoint distributionPoint, and then the certificate's subsequent distributionPoints would be ignored.
The impact was that correct provided CRLs would not be consulted to check revocation. With UnknownStatusPolicy::Deny (the default) this would lead to incorrect but safe Error::UnknownRevocationStatus. With UnknownStatusPolicy::Allow this would lead to inappropriate acceptance of revoked certificates.
This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug. An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | rustls-webpki | ≥ 0.102.0-alpha.0&&< 0.103.10 | 0.103.10cargo update -p rustls-webpki --precise 0.103.10 |
| 🦀crates.io | rustls-webpki | ≥ 0.104.0-alpha.1&&< 0.104.0-alpha.5 | 0.104.0-alpha.5cargo update -p rustls-webpki --precise 0.104.0-alpha.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rustls-webpki, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update rustls-webpki to 0.103.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pwjx-qhcg-rvj4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-pwjx-qhcg-rvj4 in your dependencies?
Find it across crates.io, including transitive dependencies.