What CVEs are caused by CWE-1325?

17 recorded CVEs are attributed to CWE-1325, including CVE-2024-27796, CVE-2024-27804, CVE-2026-34183.

What are the consequences of CWE-1325?

Exploiting CWE-1325 can lead to: DoS: Resource Consumption (Memory).

Is CWE-1325 actively exploited?

17 recorded CVEs are caused by CWE-1325; none are currently in CISA's KEV catalog of actively exploited flaws.

Base weakness

Incomplete

CWE-1325: Improperly Controlled Sequential Memory Allocation

Also known as: Stack Exhaustion

The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.

Last updated May 1, 2026

Recorded CVEs

With this primary weakness

KEVs

In the CISA KEV catalog

Not rated

Likelihood of exploit

Per MITRE

Base

Abstraction

MITRE classification

Overview

While the product might limit the amount of memory that is allocated in a single operation for a single object (such as a malloc of an array), if an attacker can cause multiple objects to be allocated in separate operations, then this might cause higher total memory consumption than the developer intended, leading to a denial of service.

Real-world CVEs

17 recorded CVEs are caused by CWE-1325 (Improperly Controlled Sequential Memory Allocation). The highest-severity and most recent are shown first. 8 new CWE-1325 CVEs have been recorded so far in 2026 (2 in 2025).

Showing 12 of 17 recorded CWE-1325 CVEs. Track new ones as they are published and get AI-written analysis and fixes.

Monitor CWE-1325 vulnerabilities

Common consequences

What can happen when CWE-1325 is exploited.

DoS: Resource Consumption (Memory)

Affects: Availability

Not controlling memory allocation can result in a request for too much system memory, possibly leading to a crash of the application due to out-of-memory conditions, or the consumption of a large amount of memory on the system.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Applies to

Languages

C++

How to prevent it

Practical mitigations for CWE-1325, grouped by where in the lifecycle they apply.

Implementation

Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Operation

Run the program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

This example contains a small allocation of stack memory. When the program was first constructed, the number of times this memory was allocated was probably inconsequential and presented no problem. Over time, as the number of objects in the database grow, the number of allocations will grow - eventually consuming the available stack, i.e. "stack exhaustion." An attacker who is able to add elements to the database could cause stack exhaustion more rapidly than assumed by the developer.

Vulnerable example

// Gets the size from the number of objects in a database, which over time can conceivably get very large

Since this uses alloca(), it allocates memory directly on the stack. If end_limit is large enough, then the stack can be entirely consumed.

Illustrative examples

Real CVEs that MITRE cites as examples of this weakness.

CVE-2020-36049 — JavaScript-based packet decoder uses concatenation of many small strings, causing out-of-memory (OOM) condition
CVE-2019-20176 — Product allocates a new buffer on the stack for each file in a directory, allowing stack exhaustion
CVE-2013-1591 — Chain: an integer overflow (CWE-190) in the image size calculation causes an infinite loop (CWE-835) which sequentially allocates buffers without limits (CWE-1325) until the stack is full.

Terminology & mappings

Alternate terms

Stack Exhaustion: When a weakness allocates excessive memory on the stack, it is often described as "stack exhaustion," which is a technical impact of the weakness. This technical impact is often encountered as a consequence of CWE-789 and/or CWE-1325.

Attack patterns

CAPEC attack patterns that exploit this weakness.

CAPEC-130: Excessive Allocation

Frequently asked questions

Common questions about CWE-1325.

What is CWE-1325?: The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.
What CVEs are caused by CWE-1325?: 17 recorded CVEs are attributed to CWE-1325, including CVE-2024-27796, CVE-2024-27804, CVE-2026-34183.
How do you prevent CWE-1325?: Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
What are the consequences of CWE-1325?: Exploiting CWE-1325 can lead to: DoS: Resource Consumption (Memory).
Is CWE-1325 actively exploited?: 17 recorded CVEs are caused by CWE-1325; none are currently in CISA's KEV catalog of actively exploited flaws.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Stay ahead of CWE-1325

Get alerted the moment a new CWE-1325 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.

Start free See pricing