CVE-2026-35189: Excessive Memory Allocation in Relative CRLDP Processing
Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions.
Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations.
The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received.
FIPS impact: no The affected code is outside the FIPS module boundary.
Affected Software
Event History
Frequently Asked Questions
Which TLS deployments are exposed to this issue?
Clients that receive certificates from malicious peers are exposed. Servers are also exposed when they solicit and process client certificates during TLS handshakes.
What does an attacker need to exploit the issue?
The attacker needs to present a crafted certificate containing many nameRelativeToCRLIssuer CRL distribution points. The certificate can remain within the approximately 100 KiB peer-certificate size limit while causing several hundred MiB of resident-memory allocation.
How can the impact be amplified?
Multiple concurrent TLS connections presenting similarly crafted certificates can produce similarly large allocations. This can create enough memory pressure to crash an affected client or server.
Does this affect the OpenSSL FIPS module boundary?
No. The affected code is outside the FIPS module boundary.