OpenSSL: CMP servers cache rejected extraCerts forever, letting a client drive the process to OOM

CVE-2026-63074Kernel, userspace & hypervisorcurated

Impact

A server that reuses one OSSL_CMP_CTX for the lifetime of the process never expunges the extraCerts attached to incoming CMP messages, including messages it rejects. A malicious client can repeat requests carrying unique extra certificates and grow that untrusted-certificate stack without bound until the process hits OOM. The blast radius is narrow: this is the Certificate Management Protocol code path only, so ordinary TLS termination, libssl clients and FIPS module users are not affected - OpenSSL states explicitly that CMP lives outside the FIPS boundary. It matters where a fleet runs its own CMP-based certificate issuance service, since that service going OOM stops certificate enrollment and renewal for everything downstream.

Who can reach it

Anyone who can send CMP messages to the CMP server endpoint over the network. No authentication is needed - the messages are the ones the server rejects.

What to do

Update OpenSSL to a build containing the linked fix (rejected messages now drop the added extra certs) and restart every daemon linked against it; the record does not name fixed version numbers, so check your distribution's advisory for the exact release. If you do not operate a CMP server, no action is required. As an interim measure, do not reuse a single long-lived OSSL_CMP_CTX across requests, or disable extraCerts caching on the context.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-63074 https://github.com/openssl/openssl/commit/01e567978a55fba18142a230380c31296049fae7 https://github.com/openssl/openssl/commit/21a5d9658b0c66daace60e10ea18ff32a448de9f https://github.com/openssl/openssl/commit/74ae7f6df47a5767c1010b88c47507dfc5b32c46

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.