CVE-2023-4807 is a bug in OpenSSL's POLY1305 MAC implementation that corrupts CPU register state on Windows: on x86_64 processors supporting the AVX512-IFMA instruction set, the optimized code path failed to save and restore non-volatile XMM registers, so any ChaCha20-Poly1305 operation — a TLS handshake included — could silently overwrite values the calling application still depended on. The realistic outcome is application-state corruption, most plausibly a crash; the fix shipped in OpenSSL 1.1.1w, 3.0.11, and 3.1.3 in September 2023.
What is CVE-2023-4807?
The OpenSSL project published the advisory on September 8, 2023. The affected code is the assembly-optimized POLY1305 message authentication routine used by the ChaCha20-Poly1305 AEAD cipher. On CPUs advertising AVX512-IFMA, OpenSSL selects a vectorized implementation that uses the XMM register file — and on Windows 64-bit builds, that implementation neglected to preserve registers the platform's calling convention says a called function must leave intact. Affected version ranges are 1.1.1 through 1.1.1v, 3.0.0 through 3.0.10, and 3.1.0 through 3.1.2, on Windows x86_64 only. Linux, macOS, and 32-bit Windows builds are not affected, and neither are machines whose CPUs lack AVX512-IFMA.
Why does the POLY1305 bug only affect Windows?
Because calling conventions differ by platform, and the bug is a calling-convention violation. The Windows x64 ABI designates registers XMM6 through XMM15 as non-volatile: a function that uses them must save and restore them, because the caller is entitled to assume they survive the call. The System V ABI used on Linux and macOS makes all vector registers caller-saved, so the same assembly is perfectly correct there. The POLY1305 AVX512-IFMA path was written to the Unix assumption; on Windows it clobbered registers its callers were still using. It is a compact illustration of why "works on Linux" proves nothing about hand-written assembly on another ABI — and why platform-specific code paths deserve platform-specific testing.
What is the realistic impact?
Here the vendor and the scoring database diverge, instructively. The OpenSSL project rated CVE-2023-4807 Low severity: the attacker does not choose which application values live in the clobbered registers or how they are used next, so steering the corruption toward code execution or key disclosure has no known practical technique. The likely worst case is incorrect computation or a crash in whatever code called into OpenSSL — a denial-of-service and correctness problem. NVD, scoring the theoretical worst case, assigned it a High rating. Both are defensible answers to different questions; for prioritization, the operational translation is: patch it in the normal cycle, expect instability rather than breach, and escalate only if you run ChaCha20-Poly1305-heavy Windows services on very recent server silicon, where the trigger conditions actually line up.
Note the trigger is remote-capable in principle: a TLS peer negotiating a ChaCha20-Poly1305 cipher suite causes the vulnerable routine to run. What the remote peer cannot do is control the consequences with any precision.
Where does affected OpenSSL hide on Windows?
The hard part of CVE-2023-4807 was never the patch — it was the inventory. OpenSSL on Windows is rarely one obvious installation. It ships statically linked inside application binaries, as bundled DLLs (libcrypto-3-x64.dll and friends) beside third-party software, and embedded in language runtimes — Node.js and Python each carry their own OpenSSL, patched on their own release schedules rather than yours. A Windows fleet can easily hold a dozen distinct OpenSSL copies, and OS-level patching reaches almost none of them.
That makes this advisory a supply chain exercise. Binary composition scanning and SBOMs answer the question "which of our applications embed an affected OpenSSL?" far faster than filesystem archaeology; software composition analysis that indexes bundled and statically linked libraries turns the search across a fleet into a query. Teams that had SBOMs for their Windows software handled this advisory in hours; teams that did not were still finding embedded copies weeks later.
Which releases fix it, and what should you do?
Upgrade to 3.1.3, 3.0.11, or later within your branch. For the 1.1.1 line, note the sharper deadline: 1.1.1w contains the fix, but 1.1.1 reached end of public support in September 2023, making it the branch's final public release — anything still pinned there needs a migration plan to 3.x, not just this patch. For bundled copies, the fix arrives through each vendor's or runtime's update, so file the tickets where the embedding happens. Then keep the monitoring on: vendored cryptographic libraries are precisely the dependency class that goes quietly stale. We track advisories like this one, with the vendor-versus-NVD severity context, on the Safeguard blog.
FAQ
Is CVE-2023-4807 exploitable remotely?
The vulnerable code can be triggered remotely — any TLS connection negotiating ChaCha20-Poly1305 with an affected Windows build runs it. But triggering is not controlling: no public technique turns the register corruption into code execution or key recovery. Treat it as a remote stability risk, not a remote compromise.
Does CVE-2023-4807 affect Linux or macOS servers?
No. The bug is a violation of the Windows x64 calling convention specifically; the same assembly is correct under the System V ABI that Linux and macOS use.
How do I know if my hardware is even affected?
The vulnerable path only activates on CPUs supporting AVX512-IFMA — present on some recent Intel cores and notably absent on many others, since consumer lines dropped AVX-512 in later generations. On Windows, tools like Coreinfo report the flag. If the instruction set is absent, the vulnerable code never runs — useful for triage, though patching remains the durable answer since workloads migrate.
Is OpenSSL 1.1.1 still safe to run?
No — independent of this CVE. Public support ended in September 2023 with 1.1.1w as the final open release; subsequent advisories in that branch receive no free patches. Any 1.1.1 deployment should be migrating to the 3.x series or onto a vendor's extended-support contract.