Webpki
Monthly
Denial of service in rustls-webpki through 0.103.12 and in 0.104.0-alpha.1 through 0.104.0-alpha.6: a crafted certificate revocation list carrying an issuingDistributionPoint extension whose onlySomeReasons BIT STRING content is exactly [0x00] triggers an integer underflow in bit_string_flags() and panics the parsing process. Unauthenticated remote attackers can reach this only where an application has explicitly opted into CRL revocation checking by passing RevocationOptions to verify_for_usage() and parses CRL bytes from a source the attacker can influence (for example an attacker-supplied or MITM'd CRL distribution point); the default rustls configuration that omits RevocationOptions is unaffected. Publicly available exploit code exists - the GHSA-82j2-j2ch-gfr8 advisory ships a complete PoC CRL that reproduces the crash - but there is no confirmation of active exploitation, and the impact is purely availability (no confidentiality or integrity effect).
CRL revocation-check bypass in rustls-webpki versions before 0.103.10 and 0.104.0-alpha.5 can cause revoked X.509 certificates to be accepted when a relying application uses the non-default UnknownStatusPolicy::Allow, because the CRL authority-matching logic compares only a certificate's first distributionPoint against each CRL's IssuingDistributionPoint and ignores any additional distributionPoints. Exploitation requires an attacker who has already compromised a trusted issuing CA (a high-privilege position, consistent with the CVSS PR:H vector) plus a target certificate that carries more than one CRL distributionPoint; the default UnknownStatusPolicy::Deny fails safe by returning Error::UnknownRevocationStatus instead of accepting the certificate. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, so the mid-range 5.9 CVSS 4.0 score overstates what the vendor and independent analysis both describe as a limited-impact, largely latent issue that would most plausibly let an attacker keep using an already-revoked credential.
Name-constraint bypass in rustls-webpki versions 0.101.0 through 0.103.11 and 0.104.0-alpha.1 through 0.104.0-alpha.5 allows a misissued wildcard certificate to escape permitted-subtree DNS name constraints, potentially permitting names outside the intended subtree. The flaw is reachable only after signature verification succeeds and requires a misissued wildcard certificate from a name-constrained CA, making real-world exploitation narrow and high-complexity (assessed CVSS 3.1 base 2.1, PR:N, AC:H). No public exploit identified at time of analysis; vendor-released patches are available in 0.103.12 and 0.104.0-alpha.6.
rustls-webpki 0.101.0 through 0.103.11 and 0.104.0-alpha releases before 0.104.0-alpha.6 accept X.509 name constraints that apply to URI names instead of enforcing them, so a misissued certificate that violates such a constraint is treated as valid. Impact is deliberately narrow: URI name constraints are only reachable after successful signature verification, the library provides no API for asserting URI names, and exploitation therefore requires a certificate authority in the trusted path to have misissued a certificate. There is no public exploit identified at time of analysis, no CISA KEV listing, and our assessment treats this as a low-priority, defense-in-depth hardening fix consistent with the vendor's CVSS 4.0 score of 2.1 rather than an urgent vulnerability.
Denial of service in rustls-webpki through 0.103.12 and in 0.104.0-alpha.1 through 0.104.0-alpha.6: a crafted certificate revocation list carrying an issuingDistributionPoint extension whose onlySomeReasons BIT STRING content is exactly [0x00] triggers an integer underflow in bit_string_flags() and panics the parsing process. Unauthenticated remote attackers can reach this only where an application has explicitly opted into CRL revocation checking by passing RevocationOptions to verify_for_usage() and parses CRL bytes from a source the attacker can influence (for example an attacker-supplied or MITM'd CRL distribution point); the default rustls configuration that omits RevocationOptions is unaffected. Publicly available exploit code exists - the GHSA-82j2-j2ch-gfr8 advisory ships a complete PoC CRL that reproduces the crash - but there is no confirmation of active exploitation, and the impact is purely availability (no confidentiality or integrity effect).
CRL revocation-check bypass in rustls-webpki versions before 0.103.10 and 0.104.0-alpha.5 can cause revoked X.509 certificates to be accepted when a relying application uses the non-default UnknownStatusPolicy::Allow, because the CRL authority-matching logic compares only a certificate's first distributionPoint against each CRL's IssuingDistributionPoint and ignores any additional distributionPoints. Exploitation requires an attacker who has already compromised a trusted issuing CA (a high-privilege position, consistent with the CVSS PR:H vector) plus a target certificate that carries more than one CRL distributionPoint; the default UnknownStatusPolicy::Deny fails safe by returning Error::UnknownRevocationStatus instead of accepting the certificate. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, so the mid-range 5.9 CVSS 4.0 score overstates what the vendor and independent analysis both describe as a limited-impact, largely latent issue that would most plausibly let an attacker keep using an already-revoked credential.
Name-constraint bypass in rustls-webpki versions 0.101.0 through 0.103.11 and 0.104.0-alpha.1 through 0.104.0-alpha.5 allows a misissued wildcard certificate to escape permitted-subtree DNS name constraints, potentially permitting names outside the intended subtree. The flaw is reachable only after signature verification succeeds and requires a misissued wildcard certificate from a name-constrained CA, making real-world exploitation narrow and high-complexity (assessed CVSS 3.1 base 2.1, PR:N, AC:H). No public exploit identified at time of analysis; vendor-released patches are available in 0.103.12 and 0.104.0-alpha.6.
rustls-webpki 0.101.0 through 0.103.11 and 0.104.0-alpha releases before 0.104.0-alpha.6 accept X.509 name constraints that apply to URI names instead of enforcing them, so a misissued certificate that violates such a constraint is treated as valid. Impact is deliberately narrow: URI name constraints are only reachable after successful signature verification, the library provides no API for asserting URI names, and exploitation therefore requires a certificate authority in the trusted path to have misissued a certificate. There is no public exploit identified at time of analysis, no CISA KEV listing, and our assessment treats this as a low-priority, defense-in-depth hardening fix consistent with the vendor's CVSS 4.0 score of 2.1 rather than an urgent vulnerability.