CVE-2026-45445

What it actually does

This flaw affects applications that use OpenSSL AES-OCB through the lower-level one-shot EVP_Cipher() interface instead of the documented streaming EVP_CipherUpdate()/EVP_CipherFinal_ex() API. In that usage pattern, the caller-provided IV is not applied before encryption or decryption, causing every message encrypted with the same key to reuse the same effective nonce. AES-OCB nonce reuse breaks confidentiality because relationships between plaintexts can be recovered from ciphertexts. If the same pattern is used when generating authentication tags, the tag can become independent of the plaintext or ciphertext and depend only on the key and IV, enabling forged ciphertexts to pass authentication after observing a valid message. OpenSSL TLS/libssl is not affected, AES-OCB is not a TLS cipher suite, and applications using the documented streaming AEAD API are not affected.

Why it matters to the business

Systems that rely on affected AES-OCB encryption code may expose supposedly encrypted data or accept tampered encrypted messages as valid. The practical risk depends heavily on whether an application actually uses AES-OCB with EVP_Cipher(), which is an uncommon and discouraged API pattern. If present in sensitive data exchange, storage encryption, licensing, tokens, backups, or custom protocols, the issue can lead to disclosure of confidential information and possible acceptance of attacker-crafted encrypted content. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS, but cryptographic flaws can have high impact where the vulnerable pattern exists.

How an attack unfolds

An attacker first needs access to an application or protocol path that encrypts or decrypts attacker-observable data using OpenSSL AES-OCB through EVP_Cipher(). The attacker observes or obtains one or more ciphertexts produced under the same encryption key. Because the supplied IV is discarded in the vulnerable one-shot path, messages that should have unique nonces instead reuse the same effective OCB nonce. With repeated keystream material, the attacker can compare ciphertexts and infer plaintext relationships, and in favorable conditions recover plaintext content using known or chosen plaintext. If the application also generates or verifies tags through the affected pattern, a single captured valid message can allow construction of arbitrary ciphertexts that verify under the same key/IV conditions. The attacker then submits forged encrypted content or uses recovered plaintext to compromise downstream business logic. Exploitation is application-specific and requires the vulnerable AES-OCB EVP_Cipher() usage; standard OpenSSL TLS traffic is not a viable attack path.

How to fix it

Upgrade OpenSSL to a vendor-provided fixed release as soon as one is available for the deployed branch. No exact fixed versions were provided in the input, so follow OpenSSL and operating-system package advisories for the authoritative patched versions. In parallel, review application code and remove any use of EVP_Cipher() with AES-OCB. Replace it with the documented streaming AEAD interface: EVP_EncryptUpdate()/EVP_EncryptFinal_ex() and EVP_DecryptUpdate()/EVP_DecryptFinal_ex(), with explicit IV handling and tag get/set controls. If immediate code changes are not possible, disable AES-OCB use in affected components or switch to a well-supported AEAD mode such as AES-GCM or ChaCha20-Poly1305 using documented APIs. Rotate encryption keys used by any confirmed vulnerable AES-OCB implementation and consider re-encrypting affected stored data, because previous ciphertexts may have been exposed by nonce reuse. OpenSSL FIPS modules in the listed branches are not affected because AES-OCB is outside the FIPS module boundary.

How to confirm the fix worked

Confirm exposure with both dependency and code-level checks. Inventory OpenSSL versions and linked applications, then search source code and binaries for AES-OCB use combined with EVP_Cipher(). A system is exposed only if AES-OCB and the one-shot EVP_Cipher() interface are used together. Validate remediation by confirming the application no longer calls EVP_Cipher() for AES-OCB and instead uses EVP_CipherUpdate()/EVP_CipherFinal_ex() or another safe AEAD mode. Add a regression test that encrypts the same plaintext under the same key with distinct IVs and verifies that ciphertext and tag outputs differ as expected, and a negative test confirming that modified ciphertext or tags fail verification. For packaged OpenSSL, verify that the installed package version matches the vendor advisory's fixed build. TLS scanner results alone are not sufficient because OpenSSL TLS is not affected by this issue.

Typical attack path

1. Identify an application, custom protocol, file format, token format, or data exchange mechanism using OpenSSL AES-OCB.
2. Confirm or infer that the implementation drives the cipher with EVP_Cipher() rather than EVP_CipherUpdate()/EVP_CipherFinal_ex().
3. Capture ciphertexts encrypted under the same key, ideally where different IVs were expected to provide uniqueness.
4. Exploit effective nonce reuse to compare ciphertexts and recover plaintext relationships or plaintext bytes using known/chosen plaintext opportunities.
5. If authentication tags are generated by the affected code path, use a captured valid message to craft ciphertext that is accepted as authentic.
6. Submit the recovered or forged encrypted content to access confidential data, bypass integrity checks, or alter application behavior.

How to detect it

There are unlikely to be reliable host or network indicators that prove exploitation, because this is a cryptographic misuse flaw and exploitation may look like normal encrypted traffic or normal application messages. Start by determining whether the vulnerable pattern exists: review source repositories, build artifacts, SBOMs, and static-analysis results for AES-OCB combined with EVP_Cipher(). For already-exploited assessment, examine application logs for unusual acceptance of encrypted messages, tokens, files, or protocol frames that should have failed authentication; unexpected successful decryptions after ciphertext modification; repeated processing of encrypted objects with differing recorded IVs but anomalously similar ciphertext structure; and unexplained access to data protected only by the affected encryption layer. If encrypted messages are logged or captured with metadata, look for multiple AES-OCB records under the same key domain where IVs differ but ciphertext XOR patterns reveal repeated keystream behavior, especially when known plaintext headers or fixed fields are present. Review key-management logs for the affected keys and correlate suspicious decrypt/verify operations with external requests. Absence of such evidence does not rule out exploitation; prioritize determining exposure and rotating keys for confirmed vulnerable uses.

• EVP_Cipher(
• EVP_aes_128_ocb
• EVP_aes_192_ocb
• EVP_aes_256_ocb
• AES-OCB
• OCB mode
• EVP_EncryptFinal_ex(
• EVP_DecryptFinal_ex(
• EVP_CIPHER-OCB

What your security team should do

• Prioritize code and dependency inventory for applications using OpenSSL directly, especially custom encryption, token, file encryption, backup, messaging, or proprietary protocol components.
• Search for AES-OCB usage and specifically flag any use of EVP_Cipher() with EVP_aes_128_ocb, EVP_aes_192_ocb, or EVP_aes_256_ocb.
• Patch OpenSSL when fixed vendor packages are available, but do not rely on library patching alone; vulnerable application API usage should be corrected.
• Disable or replace AES-OCB in applications where rapid code review is not feasible.
• Rotate keys and assess whether historical encrypted data needs re-encryption for any confirmed vulnerable implementation.
• Add secure cryptographic API usage checks to CI/CD, including bans or review gates for EVP_Cipher() in AEAD code.
• Because there is no KEV listing and no known ransomware use, prioritize based on confirmed AES-OCB EVP_Cipher() exposure and data sensitivity rather than broad TLS exposure.