CVE-2026-45446: OpenSSL AES-SIV and AES-GCM-SIV Authentication Bypass

Technical summary

The vulnerability exists in OpenSSL's provider implementation of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) AEAD modes. These algorithms are designed to be nonce-misuse-resistant and authenticate optional Additional Authenticated Data (AAD) alongside encrypted plaintext. The flaw occurs because the authentication tag is only recalculated during the decryption update phase when non-empty ciphertext is present. When an application provides AAD and then calls EVP_DecryptFinal_ex() without invoking the ciphertext update function (which occurs when receiving zero-length ciphertext), the tag remains at its default all-zeros value. For AES-GCM-SIV, this means any attacker can forge messages with arbitrary AAD and empty ciphertext by simply submitting an all-zeros tag. For AES-SIV, the attack requires context reuse without key reset. OpenSSL's built-in protocols (TLS, CMS, PKCS7, HPKE, QUIC) do not use these cipher modes, limiting impact to applications implementing custom protocols.

Business impact

Organizations using OpenSSL for custom cryptographic protocols based on AES-SIV or AES-GCM-SIV face potential message forgery attacks. An attacker could inject fraudulent authenticated messages into the application workflow, potentially bypassing integrity controls designed to prevent tampering. The impact severity depends entirely on protocol design: if the application gracefully rejects zero-length messages or resets the decryption context between operations, the vulnerability may be unexploitable. However, applications that accept authenticated metadata with empty payloads (e.g., certain command or control protocols) could face unauthorized command injection.

Affected systems

This vulnerability affects OpenSSL versions 3.2 and later for AES-GCM-SIV mode, and OpenSSL 3.0 and later for AES-SIV mode. OpenSSL's FIPS modules in versions 3.0 through 4.0 are unaffected because these cipher modes are not FIPS-approved and reside outside the FIPS boundary. The vulnerability does not impact standard TLS, CMS, PKCS7, HPKE, or QUIC implementations, as OpenSSL itself does not use these modes for those protocols. Only custom applications that directly call the EVP interface with AES-SIV or AES-GCM-SIV are at risk.

Exploitability

Exploitation requires multiple specific conditions: the target application must implement a custom protocol using AES-SIV or AES-GCM-SIV via OpenSSL's EVP interface, must accept messages with AAD and empty ciphertext, and must skip the ciphertext update phase when receiving zero-length encrypted data. For AES-GCM-SIV, an unauthenticated attacker on the network can forge messages single-shot without any key material. For AES-SIV, the attacker must additionally cause the application to reuse the decryption context without resetting the key. These constraints mean the vulnerability is not exploitable against standard OpenSSL-based services and requires developers to implement unusual message handling patterns.

Remediation

Apply security updates from OpenSSL once patches addressing this authentication bypass are released. Patches must ensure the authentication tag is computed correctly even when the ciphertext is empty, or that decryption fails gracefully in such scenarios. Organizations should review custom protocol implementations using AES-SIV or AES-GCM-SIV to confirm they validate ciphertext length and reset decryption state between operations. Until patches are available, consider whether your application truly requires these nonce-misuse-resistant modes or if standard AES-GCM is sufficient for your use case.

Patch guidance

Monitor OpenSSL security advisories for patch releases addressing CVE-2026-45446. Patches will be incorporated into upcoming OpenSSL maintenance releases for affected branches. Verify the patch against the official OpenSSL advisory to confirm which versions are fixed. Test patched versions in a staging environment before deploying to production, paying particular attention to any custom cryptographic protocol implementations. FIPS-constrained environments should note that FIPS modules are unaffected and do not require patching for this issue, though updating to patch non-FIPS components is still recommended for consistency.

Detection guidance

Detection is challenging without access to OpenSSL's internal EVP state. Security teams should review application code and dependencies for direct use of EVP_aes_siv() or EVP_aes_gcm_siv() functions. If found, audit the surrounding code for patterns where ciphertext updates are skipped or zero-length ciphertexts are processed. Monitor OpenSSL version inventory; flag systems running OpenSSL 3.0–3.1 (for AES-SIV) and 3.2+ (for AES-GCM-SIV) that use custom cryptographic protocols. Instrument applications to log or alert on zero-length ciphertext events paired with non-empty AAD, as this is the attack pattern.

Why prioritize this

This vulnerability merits prompt attention despite a CVSS score of 4.8 (Medium) because it directly bypasses a core security function: message authentication. The authentication bypass is unconditional for AES-GCM-SIV and requires only moderate preconditions for AES-SIV. However, real-world risk is significantly constrained by the requirement for custom application implementation and specific message handling patterns. Organizations without custom cryptographic protocols using these modes face minimal immediate risk. Those with such protocols should prioritize patching once available. The false-positive risk is low because affected code patterns are distinctive and unlikely to appear accidentally.

Risk score, explained

The CVSS 3.1 score of 4.8 (Medium) reflects a network-exploitable authentication bypass with no user interaction required, but limited scope (only custom application protocols) and loss of both confidentiality and integrity without availability impact. The 'AC:H' (High Attack Complexity) factor accounts for the requirement that applications must implement non-standard message handling (skipping ciphertext updates for empty messages). In practice, organizations not using custom protocols with these modes face negligible risk, while those that do should treat this as a critical authentication control failure warranting immediate patching upon availability.

Frequently asked questions