CVE-2026-42327

What it actually does

rust-openssl versions 0.9.7 through 0.10.78 can convert attacker-controlled certificate bytes into a Rust &str without validating that the bytes are valid UTF-8. The vulnerable path is X509Ref::ocsp_responders, which returns OCSP responder URLs from the certificate Authority Information Access extension as OpensslString; internally this can wrap raw OpenSSL IA5String data with str::from_utf8_unchecked. Because OpenSSL does not guarantee the IA5String is ASCII or valid UTF-8, a crafted X.509 certificate containing non-UTF-8 bytes in the OCSP accessLocation can cause safe Rust code to violate Rust’s UTF-8 invariant, resulting in undefined behavior. Practical impact depends on how the application uses the returned string, but may include process crashes, incorrect logic, memory corruption, or other unpredictable behavior in code that parses untrusted certificates.

Why it matters to the business

Applications that use affected rust-openssl versions and inspect OCSP responder URLs from untrusted certificates may be destabilized by malicious or malformed certificates received over the network. The most likely operational consequence is service disruption or application crashes in TLS-processing components, certificate validation services, scanners, proxies, gateways, or other systems that parse external certificates. The current public exploitation signal is low: EPSS is 0.00211 and unchanged over 30 days, the issue is not in CISA KEV, is not associated with ransomware use, and no exploit maturity is reported. However, because the affected code is in a widely used cryptographic binding and the flaw is reachable through certificate parsing, remediation should still be prioritized for internet-facing or certificate-processing software.

How an attack unfolds

An attacker prepares an X.509 certificate whose Authority Information Access extension includes an OCSP responder accessLocation containing bytes that are not valid UTF-8. The attacker then causes a vulnerable Rust application using rust-openssl 0.9.7 through 0.10.78 to process that certificate, for example during a TLS connection, certificate ingestion workflow, certificate scanning task, or validation pipeline. If the application calls X509Ref::ocsp_responders and subsequently treats the returned OpensslString as a Rust string, rust-openssl may construct a &str over invalid UTF-8 bytes using unchecked conversion. This violates Rust’s core string safety assumptions and places the process in undefined behavior. Depending on compiler optimizations and downstream string handling, the result may be a crash, corrupted program state, incorrect validation behavior, or other unpredictable effects. There is no indication from the supplied data that this vulnerability is currently being exploited by named threat actors.

How to fix it

Upgrade the Rust openssl crate to version 0.10.79 or later. The vulnerable range is rust-openssl 0.9.7 through versions before 0.10.79. Review Cargo.lock, workspace dependency constraints, and transitive dependencies to ensure no package continues to resolve to an affected version. Use cargo update -p openssl --precise 0.10.79 where appropriate, or update dependency constraints to allow 0.10.79 or newer. Rebuild and redeploy all affected applications after dependency updates; simply changing manifest files is not sufficient if deployed artifacts are not rebuilt. If immediate upgrade is not possible, reduce exposure by avoiding calls to X509Ref::ocsp_responders on untrusted certificates, rejecting certificates with malformed or non-ASCII Authority Information Access OCSP URI values before passing them to affected code, and isolating certificate-parsing workloads to limit blast radius from crashes or undefined behavior.

How to confirm the fix worked

Confirm remediation by inspecting Cargo.lock or equivalent software bill of materials for the Rust openssl crate and verifying the resolved version is 0.10.79 or later. Run cargo tree -i openssl to identify packages that depend on rust-openssl and ensure all built artifacts use the fixed version. Rebuild from a clean dependency cache and verify deployed binaries or container images were produced after the dependency update. Functional validation should include parsing normal certificates with OCSP AIA entries and, in a controlled test environment, parsing a crafted certificate containing invalid UTF-8 in the OCSP accessLocation to confirm the application no longer crashes or enters unsafe behavior. For externally exposed services, verify certificate ingestion and TLS-processing endpoints are running the updated build, not only the source repository.

Typical attack path

1. Identify a service or tool that parses untrusted X.509 certificates using rust-openssl versions 0.9.7 through 0.10.78.
2. Create or obtain a certificate with an Authority Information Access extension containing an OCSP responder accessLocation with non-UTF-8 bytes.
3. Deliver the certificate to the target through a TLS handshake, certificate upload, scanning target, validation API, or other certificate-processing workflow.
4. Trigger application logic that calls X509Ref::ocsp_responders on the certificate.
5. Cause the vulnerable library to expose invalid bytes as a Rust &str, resulting in undefined behavior in the consuming process.
6. Leverage the resulting crash, corrupted state, or inconsistent behavior for denial of service or other application-specific impact.

How to detect it

To assess possible prior exploitation, focus on systems that process untrusted X.509 certificates and use rust-openssl. Review application logs, TLS gateway logs, certificate ingestion logs, crash telemetry, core dumps, and container restart events for failures occurring while parsing OCSP responder information or Authority Information Access extensions. Look for abnormal process exits, segmentation faults, sanitizer reports, panics, or repeated restarts correlated with incoming TLS connections, certificate uploads, or certificate-scanning jobs. If certificate capture or TLS inspection metadata is available, examine peer or uploaded certificates around the time of crashes and inspect the Authority Information Access extension, especially id-ad-ocsp accessLocation URI values, for bytes outside valid ASCII/UTF-8. There may be no clean network indicator because the exploit is embedded in certificate ASN.1 data and impact depends on application behavior after calling X509Ref::ocsp_responders.

• X509Ref::ocsp_responders
• openssl::x509::X509Ref::ocsp_responders
• str::from_utf8_unchecked
• Authority Information Access
• authorityInfoAccess
• OCSP responder
• accessLocation
• id-ad-ocsp
• 1.3.6.1.5.5.7.48.1
• 1.3.6.1.5.5.7.1.1
• invalid UTF-8
• malformed certificate
• segmentation fault
• SIGSEGV
• core dumped

What your security team should do

• Inventory Rust applications, services, scanners, proxies, agents, and certificate-processing tools that include the openssl crate.
• Prioritize upgrades for internet-facing services and systems that parse certificates from untrusted peers or uploaded content.
• Upgrade the openssl crate to 0.10.79 or later and rebuild/redeploy all affected artifacts.
• Add dependency scanning or SBOM checks that flag rust-openssl versions 0.9.7 through 0.10.78.
• Review crash telemetry, core dumps, and certificate-processing logs for recent failures involving OCSP, Authority Information Access, or malformed certificates.
• Where certificate parsing occurs on untrusted inputs, add defensive validation and process isolation to reduce impact from malformed certificate data.
• Because the issue is not KEV-listed and EPSS is low and stable, treat this as important hygiene unless the affected component is internet-facing or processes arbitrary certificates, in which case treat it as higher priority.