CVE-2026-84783 in OpenSSL
Summary
by MITRE • 09/29/2026
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
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
A critical concurrency vulnerability exists within the X.509 certificate handling logic of OpenSSL version 4.0, classified under CWE-416 as a Use After Free error. This flaw arises from an unsafe implementation detail in how decoded extension data is cached and managed across multiple threads simultaneously. The core technical issue stems from a race condition during the initialization phase of certificate cache population. When OpenSSL encounters a new X.509 certificate for which it has not yet computed or stored the values of its extensions, it initiates a two-phase caching process. In the first phase, the system computes these extension values while holding only a read lock on the certificate object. Because standard reader-writer locks allow multiple concurrent readers, this design permits several threads to enter this computation stage simultaneously for the same shared certificate instance.
The vulnerability manifests in the second phase of the caching operation, where each thread attempts to install its computed results into the central cache structure under a write lock. Since multiple threads may have completed their computations concurrently while holding read locks, they will sequentially acquire the exclusive write lock one after another. The first thread to secure the write lock successfully installs its data and marks the cache as complete. However, subsequent threads that also acquired the write lock proceed to overwrite this existing cached data with their own independently computed results. Crucially, before installing new data, these later threads free the memory associated with the previously installed values. This creates a dangerous state where earlier threads, which have already returned pointers into the cache structure to their respective callers, now hold references to memory that has been deallocated by subsequent threads acquiring the write lock.
This race condition leads directly to a use-after-free read scenario when an initial thread attempts to access or utilize the cached extension data it believes is still valid and resident in memory. The operational impact of this flaw is severe for multi-threaded TLS implementations, particularly those acting as clients verifying server certificates or servers requesting client authentication. In these scenarios, trusted CA certificates are shared across all active connections within a single process context to optimize performance by avoiding redundant cryptographic operations. If multiple concurrent connections trigger the verification chain building against the same set of trusted CAs at nearly identical times, they will likely hit this race condition during their first interaction with those specific certificate extensions. The resulting memory corruption typically causes an immediate crash or segmentation fault in the TLS process, leading to a reliable Denial of Service attack vector for any service relying on OpenSSL 4.0 without additional synchronization mechanisms.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates remote unauthenticated denial-of-service attacks. An attacker does not need valid credentials or prior authentication; they merely need to initiate multiple concurrent TLS handshakes that involve chain verification against the same trusted root certificates. The ability to crash the service disrupts availability for all users of the affected system. It is important to note that this vulnerability specifically impacts OpenSSL version 4.0 and does not affect earlier major releases such as versions 3.6, 3.5, 3.4, 3.0, 1.1.1, or 1.0.2 due to differences in their internal locking strategies or cache management implementations. Furthermore, the FIPS module is unaffected because X.509 certificate handling resides outside the boundary of the cryptographic modules governed by Federal Information Processing Standards compliance requirements.
Mitigation for this issue requires immediate action from administrators and developers utilizing OpenSSL 4.0. The recommended course of action is to upgrade to OpenSSL version 4.0.3 or later, where the concurrency flaw has been resolved through improved synchronization logic that prevents multiple threads from concurrently modifying shared cache structures without proper mutual exclusion during both computation and installation phases. Until an upgrade can be performed, operators may consider implementing application-level serialization for certificate verification operations if feasible within their architecture, though this would significantly impact performance. The vulnerability was reported by Tim Becker of Xint.io on August 27, 2026, with independent confirmation provided by aydinmercan shortly thereafter. The fix was developed and implemented by Bob Beck to ensure thread-safe handling of certificate extension caching in multi-threaded environments.