EUVD-2026-30474
GHSA-xp3w-r5p5-63rr
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
5DescriptionGitHub Advisory
X509Ref::ocsp_responders returns OCSP responder URLs from a certificate's AIA extension as OpensslString, whose Deref<Target = str> wraps the raw bytes with str::from_utf8_unchecked. OpenSSL does not enforce that the underlying IA5String is ASCII, so a certificate with non-UTF-8 bytes in its OCSP accessLocation causes safe Rust code to construct a &str that violates the UTF-8 invariant - resulting in undefined behavior.
AnalysisAI
Undefined behavior in rust-openssl's X509Ref::ocsp_responders allows crafted X.509 certificates with non-UTF-8 OCSP responder URLs to violate Rust's memory safety guarantees. Applications parsing untrusted certificates (TLS handshakes, certificate validation pipelines, PKI tooling) can trigger undefined behavior through safe Rust code when processing malformed AIA extensions. CVSS 8.7 reflects network-exploitable integrity impact; no active exploitation confirmed (not in CISA KEV), but patch available in version 0.10.79 per upstream GitHub advisory GHSA-xp3w-r5p5-63rr.
Technical ContextAI
The rust-openssl crate provides Rust bindings to OpenSSL's libssl/libcrypto libraries. The vulnerability exists in the X509Ref::ocsp_responders method, which extracts OCSP responder URLs from X.509 certificates' Authority Information Access (AIA) extension. Per RFC 5280, these URLs are encoded as IA5String, which OpenSSL defines as ASCII (7-bit). However, OpenSSL's implementation does not validate IA5String encoding. The rust-openssl wrapper calls str::from_utf8_unchecked to convert these raw bytes into Rust's &str type without validation. This violates Rust's fundamental invariant that &str must contain valid UTF-8, classified as CWE-20 (Improper Input Validation). Undefined behavior in Rust can enable memory corruption, information disclosure, or arbitrary code execution depending on how downstream code processes the invalid &str. The CPE identifier pkg:rust/openssl covers versions 0.9.7 through 0.10.78, with version 0.10.79 introducing proper UTF-8 validation before dereferencing to &str.
RemediationAI
Upgrade rust-openssl to version 0.10.79 or later, which implements proper UTF-8 validation in X509Ref::ocsp_responders before constructing &str references (confirmed fix per GitHub advisory GHSA-xp3w-r5p5-63rr at https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-xp3w-r5p5-63rr). Update Cargo.toml dependency specification to openssl = "0.10.79" and run cargo update. For applications that cannot immediately upgrade, implement certificate validation to reject certificates with non-ASCII characters in AIA extensions before processing, though this requires duplicating OpenSSL's X.509 parsing at the application layer. Alternatively, avoid calling ocsp_responders on untrusted certificates and rely on external OCSP validation services, accepting the operational overhead of out-of-band validation. Note that input filtering is fragile since the vulnerability exists in library internals-upgrading is the only complete mitigation. Organizations should audit dependency trees (cargo tree | grep openssl) to identify all affected components, as transitive dependencies may pull vulnerable versions.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today