CWE-1325 Base Incomplete

Improperly Controlled Sequential Memory Allocation

This vulnerability occurs when a system allocates memory separately for each item in a collection but fails to enforce a global limit on the total memory used by all items combined.

Definition

What is CWE-1325?

This vulnerability occurs when a system allocates memory separately for each item in a collection but fails to enforce a global limit on the total memory used by all items combined.
While a developer might cap the memory for a single allocation—like setting a maximum size for one array—an attacker can bypass this by forcing the system to create many such objects in sequence. Each individual allocation stays within its allowed limit, but the cumulative memory consumption across all objects can exhaust available resources, causing a system slowdown or crash. This is a common oversight in systems that handle dynamic collections, such as connection pools, session managers, or request queues. To prevent it, developers must implement a two-tier check: one for per-object allocation and another for the aggregate memory footprint of the entire collection, ensuring the system can't be tricked into a denial of service through repeated small allocations.
Real-world impact

Real-world CVEs caused by CWE-1325

  • 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.

How attackers exploit it

Step-by-step attacker path

  1. 1

    Identify a code path that handles untrusted input without validation.

  2. 2

    Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.

  3. 3

    Deliver the payload through a normal request and observe the application's reaction.

  4. 4

    Iterate until the response leaks data, executes attacker code, or escalates privileges.

Vulnerable code example

Vulnerable C

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 C 
```
// Gets the size from the number of objects in a database, which over time can conceivably get very large* 
   int end_limit = get_nmbr_obj_from_db();
   int i;
   int *base = NULL;
   int *p =base;
   for (i = 0; i < end_limit; i++)
   {
  
  ```
  	 *p = alloca(sizeof(int *)); 
```
// Allocate memory on the stack* 
  	 p = *p; 
  	 *// // Point to the next location to be saved* 
  	 }
Secure code example

Secure pseudo

Secure pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-1325

  • 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.
Detection signals

How to detect CWE-1325

SAST High

Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.

DAST Moderate

Run dynamic application security testing against the live endpoint.

Runtime Moderate

Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.

Code review Moderate

Code review: flag any new code that handles input from this surface without using the validated framework helpers.

Plexicus auto-fix

Plexicus auto-detects CWE-1325 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-1325?

This vulnerability occurs when a system allocates memory separately for each item in a collection but fails to enforce a global limit on the total memory used by all items combined.

How serious is CWE-1325?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-1325?

MITRE lists the following affected platforms: C, C++.

How can I 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. 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…

How does Plexicus detect and fix CWE-1325?

Plexicus's SAST engine matches the data-flow signature for CWE-1325 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-1325?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1325.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-1325

CWE-770 Parent

Allocation of Resources Without Limits or Throttling

This vulnerability occurs when a system allows users or processes to request resources without any built-in caps or rate limits. Think of…

CWE-774 Sibling

Allocation of File Descriptors or Handles Without Limits or Throttling

This vulnerability occurs when an application creates file descriptors or handles for a user or process without enforcing any limits on…

CWE-789 Sibling

Memory Allocation with Excessive Size Value

This vulnerability occurs when a program allocates memory based on a user-supplied or untrusted size value without proper validation. If…

CWE-476 Can precede

NULL Pointer Dereference

This vulnerability occurs when a program attempts to access or manipulate memory using a pointer that is set to NULL, causing a crash or…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.