CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How it's found
Uncontrolled Resource Consumption describes a general pattern rather than a single fixed bug. Testers use a mix of static analysis and manual code review to find where a target's code matches this pattern, then confirm exploitability by hand.
Vulnerable vs. safe
/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
body = &message[1][0];processMessageBody(body);return(SUCCESS);
printf("Unable to process message; invalid message length");return(FAIL);char *body;int length = getMessageLength(message[0]);if (length > 0) {}else {}int processMessage(char **message){}unsigned int length = getMessageLength(message[0]);if ((length > 0) && (length < MAX_LENGTH)) {...}Consequences
- DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other): If an attacker can trigger the allocation of the limited resources, but the number or size of the resources is not controlled, then the most common result is denial of service. This would prevent valid users from accessing the product, and it could potentially have an impact on the surrounding environment, i.e., the product may slow down, crash due to unhandled errors, or lock out legitimate users. For example, a memory exhaustion attack against an application could slow down the application as well as its host operating system.
- Bypass Protection Mechanism, Other: In some cases it may be possible to force the product to "fail open" in the event of resource exhaustion. The state of the product -- and possibly the security functionality - may then be compromised.
Mitigations
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
How TurboPentest tests for this (white-box)
This weakness (Uncontrolled Resource Consumption) is caught by white-box static analysis when you connect a GitHub repo: IntegSec's Opengrep SAST rule pack carries 1 rule for it, flagging the issue directly in your source code as part of the pentest.
Frequently asked questions
What is CWE-400?
The product does not properly control the allocation and maintenance of a limited resource.
How do you find Uncontrolled Resource Consumption?
Uncontrolled Resource Consumption describes a general pattern rather than a single fixed bug. Testers use a mix of static analysis and manual code review to find where a target's code matches this pattern, then confirm exploitability by hand.
What is the impact of CWE-400?
DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other): If an attacker can trigger the allocation of the limited resources, but the number or size of the resources is not controlled, then the most common result is denial of service. This would prevent valid users from accessing the product, and it could potentially have an impact on the surrounding environment, i.e., the product may slow down, crash due to unhandled errors, or lock out legitimate users. For example, a memory exhaustion attack against an application could slow down the application as well as its host operating system. Bypass Protection Mechanism, Other: In some cases it may be possible to force the product to "fail open" in the event of resource exhaustion. The state of the product -- and possibly the security functionality - may then be compromised.
Does TurboPentest test for Uncontrolled Resource Consumption?
This weakness (Uncontrolled Resource Consumption) is caught by white-box static analysis when you connect a GitHub repo: IntegSec's Opengrep SAST rule pack carries 1 rule for it, flagging the issue directly in your source code as part of the pentest.
Related CWEs
- Pillar weaknessCWE-664: Improper Control of a Resource Through its Lifetime
- Variant weaknessCWE-48: Path Equivalence: 'file name' (Internal Whitespace)
- Base weaknessCWE-170: Improper Null Termination
- Base weaknessCWE-369: Divide By Zero
- Variant weaknessCWE-382: J2EE Bad Practices: Use of System.exit()
- Variant weaknessCWE-401: Missing Release of Memory after Effective Lifetime
Written and reviewed by
Michel Chamberland - Founder & CEO, IntegSec
CISSP, OSCP, OSCE, CEH, GIAC, CCSK · 20+ years in offensive security
Michel has spent 20+ years on offensive security teams including IBM X-Force Red and Trustwave SpiderLabs, leading penetration tests, red team engagements, and breach response for Fortune 500 customers. He is the founder of IntegSec and the architect of TurboPentest.
Find these issues before an attacker does
TurboPentest runs an agentic AI pentest against your target and reports findings with proof, from $99 per target.
Start a pentest