- The Mess: OpenSSL disclosed CVE-2026-63072 today, a heap buffer overflow in CMS key unwrapping that can trigger an 8-byte out-of-bounds heap write when a crafted message is decrypted. The bug affects multiple OpenSSL branches and was fixed in today’s security releases.
This one lives deep inside cryptographic plumbing.
That’s exactly where you don’t want sloppy memory handling.
The vulnerable code handles CMS decryption and AES-WRAP-PAD key unwrapping. OpenSSL calculates the required output buffer based on the reported unwrapped key size.
The problem?
The AES-WRAP-PAD primitive can write and cleanse more bytes than that calculation expects.
OpenSSL ends up writing eight bytes beyond the allocated heap buffer.
Eight bytes doesn’t sound impressive.
A memory corruption bug doesn’t care about marketing.
The attacker can craft a CMS message that causes the vulnerable code path to hit the out-of-bounds write when the victim processes it with CMS_decrypt().
There is an interesting twist.
The attacker can take a legitimate CMS message and modify the key-wrap algorithm identifier so that it selects the padded AES-WRAP variant.
The rest of the message can remain valid.
The victim then processes the modified message and eventually hits the heap overwrite.
The cryptographic integrity check itself is expected to fail.
The memory corruption happens anyway.
That’s the ugly bit.
- The Damage: The most likely impact is process crash and denial of service, but heap corruption from an out-of-bounds write can potentially have more serious consequences depending on the application, allocator and surrounding memory layout.
OpenSSL rates the vulnerability Moderate, which is important context.
This isn’t “Heartbleed 2.0”.
It isn’t a universal remote shell.
An attacker needs an application that actually processes the affected CMS content and reaches the vulnerable key-unwrapping path.
Still, OpenSSL is embedded everywhere.
Mail systems.
VPN infrastructure.
Enterprise applications.
PKI tooling.
TLS stacks.
Security products.
If one of those applications accepts attacker-controlled CMS messages, a memory-corruption bug inside OpenSSL becomes its problem too.
And because OpenSSL is a shared library, administrators can easily miss it.
The application might be fully patched.
The operating system might look fine.
But an old OpenSSL library underneath it can still be carrying the vulnerable code.
- The Fix: Update OpenSSL to a fixed release immediately: 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22 or 1.1.1zi, depending on the branch you use.
OpenSSL lists the affected ranges as:
- 4.0.0 → before 4.0.2
- 3.6.0 → before 3.6.4
- 3.5.0 → before 3.5.8
- 3.4.0 → before 3.4.7
- 3.0.0 → before 3.0.22
- 1.1.1 → before 1.1.1zi
Linux administrators should also remember the distro rule:
Don’t judge vulnerability purely by the OpenSSL version string.
Debian, Ubuntu, RHEL and other distributions frequently backport security fixes while retaining their own package versioning.
Check the distribution advisory.
Then restart applications using the affected library if required.
A patched library sitting on disk doesn’t necessarily mean a long-running process has stopped using the vulnerable code.
Bugstoday Opinion
This isn’t the loudest OpenSSL bug we’ve seen.
That’s precisely why it could be missed.
No dramatic authentication bypass.
No instant root.
Just an 8-byte heap overwrite hiding inside cryptographic message processing.
And OpenSSL is one of those pieces of software where “just a library” is a terrible description.
It’s underneath an enormous amount of infrastructure.
The interesting part is also the attack technique: take a legitimate CMS message, alter one algorithm identifier, and make the victim’s own crypto stack walk into a memory-corruption bug.
Clean.
Nasty.
Very Bugstoday.
Bugstoday verdict: patch OpenSSL today. An eight-byte overwrite doesn’t look scary until you remember that the eight bytes belong to someone else’s heap.
