Use-After-Free Race in OpenSSL 4.0 Certificate Cache Allows Remote DoS
CVSS 3.1
7.5high
EPSS
—
Published
()
Modified
AI analysis
OpenSSL 4.0 builds the cached X.509v3 extension data of a certificate in two phases — computing values under a read lock, then installing them under a write lock — which lets several threads racing on the same certificate each free the results installed by the previous thread, yielding a use-after-free read. In practice, a remote, unauthenticated attacker can trigger this by opening several TLS connections at the same time so that the first certificate chains to the same trusted CA certificate are built concurrently, crashing a multi-threaded TLS client or a multi-threaded TLS server that requests and verifies client certificates (mutual TLS). The impact is denial of service only — no confidentiality or integrity impact — and peer-supplied certificates are not affected because they are decoded per-connection. Only OpenSSL 4.0 is vulnerable; the 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 branches are not affected, and the fix ships in OpenSSL 4.0.3. There is no known public proof of concept and no indication of exploitation in the wild.
What to do: Upgrade OpenSSL 4.0.x installations to OpenSSL 4.0.3; verify with 'openssl version' and apply vendor security updates that pick up the fixed release. Deployments on OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 or 1.0.2 require no action for this issue. If immediate patching of a vulnerable 4.0 deployment is not possible, prioritize internet-facing multi-threaded TLS servers that request client certificates and multi-threaded TLS clients, and consider pre-warming the trusted-CA extension cache (performing one full chain verification at startup before concurrent connections are accepted) to close the race window.
Affected
OpenSSL
4.0.0 through 4.0.2 (all 4.0 releases before 4.0.3)
Estimated exposure
nicheunknown count; plausibly on the order of thousands of hosts worldwide running early-adopter OpenSSL 4.0 builds — OpenSSL 4.0 is a very recent major version that mainstream Linux distributions have not yet broadly shipped (they remain on 3.x), so exposure is largely limited to bleeding-edge distributions, custom builds, and early adopters; the race…
Description
Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it. Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service. CWE: CWE-416: Use After Free Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory. Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time. FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary. OpenSSL 4.0 is vulnerable to this issue. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan. The fix has been developed by Bob Beck. -- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck
OpenSSL patches high-severity DTLS flaw CVE-2026-84782 (CVSS 8.2) that can leak unencrypted heap memory or crash DTLS connections.
CVE-2026-84782 is a high-severity OpenSSL flaw where a DTLS handshake message resend during a paused larger message send can transmit mislabeled data containing heap memory as unencrypted handshake data, or crash on unmapped memory. Fixes are available in OpenSSL 4.0.3, 3.6.5, 3.5.9 and 3.4.8, while 3.0, 1.1.1 and 1.0.2 fixes are limited to premium support customers. CISA assigned CVSS 8.2 and listed exploitation as none. The September 29 releases also fix 13 other flaws, including moderate CVE-2026-84783 (crash in multithreaded TLS) and low CVE-2026-75806 (DTLS 1.2 AEAD connection reset).
OpenSSL and wolfSSL patched roughly 25 vulnerabilities, including an 8.2-rated DTLS heap data leak and certificate authentication bypasses affecting Nginx and HAProxy builds.
OpenSSL fixed 14 flaws, led by CVE-2026-84782 (CVSS 8.2), which lets an unauthenticated remote peer obtain heap memory fragments or crash DTLS applications common in VPNs, VoIP and IoT products. wolfSSL 5.9.4 patches 11 vulnerabilities including three high-severity authentication bypasses (CVE-2026-93302, CVE-2026-89102, CVE-2026-89136) enabling server impersonation and forged certificates. Remaining flaws mainly cause DoS, QUIC DDoS amplification, or timing side-channel leaks relevant to private key recovery. No exploitation was reported.