OpenSSL: certificate with many relative-name CRL distribution points inflates heap on TLS handshake

UnscoredCVE-2026-35189Kernel, userspace & hypervisorcurated

Impact

A peer that presents a crafted certificate under the normal ~100 KiB chain size limit can make the receiving side allocate several hundred MiB of resident memory while caching X.509 extensions, and that memory is held for the life of the certificate object rather than freed immediately. A handful of concurrent connections is enough to push a process into OOM. On a GPU fleet this hits anything that terminates TLS or requests client certificates - API gateways, registries, control-plane and scheduler endpoints, monitoring collectors - and the mTLS-heavy internal paths are exactly the ones that ask for client certificates, so the DoS is reachable from a client, not only from a server. The fix defers CRL distribution point processing until a CRL check actually needs it.

Who can reach it

Any TLS peer that can complete enough of a handshake to send a certificate. No authentication needed: an unauthenticated client against a server that solicits client certificates, or a malicious server against an outbound client.

What to do

Update the OpenSSL packages on affected hosts and restart every service linked against the shared library (or rebuild anything statically linked). The published advisory and commits are the only fix information in this record; no fixed version numbers are stated here. Long-lived daemons keep the vulnerable code mapped until restarted, so plan a rolling restart of TLS-terminating services rather than relying on the package update alone.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-35189 https://openssl-library.org/news/secadv/20260929.txt https://github.com/openssl/openssl/commit/2b93c73b2c70ddc4c61c5e4bfaaa6bd71379eb84

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.