CVE-2026-75803: OpenSSL Empty-Ciphertext AEAD Tag Verification Failure

CVE-2026-75803 is a low-severity but security-significant OpenSSL integrity-check flaw in a narrow API pattern. ChaCha20-Poly1305 and AES-OCB decryption can report success without verifying the supplied authentication tag when an application processes an empty ciphertext and finalizes the operation through the one-shot EVP_Cipher() function. See OpenSSL security advisory.

This is not a general TLS decryption bypass and not a statement that every application linked to an affected OpenSSL build accepts forged data. A useful exposure decision requires four facts: the application calls EVP_Cipher(); the operation is decryption; the selected AEAD cipher is ChaCha20-Poly1305 or AES-OCB; and an empty ciphertext is a valid or attacker-reachable input.

Why empty ciphertext is not the same as no message

Authenticated encryption with associated data protects both confidentiality and integrity. Some protocols legitimately authenticate a message that has associated data but no encrypted payload. The authentication tag still matters: it proves that the key holder produced the complete message context.

The affected EVP_Cipher() paths skipped tag verification for an empty ciphertext in the named ciphers. A caller could interpret a successful return as proof that the tag was valid even though OpenSSL had not performed that check. If the application treats an empty authenticated record as an authorization, state-change, replay-control, or protocol message, accepting a forged record may have application-level consequences.

Affected and fixed OpenSSL branches

Version reference: OpenSSL security advisory.

Distribution packages may backport the correction while retaining an older upstream base number. Use the operating-system or appliance vendor advisory for packaged OpenSSL. For statically linked or vendored applications, record the exact source revision or library embedded in the deliverable. See OpenSSL security advisory.

FIPS boundary

The OpenSSL advisory states that the FIPS modules for 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected because the affected algorithms are not FIPS approved and are not implemented in those modules. That does not prove an entire application is unaffected merely because it uses FIPS mode elsewhere. Confirm that the vulnerable operation is actually constrained to the validated module and that the application cannot select a non-FIPS provider for the named algorithms. See OpenSSL security advisory.

Determine API reachability

Search the source, wrappers, bindings, cryptographic abstraction layer, and third-party components. A direct call is easiest to find, but generated bindings and internal wrappers can hide the function name from application code.

rg -n 'EVP_Cipher\s*\(' src include vendor
rg -n 'EVP_chacha20_poly1305|EVP_aes_.*_ocb' src include vendor
rg -n 'OSSL_PROVIDER|FIPS|provider=' src config

For each match, determine whether the call performs decryption, how the cipher is selected, whether zero-length ciphertext is accepted, how the tag is supplied, and what the caller does with the return value. Do not mark an application exposed because it calls EVP_Cipher() only for an unrelated stream cipher or encryption path.

Explore Penligent for authorized security testing and evidence review.

Exposure decision table

Version reference: OpenSSL security advisory.

Safe regression testing

Build an application-level test around the real wrapper rather than reproducing a generic forgery. Use test-only keys and fixtures and include:

• a valid non-empty ciphertext and valid tag;
• a valid empty ciphertext and valid tag if the protocol permits it;
• an empty ciphertext with a deliberately corrupted tag, which must fail;
• a non-empty ciphertext with a corrupted tag, which must fail;
• the application’s expected error propagation and state behavior.

The critical assertion is not only the OpenSSL return code. Confirm that the application does not continue processing, change state, authorize a request, or emit a success result after an authentication failure. Keep the test in the normal suite so future wrapper changes do not reintroduce an equivalent assumption.

Patch and runtime verification

1. Record the build-time and runtime OpenSSL provider and version.
2. Update to the vendor-fixed release or distribution backport.
3. Rebuild statically linked applications and replace containers or appliances as required.
4. Restart long-running processes so they load the corrected library.
5. Run the valid and corrupted-tag regression matrix.
6. Retain the artifact digest, library mapping, test result, and change record.

openssl version reports the command-line installation, which may differ from a library embedded in an application or container. Use runtime linkage, application build information, SBOM, and supplier evidence to connect the observed service to the correction.

Mitigation before updating

If immediate deployment is impossible, reject empty-ciphertext records before the affected call, disable the affected algorithm where protocol compatibility permits, or route the operation through a reviewed API that verifies the tag correctly. These are application-specific controls and require regression testing. Avoid introducing a silent compatibility fallback that accepts a message through a weaker path.

निष्कर्ष

CVE-2026-75803 is narrow enough that dependency presence alone produces poor risk decisions, but cryptographic integrity failures deserve precise treatment. Identify the actual API and input path, install the corrected OpenSSL build, confirm which library or provider the application loads, and keep a corrupted-tag test at the application boundary. That evidence establishes remediation without exaggerating the issue into a universal TLS vulnerability.