CVE-2026-35188

What it actually does

This vulnerability is a memory corruption flaw in OpenSSL client-side TLS certificate verification when OCSP stapling is enabled. A malicious TLS server can send a crafted stapled OCSP response through the TLS status_request extension, causing the client to free the same memory twice during verification. The most direct result is client process crash or denial of service. In some allocator, platform, and application conditions, the heap corruption could potentially be shaped into limited confidentiality or integrity impact, including possible code execution, but reliable exploitation is expected to be difficult and environment-dependent. OpenSSL FIPS modules are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Organizations are primarily exposed where applications, agents, scanners, proxies, package managers, or other OpenSSL-based TLS clients explicitly enable OCSP stapling and connect to untrusted or attacker-controlled servers. The likely operational consequence is disruption of those client processes when they reach a malicious endpoint, which can interrupt service checks, outbound integrations, automated downloads, monitoring, or user-facing workflows that depend on TLS connections. The CVSS score is moderate, EPSS is currently low and flat, there is no known KEV listing, no ransomware association, and no public exploit maturity reported, so this should be handled as a planned but important cryptographic library update rather than an emergency internet-wide incident unless OCSP stapling is enabled in high-risk clients.

How an attack unfolds

An attacker first needs the vulnerable software to act as a TLS client and connect to a server the attacker controls or can impersonate. The client must have OCSP stapling enabled, which is not the default OpenSSL behavior. During the TLS handshake, the attacker’s server uses the status_request extension path to deliver a specially crafted stapled OCSP response. When the client validates the server certificate and processes the stapled OCSP data, the vulnerable OpenSSL verification path mishandles memory ownership and frees the same object twice. This corrupts heap state and can crash the client process. More advanced exploitation would require precise control of heap layout and application behavior after the double-free, making code execution possible in theory but not expected to be broadly reliable.

How to fix it

Upgrade OpenSSL to a vendor-supported release that contains the fix as soon as it becomes available through the operating system, appliance, container base image, language runtime, or application vendor. No exact fixed version was provided in the input, so track the relevant OpenSSL security advisory and downstream package advisories for the precise patched package versions. Rebuild and redeploy statically linked applications, containers, appliances, and embedded agents that bundle OpenSSL rather than relying only on operating-system package updates. If immediate patching is not possible, disable client-side OCSP stapling/status_request processing where operationally acceptable, restrict vulnerable clients from connecting to untrusted TLS servers, and prefer trusted allowlisted endpoints for automated outbound TLS workflows. FIPS-only usage is not a sufficient general mitigation unless the affected code path is demonstrably not present or not used by the application.

How to confirm the fix worked

Confirm exposure by identifying OpenSSL versions in deployed operating systems, containers, appliances, and statically linked binaries, then determine whether those clients enable OCSP stapling/status_request processing. Validate remediation by confirming the installed OpenSSL package or bundled library version matches the vendor-fixed release once published, restarting dependent services so they load the patched library, and rescanning images and hosts for vulnerable OpenSSL builds. Where source or configuration is available, review application TLS configuration for OCSP stapling client options. Functional validation can include connecting patched clients to a controlled TLS test service that sends malformed or unusual stapled OCSP responses and confirming the process no longer crashes, but such testing should be performed only in a lab or staging environment.

Typical attack path

1. Identify software using affected OpenSSL versions as a TLS client with OCSP stapling explicitly enabled.
2. Cause or wait for that client to connect to an attacker-controlled TLS service, malicious mirror, compromised endpoint, or impersonated service.
3. Negotiate a TLS handshake that exercises the status_request OCSP stapling path.
4. Return a crafted stapled OCSP response designed to trigger the double-free during certificate verification.
5. Crash the client process or attempt to manipulate heap state for more advanced exploitation.
6. Repeat connections as needed to sustain denial of service against affected client workflows.

How to detect it

To assess prior exploitation, focus on evidence of affected OpenSSL-based client processes crashing while making outbound TLS connections, especially to unusual or newly contacted servers. Review application logs, system journals, endpoint detection telemetry, crash reporters, core dump directories, and container termination events for crashes involving OpenSSL, OCSP, certificate verification, or heap allocator double-free messages. Network telemetry may show repeated outbound TLS handshakes to the same external host shortly before process termination, with use of the TLS status_request extension and stapled OCSP responses if full TLS handshake metadata is captured. Because exploitation occurs inside encrypted handshake processing and the attacker-controlled payload is not normally logged, absence of a specific log string does not prove non-exploitation. Correlate process crashes with destination IPs/domains, certificate validation errors, OCSP stapling messages, and abnormal restart loops. If core dumps are available, inspect backtraces for OpenSSL OCSP or certificate verification functions and heap corruption indicators.

• status_request
• OCSP stapling
• stapled OCSP
• OCSP response
• double free
• free(): double free
• double free or corruption
• corrupted double-linked list
• malloc(): unaligned tcache chunk detected
• malloc_consolidate(): invalid chunk size
• certificate verify
• certificate verification
• libssl
• libcrypto
• openssl
• core dumped
• Segmentation fault

What your security team should do

• Inventory OpenSSL usage across hosts, containers, appliances, agents, and statically linked applications, prioritizing systems that initiate outbound TLS connections to untrusted or internet-controlled destinations.
• Determine which applications explicitly enable client-side OCSP stapling/status_request processing; prioritize those for upgrade or mitigation.
• Monitor vendor advisories for exact fixed OpenSSL and downstream package versions, then patch and restart affected services once fixes are available.
• Temporarily disable OCSP stapling in vulnerable TLS clients where feasible, especially for automated clients that connect to arbitrary URLs, mirrors, partner endpoints, or user-supplied destinations.
• Restrict outbound TLS connections from sensitive automated clients to known-good destinations where business processes allow.
• Search crash logs, core dumps, and endpoint telemetry for OpenSSL-linked client crashes occurring during TLS handshakes or OCSP validation.
• Because EPSS is low, exploit maturity is none, and this is not in KEV, handle via risk-based patching cadence unless local exposure confirms OCSP stapling is enabled in critical clients.