GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL: crafted CMS message causes an 8-byte out-of-bounds heap write during CMS_decrypt()

CVE-2026-63072Kernel, userspace & hypervisorcurated

Impact

An attacker who can hand a CMS message to anything that calls CMS_decrypt() gets a deterministic 8-byte zero write immediately past a heap allocation. The trigger is a single OID byte change on an otherwise valid message, selecting the padded AES key-wrap variant; no special build or configuration is needed and the unwrap key is derived from the recipient's own ECDH or ML-KEM operation, so the attacker needs no secret. OpenSSL assesses the consequence as heap corruption leading to process termination, not code execution. On a GPU fleet this matters wherever CMS decryption sits in a service path - artifact or model-bundle decryption, S/MIME-style enveloped payloads, PKI and secret-distribution tooling - because a crash there takes out a shared control-plane component rather than one tenant's pod.

Who can reach it

Anyone who can supply a CMS message to an application that decrypts it with CMS_decrypt(). No authentication and no knowledge of the wrapping key is required; reachability depends entirely on whether the service exposes a CMS decryption path.

What to do

Upgrade to the fixed OpenSSL release named in the 2026-08-25 OpenSSL advisory for your branch and restart every daemon linked against libcrypto - this is the expensive part, since it means bouncing API gateways, registries, schedulers and anything else holding an old libcrypto mapped. Distro package updates do not restart running processes for you; check with lsof/needrestart for services still on the old library. Statically linked binaries and vendored copies need a rebuild. The record does not name a fixed version for this specific CVE - take it from the advisory.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.