Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
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
-
JavaScript-based packet decoder uses concatenation of many small strings, causing out-of-memory (OOM) condition
-
Product allocates a new buffer on the stack for each file in a directory, allowing stack exhaustion
-
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
Identify a code path that handles untrusted input without validation.
- 2
Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.
- 3
Deliver the payload through a normal request and observe the application's reaction.
- 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.
```
// 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
// 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
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
CWE-1325
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-1325?
How serious is CWE-1325?
What languages or platforms are affected by CWE-1325?
How can I prevent CWE-1325?
How does Plexicus detect and fix CWE-1325?
Where can I learn more about CWE-1325?
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 to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.