Issue Summary: Cryptographic Message Services (CMS) processing fails to perform sufficient input validation on the cipher and tag length fields of AuthEnvelopedData containers, leading to various potential compromises. Impact Summary: Attackers making use of these vulnerabilities may achieve key-equivalent functionality for a given CMS recipient and/or bypass integrity validation for a given message. In one use case, an attacker may send a CMS message containing AuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSL erroneously allows this selection, and attempts to decrypt and validate the message. An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData addressed to the victim can re-emit it with the recipientInfos set left byte-for-byte intact, so the victim's private key still unwraps the genuine CEK (the content-encryption key), but with the inner OID rewritten to AES-256-OFB (Output Feedback Mode, an unauthenticated keystream mode) and with an attacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the real CEK, never consults the MAC field, and CMS_decrypt() returns success. If the application under attack responds to the attacker with any indicator showing success or failure of the decryption effort, it is possible for the attacker to use this as an oracle to obtain key equivalent functionality for the CEK used for the chosen recipient of the message. In another use case, an attacker can reduce the tag length of the chosen AEAD cipher for a given AuthEnvelopedData container to be a single byte long, allowing an attacker to brute force CMS decryption, producing an integrity bypass for applications that trust CMS_decrypt() to reject modified content. The FIPS modules are not affected by this issue.
In the first scenario, an attacker intercepts a valid AES-GCM AuthEnvelopedData message and replays it, substituting the internal encryption OID identifier with AES-256-OFB (stream mode without authentication) while preserving the original recipientInfos. The victim correctly unwraps the CEK (Content Encryption Key) with their private key, initializes AES-256-OFB with the attacker-chosen IV and ciphertext, skips MAC verification, and CMS_decrypt() returns success. If the victim's application discloses the decryption operation result, the attacker can repeat this process multiple times, using responses as an oracle to obtain functionality equivalent to the CEK. In the second scenario, the attacker shortens the AEAD tag length to one byte, enabling brute-force MAC verification and effectively bypassing content integrity checks.
An attacker can obtain functionality equivalent to the Content Encryption Key (CEK) for a chosen recipient of a CMS message and bypass integrity verification, resulting in high violation of confidentiality and integrity of protected data. FIPS modules are not vulnerable to this issue.
Apply patches available from the vendor according to references — fixes have been published in the OpenSSL repository (commits: 03c1f4d, 439ed7d, 7947e6a, 9fd97f8, d2ca86b). Update OpenSSL to a version containing the mentioned fixes and verify that applications using CMS_decrypt() have additional validation on the application side.
OpenSSL in versions processing CMS AuthEnvelopedData (specific versions indicated in vendor references); FIPS modules are not vulnerable.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NOpenSSL
APPOpenssl4.0.03.0.0 – 3.0.21 (excl.)3.4.0 – 3.4.6 (excl.)3.5.0 – 3.5.7 (excl.)3.6.0 – 3.6.3 (excl.)
Related vulnerabilities
OpenSSL: heap buffer overflow przy konwersji OCTET STRING na hex (32-bit)
OpenSSL 3.0.4 – RCE przez błąd implementacji RSA na procesorach AVX512IFMA
Buffer overflow w dekodowaniu SM2 w OpenSSL — przepełnienie bufora na stercie
openfortivpn: błędna walidacja certyfikatów TLS z nullowym bajtem w CN
OpenSSL 1.1.0a: use-after-free w obsłudze sesji TLS (RCE/DoS)