CVE-2026-34182

What it actually does

OpenSSL CMS AuthEnvelopedData processing insufficiently validates the content-encryption algorithm and AEAD authentication tag length. A crafted CMS message can cause OpenSSL to accept an unauthenticated cipher mode, such as AES-OFB, in a context that should require authenticated encryption, or to accept an extremely short AEAD tag. In vulnerable use cases, this can let an attacker bypass message integrity checks or use application success/failure behavior as a decryption oracle to gain key-equivalent capability for a captured content-encryption key associated with a recipient. The OpenSSL FIPS modules are reported as not affected.

Why it matters to the business

Systems that rely on OpenSSL CMS_decrypt() to protect encrypted CMS messages may accept tampered content as valid. This can undermine confidentiality and integrity of signed or encrypted workflows, including secure message handling, document exchange, certificate-based encryption, gateway processing, and automated ingestion pipelines. Although EPSS is currently low and no known exploited status is reported, the CVSS severity is critical because exploitation is network-reachable, requires no authentication or user interaction, and can compromise protected message contents or trust decisions.

How an attack unfolds

An attacker first obtains or intercepts a legitimate CMS AuthEnvelopedData message addressed to a victim recipient. The attacker preserves the recipientInfos structure so the victim still unwraps the legitimate content-encryption key with its private key. The attacker then modifies the inner algorithm identifier to specify an unsupported or inappropriate non-AEAD mode, such as AES-256-OFB, and supplies attacker-controlled IV and ciphertext values. Vulnerable OpenSSL processing initializes the requested cipher under the real content-encryption key and may return success without enforcing the expected authenticated-encryption validation. If the target application exposes a success/failure signal, the attacker can adaptively query it as an oracle to recover key-equivalent functionality for that content-encryption key. In a second attack pattern, the attacker keeps an AEAD cipher but reduces the authentication tag length to a very small value, potentially one byte, making brute-force integrity bypass practical for applications that trust CMS_decrypt() to reject modified content.

How to fix it

Upgrade OpenSSL to a version that includes the vendor fix for CVE-2026-34182 as soon as fixed packages are available from the operating system, appliance, container image, or application vendor. No exact fixed version was provided in the input, so track the official OpenSSL security advisory and downstream package advisories for the applicable release branch. Rebuild or restart applications that statically link OpenSSL or bundle their own OpenSSL libraries. As compensating controls, reject CMS AuthEnvelopedData that specifies non-AEAD content-encryption algorithms where authenticated encryption is required, enforce minimum AEAD authentication tag lengths consistent with the selected cipher, reject unexpected algorithm OIDs, and avoid exposing distinguishable decryption success/failure responses to untrusted callers. Where appropriate and validated, use an unaffected OpenSSL FIPS module configuration for CMS processing.

How to confirm the fix worked

Confirm the deployed OpenSSL runtime and any bundled OpenSSL copies are updated to a vendor-fixed build once available. Inventory both dynamically linked and statically linked applications, containers, language bindings, and appliances that process CMS, S/MIME, PKCS#7, or AuthEnvelopedData. Test that malformed AuthEnvelopedData using non-AEAD algorithms in an authenticated-encryption context is rejected. Test that AEAD tag lengths below approved minimums are rejected. Verify applications return generic errors for CMS decryption failures and do not expose timing, status-code, log, or workflow differences that can be used as an oracle. If using vendor packages, validate with package-manager metadata and runtime checks rather than only checking the system OpenSSL CLI version.

Typical attack path

1. Identify an application or service that accepts CMS AuthEnvelopedData and uses vulnerable OpenSSL CMS processing.
2. Capture, obtain, or reuse a valid AES-GCM AuthEnvelopedData message for the intended recipient.
3. Modify the CMS structure while leaving recipientInfos intact so the recipient can still unwrap the original content-encryption key.
4. Change the content-encryption algorithm identifier to a non-AEAD mode such as AES-256-OFB, or reduce the AEAD tag length to an unsafe value.
5. Submit the crafted CMS object to the target application or protocol endpoint.
6. Observe whether the application returns a decryption success/failure signal, processes the plaintext, or accepts modified content.
7. Use repeated oracle responses or brute-force tag attempts to bypass integrity validation or gain key-equivalent functionality for the selected message key.

How to detect it

Look for evidence of crafted CMS AuthEnvelopedData being submitted to applications that perform OpenSSL CMS decryption. Useful sources include application request logs, secure mail gateway logs, document ingestion logs, API gateway logs, reverse proxy logs, message queues, attachment archives, EDR file telemetry, and OpenSSL/application error logs. Focus on unusual CMS objects containing AuthEnvelopedData with non-AEAD algorithms such as AES-OFB, unexpected algorithm OIDs, very short GCM/CCM authentication tags, repeated CMS decryption failures, and repeated submissions of near-identical encrypted payloads from the same source. Because successful exploitation may return normal application success and OpenSSL may not log a distinctive error, retrospective detection often requires preserving submitted CMS payloads and parsing their ASN.1 structures. Where payloads are available, inspect for id-ct-authEnvelopedData combined with AES-OFB OIDs or AEAD parameter structures specifying an authentication tag length that is far shorter than policy allows. Also review whether any endpoint provided externally observable differences between CMS parsing, decryption failure, authentication failure, and successful processing, as that behavior can indicate oracle exploitability.

• 1.2.840.113549.1.9.16.1.23
• id-smime-ct-authEnvelopedData
• id-ct-authEnvelopedData
• AuthEnvelopedData
• 2.16.840.1.101.3.4.1.43
• id-aes256-OFB
• aes-256-ofb
• AES-256-OFB
• 2.16.840.1.101.3.4.1.3
• id-aes128-OFB
• aes-128-ofb
• AES-128-OFB
• 2.16.840.1.101.3.4.1.23
• id-aes192-OFB
• aes-192-ofb
• AES-192-OFB
• CMS_decrypt
• unsupported content encryption algorithm
• bad decrypt
• cipher operation failed

What your security team should do

• Prioritize internet-facing or partner-facing services that accept CMS, S/MIME, PKCS#7, encrypted documents, secure email, or certificate-encrypted payloads.
• Track OpenSSL and downstream OS/vendor advisories and apply the fixed package as soon as it is released for the affected branch.
• Search for bundled or statically linked OpenSSL in applications, containers, appliances, and third-party products; patching the OS package alone may not remediate all exposure.
• Add application-layer validation to reject AuthEnvelopedData using non-AEAD ciphers or unsafe AEAD tag lengths before calling CMS_decrypt().
• Normalize CMS decryption errors so untrusted callers cannot distinguish padding, tag, algorithm, parsing, or success states.
• Review message archives and ingestion logs for malformed AuthEnvelopedData using AES-OFB, other non-AEAD modes, or abnormally short GCM/CCM tags.
• Increase monitoring on systems that decrypt CMS content for repeated decryption failures or high-volume submissions from the same source, which may indicate oracle probing.
• If CMS decryption is not required, disable the feature or restrict it to trusted authenticated channels until patched.