CVE-2026-45446

What it actually does

OpenSSL provider implementations of AES-SIV and AES-GCM-SIV can incorrectly authenticate messages when the ciphertext length is zero. In the affected decryption flow, Additional Authenticated Data (AAD) may be supplied, but if no ciphertext update is performed because the ciphertext is empty, the expected authentication tag is not recomputed and can remain an all-zero value. For AES-GCM-SIV, this allows a remote attacker to submit arbitrary AAD, an empty ciphertext, and an all-zero 16-byte tag that verifies successfully without knowing the encryption key. For AES-SIV, exploitation additionally requires an application pattern that reuses a decryption context without resetting the key. The issue affects applications that implement custom protocols using the OpenSSL EVP interface with AES-SIV or AES-GCM-SIV; OpenSSL’s own TLS, CMS, PKCS7, HPKE, and QUIC protocol implementations are not affected.

Why it matters to the business

The main risk is that custom applications relying on AES-SIV or AES-GCM-SIV for message authenticity may accept forged empty messages as legitimate. This could allow unauthorized commands, metadata, state transitions, or control messages if those applications treat AAD as security-relevant input. The practical exposure is narrower than many OpenSSL issues because exploitation requires specific cipher use, custom protocol behavior, and empty-ciphertext handling. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, but organizations using OpenSSL broadly should still assess custom cryptographic integrations because OpenSSL is widely embedded in downstream software.

How an attack unfolds

An attacker first identifies an application or service that uses OpenSSL’s EVP interface with AES-GCM-SIV or AES-SIV in a custom protocol. The attacker then determines whether the protocol permits messages with authenticated AAD but an empty ciphertext body. For AES-GCM-SIV, the attacker can craft a message containing arbitrary AAD, zero-length ciphertext, and a 16-byte all-zero authentication tag. If the application’s decryption path supplies the AAD and then finalizes decryption without processing any ciphertext data, the OpenSSL provider implementation may incorrectly treat the all-zero tag as valid. The application may then process the attacker-controlled AAD as authenticated. For AES-SIV, the same class of forgery requires the additional condition that the application reuses a decryption context without resetting the key. Successful exploitation depends heavily on how the application maps AAD to authorization, command semantics, routing, message type, identity, or business logic.

How to fix it

Upgrade OpenSSL to a version containing the vendor fix once available from the OpenSSL project or operating system/package maintainers, then restart or redeploy all applications that dynamically link to OpenSSL and rebuild applications that statically link it. Because no fixed versions were provided in the input, use the authoritative advisory for the deployed OpenSSL branch and the relevant distribution package changelog. As compensating controls, inventory custom code and third-party components that call EVP with AES-SIV or AES-GCM-SIV; reject or strictly validate zero-length ciphertext messages using these modes until patched; do not treat AAD-only messages as authoritative unless the cryptographic library is fixed; avoid AES-SIV/AES-GCM-SIV in affected OpenSSL provider paths where feasible; and ensure decryption contexts are freshly initialized or correctly reset between messages, especially for AES-SIV. The OpenSSL FIPS modules for the listed branches are not affected because these algorithms are outside the FIPS module boundary.

How to confirm the fix worked

Confirm the installed OpenSSL package or embedded library version includes the vendor fix for this issue. Verify both runtime and build-time linkage because applications may statically link OpenSSL or bundle their own copy. Review application code for use of EVP cipher implementations corresponding to AES-SIV or AES-GCM-SIV and for decryption paths that process AAD and then finalize without a ciphertext update when ciphertext length is zero. Add or run regression tests that attempt to decrypt a message with arbitrary AAD, empty ciphertext, and a 16-byte all-zero tag; the fixed behavior should reject the message. Validate that services were restarted after package updates and that container images, appliances, language runtime bindings, and vendored dependencies have been rebuilt or refreshed.

Typical attack path

1. Identify an application or service using OpenSSL 3.x EVP APIs with AES-SIV or AES-GCM-SIV in a custom protocol.
2. Confirm the protocol accepts messages where AAD is present but ciphertext length is zero.
3. Craft a message with attacker-controlled AAD, empty ciphertext, and a 16-byte all-zero authentication tag.
4. Send the forged message to the target service over the normal application protocol.
5. Rely on the vulnerable OpenSSL decryption flow to finalize successfully without recomputing the expected tag.
6. Trigger application behavior that trusts the forged AAD as authenticated data.
7. For AES-SIV specifically, exploitability also depends on decryption context reuse without resetting the key.

How to detect it

This vulnerability does not create a universal host-level artifact, process name, file path, or registry key. Detection depends on application and protocol telemetry. Review logs from services that use AES-SIV or AES-GCM-SIV for records of successful decryptions or accepted requests where ciphertext length is zero, AAD is present, and the authentication tag is all zeros. Pay particular attention to AAD-only messages that caused authorization decisions, command execution, state transitions, object creation, metadata changes, or other sensitive actions. Network inspection may be possible only where the custom protocol format exposes the tag and ciphertext length; look for empty encrypted payload fields paired with a 16-byte all-zero tag. Source-code and binary review can help scope exposure by searching for EVP usage of AES-SIV or AES-GCM-SIV, calls to EVP_DecryptFinal_ex, and conditional logic that skips ciphertext update processing for zero-length payloads. For suspected exploitation, correlate unusual AAD-only accepted messages with downstream application actions and account/session context at the same timestamp.

• 00000000000000000000000000000000
• AES-GCM-SIV
• AES-SIV
• EVP_DecryptFinal_ex

What your security team should do

• Prioritize inventory of systems and applications using OpenSSL 3.x with custom cryptographic protocols, especially those using AES-GCM-SIV or AES-SIV through EVP APIs.
• Patch OpenSSL through vendor-supported packages or rebuild bundled/static OpenSSL copies as soon as fixed builds are available.
• Ask application teams to review whether AAD-only or zero-ciphertext messages are accepted and whether AAD influences authorization, command handling, identity, routing, or state changes.
• Temporarily block, reject, or add explicit application-layer validation for zero-length ciphertext messages using AES-SIV or AES-GCM-SIV where operationally safe.
• Add negative cryptographic tests for empty ciphertext plus all-zero tag cases to CI/CD test suites for affected custom protocols.
• Hunt application logs for accepted zero-length encrypted messages, all-zero authentication tags, unusual AAD-only requests, or state-changing operations with no encrypted payload.
• Track vendor advisories for downstream products that bundle OpenSSL, not only operating system OpenSSL packages.
• Treat internet-exposed custom services using these cipher modes with higher urgency, even though the vulnerability is not currently KEV-listed and EPSS is low.