CVE-2026-63072: Heap Buffer Overflow in CMS Key Unwrapping
A flaw was found in OpenSSL. OpenSSL CMS decryption sizes the key-unwrap output buffer based on querying the unwrapped key size, but the AES-WRAP-PAD unwrap primitive can write and cleanse more bytes than that query reports, causing an 8-byte out-of-bounds heap write.
An attacker who supplies a crafted CMS message can trigger a deterministic 8-byte out-of-bounds heap write when the victim decrypts it with CMSdecrypt(), corrupting the heap and typically resulting in a Denial of Service.
The key-wrap OID is potentially attacker-controlled on the wire. CMS unwrapping allows both id-aesNNN-wrap-pad and id-aesNNN-wrap ciphers. An attacker can take a legitimate message and change a single OID byte to select the padded variant while leaving the message otherwise valid. Since the unwrap key is derived from the recipient's private operation (ECDH key agreement or ML-KEM decapsulation), the RFC 5649 integrity check cannot pass, and the decryption fails with integrity failure.
The write is a fixed-size (8-byte), fixed-value (zero) heap overflow immediately past the allocation, requires no special configuration, and is reachable from the public CMSdecrypt() function. The consequence is a heap corruption leading to a Denial of Service. The fix in the CMS code sizes the unwrap output buffer for the worst case so a failed unwrap cannot write past the allocation.
As the CMS code lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.
OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, and 1.1.1 are vulnerable to this issue. OpenSSL 1.0.2 is not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.2. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.4. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.8. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.7. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.22.
Premium support customers only: OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zi.
Other sources
Heap Buffer Overflow in CMS Key Unwrapping
— Microsoft
Issue summary: OpenSSL CMS decryption sizes the key-unwrap output buffer based on querying the unwrapped key size, but the AES-WRAP-PAD unwrap primitive can write and cleanse more bytes than that query reports, causing an 8-byte out-of-bounds heap write.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.3.7-6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 20240524git3e722403cd16-19 - Upgrade
Upgrade
debian/opensslto a version that resolves this vulnerability.Fixed in 3.0.22-1~deb12u2Fixed in 3.5.7-1~deb13u2Fixed in 3.5.7-1~deb13u3Fixed in 3.6.5-1 - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 1.1.1zi - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 3.0.22 - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 3.4.7 - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 3.5.8 - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 3.6.4 - Upgrade
Upgrade
OpenSSLto a version that resolves this vulnerability.Fixed in 4.0.2
Event History
Frequently Asked Questions
Is a non-default configuration required for exploitation?
No. The issue requires no special configuration and is reachable when a victim decrypts a crafted CMS message with CMS_decrypt().
What must an attacker provide to trigger the issue?
The attacker must supply a crafted CMS message for decryption. They can modify a legitimate message by changing a single key-wrap OID byte to select the AES-WRAP-PAD variant while leaving the rest of the message valid.
Does the CMS message decrypt successfully after the overwrite?
No. The unwrap operation ultimately fails its RFC 5649 integrity check because the unwrap key is derived from the recipient's private operation, such as ECDH key agreement or ML-KEM decapsulation. The out-of-bounds write occurs before the integrity failure is returned.
What is the expected impact of a successful trigger?
The write is a deterministic 8-byte, zero-value heap overflow immediately after the allocated buffer. It typically results in a denial of service through heap corruption.