CVE-2024-2511
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2024-2511 is a medium-severity Improperly Controlled Sequential Memory Allocation (CWE-1325) vulnerability in Siemens (inferred from references). Its CVSS base score is 5.9 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked in the top 1% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-6 (Resource Availability) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2024-2511 is a memory-management flaw in OpenSSL that affects TLS servers supporting TLSv1.3 when the non-default SSL_OP_NO_TICKET option is enabled without early-data anti-replay protection. Under certain conditions the session cache enters an incorrect state and stops flushing, producing unbounded memory growth that eventually results in a denial of service. The issue does not affect TLS clients, the FIPS modules in OpenSSL 3.0–3.2, or OpenSSL 1.0.2.
A remote attacker who can reach an affected server can deliberately trigger the cache-growth condition, exhausting memory and causing the server process to become unresponsive. Exploitation requires a specific non-default configuration and carries high attack complexity, consistent with the CVSS 5.9 rating that emphasizes availability impact without confidentiality or integrity loss.
The official OpenSSL advisory and accompanying commits (7e4d731, b52867a, e9d7083, and the extended-release fix) describe the root cause and provide patches that restore proper session-cache flushing. Administrators are advised to apply the updates or revert to default ticket behavior if the non-default option is not required.
EPSS scores have remained low and essentially flat (current 0.0883, peak 0.0905), indicating no material increase in observed exploitation interest since disclosure.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-27460
Vulnerability Data
Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions Impact summary: An attacker may exploit certain server configurations to trigger unbounded memory growth that would lead to a Denial of Service This problem…
more
can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is being used (but not if early_data support is also configured and the default anti-replay protection is in use). In this case, under certain conditions, the session cache can get into an incorrect state and it will fail to flush properly as it fills. The session cache will continue to grow in an unbounded manner. A malicious client could deliberately create the scenario for this failure to force a Denial of Service. It may also happen by accident in normal operation. This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS clients. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.0.2 is also not affected by this issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V2.4.1V13.1.2V13.2.6
Mitigating Controls (NIST 800-53 r5) AI
SC-6 directly enforces resource quotas and priority allocations that stop unbounded sequential memory requests from exhausting the system.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require developers to enforce total memory limits during sequential allocations.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect unbounded allocation patterns, but removing the weakness does not fulfill testing obligations.
Secure development life cycle includes resource-management requirements that can prevent uncontrolled per-object allocations.
Secure architecture principles can mandate bounded resource usage, but eliminating this CWE does not address broader architectural controls.
Secure coding standards can require explicit limits on memory per object, yet fixing the weakness alone does not satisfy the full control.
Capacity management directly limits total memory consumption across objects, mitigating unbounded sequential allocations.