OpenSSL 1.1.1 < 1.1.1w Vulnerability

CVE-2023-4807 is a bug in OpenSSL's POLY1305 MAC implementation that fails to restore non-volatile XMM registers after processing data larger than 64 bytes on Windows 64-bit systems running on processors with AVX512-IFMA instruction support (Intel Ice Lake and later). The registers are zeroed instead of being restored, which can corrupt application state. Affected versions span OpenSSL 1.1.1 through 1.1.1v, 3.0.0 through 3.0.10, and 3.1.0 through 3.1.2. Fixed in 1.1.1w, 3.0.11, and 3.1.3. Notably, 1.1.1w is the final release of the 1.1.1 branch, which went EOL on September 11, 2023.

The NVD-assigned CVSS 7.8 HIGH is wildly misleading here. The vector claims C:H/I:H/A:H — full confidentiality, integrity, and availability impact — but the actual behavior is that XMM registers get *zeroed*, not overwritten with attacker-controlled data. The OpenSSL project itself explicitly rates this LOW severity. There is no path to code execution, no data exfiltration, and no integrity violation beyond garbled calculations. The realistic worst case is a TLS connection producing incorrect AEAD results or crashing. The CVSS score is a mechanical artifact that doesn't survive contact with the actual bug report.

Why this verdict

• Vendor self-assessment override: OpenSSL rates this LOW despite NVD's mechanical 7.8. The project that wrote the code says the C:H/I:H claims are unsupported — the attacker zeroes registers, they don't control them.
• Platform restriction compounds friction: Bug is Windows 64-bit *only*, on AVX512-IFMA CPUs *only*. Most enterprise OpenSSL usage on Windows goes through SChannel, and most servers still run pre-Ice Lake hardware. The reachable population is a small fraction of the installed base.
• No offensive utility demonstrated: No PoC, no known affected application, no path from register zeroing to code execution or data exfiltration. The worst case is a process crash that a supervisor restarts.
• Role multiplier: OpenSSL is embedded in high-value components (web servers, load balancers, identity proxies). However, this specific bug (a) only fires on Windows+AVX512-IFMA, (b) maxes out at DoS/crash, and (c) has no path to domain takeover, data exfiltration, or supply-chain compromise. Even on a domain controller running OpenSSL on Windows with an Ice Lake CPU, the outcome is a service restart — not credential theft. The blast radius is host-level DoS, not fleet-scale compromise, so the role multiplier does not elevate the floor beyond LOW.

Why not higher?

Elevating to MEDIUM or above would require either a demonstrated path to code execution, attacker-controlled register values, or evidence of real-world exploitation — none of which exist. The OpenSSL project's own LOW rating, the absence of any PoC, and the narrow hardware prerequisite (AVX512-IFMA on Windows only) all argue against a higher bucket. The CVSS C:H/I:H ratings are not substantiated by the bug's actual behavior.

Why not lower?

IGNORE would be appropriate only if the bug were entirely theoretical or affected zero real deployments. While the population is small, AVX512-IFMA CPUs *do* exist in production (Ice Lake Xeons in newer data centers), and OpenSSL *is* used on Windows in some environments (e.g., Node.js servers, custom apps linking libssl). A defender should still track this for completeness, especially given the 1.1.1 EOL status which is a separate and more urgent concern.

1. Set OPENSSL_ia32cap=:~0x200000 on affected Windows hosts — This environment variable disables AVX512-IFMA instructions at OpenSSL runtime, completely neutralizing the vulnerable code path. No performance impact for most workloads. Deploy via GPO or configuration management. No mitigation SLA applies at LOW severity — treat as backlog.
2. Prefer AES-GCM ciphers over CHACHA20-POLY1305 in TLS configuration — Remove or deprioritize CHACHA20-POLY1305 from server cipher suites. This eliminates the trigger path. Most Windows servers already prefer AES-GCM.
3. Migrate off OpenSSL 1.1.1 entirely (EOL since September 2023) — The real risk here is running an EOL cryptographic library, not this specific CVE. Upgrade to OpenSSL 3.0.x LTS or 3.1.x+ to receive ongoing security patches. This addresses the CVE and the broader unsupported-software risk simultaneously.

Run on each Windows host where OpenSSL 1.1.1 may be installed. Execute as a standard user in PowerShell: .\check-cve-2023-4807.ps1. No admin privileges required.

#!/usr/bin/env pwsh
# check-cve-2023-4807.ps1 — Detect CVE-2023-4807 exposure
# Target: Windows hosts with OpenSSL 1.1.1
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

$ErrorActionPreference = 'SilentlyContinue'
$found = $false
$vulnerable = $false

# Check common OpenSSL binary locations
$searchPaths = @(
    "$env:ProgramFiles\OpenSSL*\bin\openssl.exe",
    "$env:ProgramFiles(x86)\OpenSSL*\bin\openssl.exe",
    "$env:SystemRoot\System32\openssl.exe",
    "$env:LOCALAPPDATA\Programs\*\openssl.exe"
)

# Also check PATH
$pathOpenSSL = Get-Command openssl.exe -ErrorAction SilentlyContinue
if ($pathOpenSSL) { $searchPaths += $pathOpenSSL.Source }

$binaries = @()
foreach ($p in $searchPaths) {
    $binaries += Get-Item $p -ErrorAction SilentlyContinue
}
$binaries = $binaries | Select-Object -Unique

if ($binaries.Count -eq 0) {
    Write-Host 'UNKNOWN — no OpenSSL binary found on this host.'
    exit 2
}

foreach ($bin in $binaries) {
    $verOutput = & $bin.FullName version 2>&1
    if ($verOutput -match 'OpenSSL\s+(1\.1\.1)([a-v]?)\s') {
        $found = $true
        $letter = $Matches[2]
        # 1.1.1 through 1.1.1v are vulnerable; 1.1.1w is fixed
        if ($letter -eq '' -or $letter -lt 'w') {
            $vulnerable = $true
            Write-Host "VULNERABLE — $($bin.FullName) reports: $verOutput"
        } else {
            Write-Host "PATCHED — $($bin.FullName) reports: $verOutput"
        }
    } elseif ($verOutput -match 'OpenSSL\s+3\.') {
        Write-Host "INFO — $($bin.FullName) is OpenSSL 3.x (check separately): $verOutput"
    }
}

# Check CPU for AVX512-IFMA
try {
    $cpuInfo = Get-CimInstance Win32_Processor | Select-Object -First 1
    Write-Host "CPU: $($cpuInfo.Name)"
} catch {}

# Check mitigation env var
$cap = [Environment]::GetEnvironmentVariable('OPENSSL_ia32cap', 'Machine')
if ($cap -and $cap -match '~0x200000') {
    Write-Host 'NOTE: OPENSSL_ia32cap mitigation is SET (AVX512-IFMA disabled). Bug is neutralized.'
    if ($vulnerable) {
        Write-Host 'PATCHED (via workaround)'
        exit 0
    }
}

if ($vulnerable) { exit 1 }
if ($found) { exit 0 }
Write-Host 'UNKNOWN — could not determine OpenSSL 1.1.1 version.'
exit 2

Sources

1. Tenable Plugin 181288
2. OpenSSL Advisory for CVE-2023-4807
3. Wiz Vulnerability Database — CVE-2023-4807
4. FIRST EPSS API — CVE-2023-4807
5. OpenSSL 1.1.1 End of Life Announcement
6. Red Hat CVE Page — CVE-2023-4807
7. SentinelOne Vulnerability Database — CVE-2023-4807