Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
On most platforms, Go uses the given system root certificates. However, in some narrower cases, the system trust stores may not be updated without further action. To defend against the narrower set of cases that may remain affected, a denylist was added in crypto/x509 to return an error when calling Verify with any of the known intermediate certificates that are no longer considered to be trustworthy.
Recommended action: Upgrade to 0.104.0-alpha.8 (pre-release) or 0.103.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
bitstringflags() in src/der.rs panics with an index-out-of-bounds when given a BIT STRING whose content is exactly [0x00] (one byte: zero padding bits, zero data bytes). This is reachable through the public API BorrowedCertRevocationList::fromder() via the issuingDistributionPoint CRL extension. Precondition: CRL checking is opt-in in rustls-webpki. This vulnerability affects only applications that explicitly pass RevocationOptions to verifyforusage() and load CRL bytes from a source the attacker can influence. The default rustls configuration (no RevocationOptions) is not affected. AI disclosure: This report was prepared with AI assistance (Claude). The vulnerability was discovered by differential fuzzing against a formally-verified Rust oracle. All technical claims have been independently verified against the live source code before submission. Details bitstringflags() in src/der.rs reads the content of named-bit BIT STRINGs (KeyUsage, ReasonFlags, etc.). Its input guard:…
Recommended action: Upgrade to 0.104.0-alpha.7 (pre-release) or 0.103.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.104.0-alpha.6 (pre-release) or 0.103.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.104.0-alpha.6 (pre-release) or 0.103.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.104.0-alpha.5 (pre-release) or 0.103.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building. Both TLS clients and TLS servers that accept client certificate are affected. We now give each path building operation a budget of 100 signature verifications. The original webpki crate is also affected, see GHSA-8qv2-5vq6-g2g7. This was previously reported in the original crate <https://github.com/briansmith/webpki/issues/69 and re-reported to us recently.
Recommended action: Upgrade to 0.101.4 or 0.100.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.