CVE-2026-84783

What it actually does

OpenSSL 4.0 caches decoded X.509v3 extension values on the shared X509 object the first time they are needed. That cache is built in two phases: values are computed under a read lock, then installed under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate concurrently. Each thread that later takes the write lock installs its own results and frees values installed by the previous writer, even though an earlier thread may already have marked the cache complete and returned pointers into it. Callers still using those pointers perform a use-after-free read, which typically aborts the process. Only shared certificates are exposed, and only on first concurrent decode. In TLS, that means trusted CA certificates used for chain verification; per-connection peer certificates are not shared and are not affected. The FIPS module is not affected because X.509 handling sits outside the FIPS module boundary. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 are not affected.

Why it matters to the business

A remote, unauthenticated peer can crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, causing denial of service until the process is restarted. Confidentiality and integrity are not impacted; this is an availability issue (CVSS 7.5). The advisory is five days old, is not in CISA KEV, is not associated with ransomware campaigns, and has no known exploit maturity, so mass exploitation is not indicated—but any internet-facing or high-concurrency TLS service still on OpenSSL 4.0 can be taken down by coincidental or deliberate concurrent first-time chain builds to the same trusted CA. Restart loops under load amplify operational cost. Apply upstream 4.0.3 or the matching Red Hat updates promptly on affected TLS stacks.

How an attack unfolds

The attacker does not need credentials or a malicious certificate. They only need to cause several TLS connections at once to perform their first chain build to the same trusted CA while the target process is using OpenSSL 4.0. On a multi-threaded TLS client this can be done by inducing the client to open parallel sessions whose chains terminate at that CA. On a multi-threaded TLS server that requests client certificates, parallel handshakes that trigger verification against the same trusted CA produce the same race. Threads concurrently decode extensions on the shared CA certificate; a later writer frees cache memory still referenced by an earlier thread; the process reads freed memory and crashes. Peer-supplied certificates are decoded per connection and do not trigger the bug. No named threat actors or in-the-wild campaigns are associated with this issue, and exploit maturity is none, so the realistic scenario is opportunistic or coincidental concurrency rather than a packaged exploit kit.

How to fix it

Upgrade OpenSSL 4.0 to OpenSSL 4.0.3 (or later in the 4.0 line) and rebuild or restart every process that dynamically or statically links it. For Red Hat openssl3-main, install 3.5.8-1.hum1 via RHSA-2026:59641; for Red Hat openssl-main, install 3.5.8-0.1.hum1 via RHSA-2026:59641; then restart dependent services. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 do not require a fix for this issue. The FIPS module is not affected. There is no practical configuration workaround: reducing first-time concurrent chain builds is unreliable under real load. After upgrade, confirm no remaining OpenSSL 4.0.0–4.0.2 libraries remain on disk or in running process maps.

How to confirm the fix worked

Inventory TLS clients and servers and record the OpenSSL version actually loaded at runtime (package version, linked soname, and process maps), not only the package that was installed. Affected is OpenSSL 4.0 before 4.0.3. Confirm openssl version / package NVR shows 4.0.3 or later, or Red Hat openssl3-main 3.5.8-1.hum1 / openssl-main 3.5.8-0.1.hum1 from RHSA-2026:59641. Restart all long-lived TLS processes after the library update so they pick up the new code. In a staging environment, drive concurrent first-time chain builds to a shared trusted CA against a patched multi-threaded client or client-auth server and confirm the process remains stable. Verify FIPS-only stacks if relevant; this defect is outside the FIPS module. Re-scan images and hosts for leftover 4.0.0–4.0.2 libraries.

Typical attack path

1. Identify a multi-threaded TLS client, or a TLS server that requests and verifies client certificates, linked to OpenSSL 4.0.
2. Determine that verification uses shared trusted CA certificates (the objects whose extensions are cached across connections).
3. Open several connections at the same time so the first chains to that CA are built concurrently.
4. Trigger the two-phase extension-cache race: multiple threads compute under the read lock, then each writer installs and frees the previous cache.
5. A surviving thread reads freed extension data; the process crashes and TLS service is denied until restart.
6. Repeat the concurrent first-use pattern after restart if the process is still unpatched, sustaining the outage.

How to detect it

This defect leaves crash artifacts, not a distinctive network payload or planted file. Look for unexpected exits, coredumps, or orchestrator restart loops of multi-threaded TLS clients and of TLS servers that request client certificates, especially immediately after process start or after a CA store reload—the window of first concurrent chain builds to a shared trusted CA. Correlate those crashes with a spike of parallel TLS handshakes. On hosts still running OpenSSL 4.0 before 4.0.3, inspect core files and fatal-signal logs for stacks in X.509 extension decode/cache install on a shared CA certificate. Peer certificate paths are not the trigger. There are no associated threat-actor TTPs, KEV activity, or ransomware notes to pivot from; absence of crashes does not prove the library was unexposed, only that the race may not have been hit.

What your security team should do

• Patch OpenSSL 4.0 to 4.0.3 (or apply RHSA-2026:59641: openssl3-main 3.5.8-1.hum1, openssl-main 3.5.8-0.1.hum1) and restart TLS processes immediately—do not wait for KEV listing.
• Inventory multi-threaded TLS clients and TLS servers that request client certificates; deprioritize stacks on OpenSSL 3.6/3.5/3.4/3.0/1.1.1/1.0.2 and FIPS-module-only X.509 handling.
• Hunt for leftover OpenSSL 4.0.0–4.0.2 in containers, statically linked binaries, language runtimes, and sidecar images after the package update.
• Watch for unexplained crashes or restart storms on TLS services during the first burst of connections after process start, which is when the cache is first populated.
• Treat this as an availability patch, not a confidentiality incident; no evidence of ransomware or named-actor exploitation at this time.