Insufficient Resource Pool

Incomplete Class
Structure: Simple
Description

This vulnerability occurs when a system's resource pool is too small to handle maximum usage. Attackers can exploit this by making a high volume of requests, consuming all available resources and blocking legitimate users.

Extended Description

At its core, this weakness creates a denial-of-service condition by exhausting a finite resource pool—like database connections, threads, or memory blocks. When an attacker floods the system with requests, the pool is quickly depleted, preventing normal users from accessing the service. This often manifests as connection timeouts, application crashes, or severe performance degradation during traffic spikes. To prevent this, developers must design resource pools that scale under peak load and implement safeguards like rate limiting, request throttling, and automatic resource recycling. Monitoring usage patterns and setting up alerts for abnormal consumption are also critical, as they allow teams to respond before a full outage occurs.

Common Consequences 1
Scope: AvailabilityIntegrityOther

Impact: DoS: Crash, Exit, or RestartOther

Floods often cause a crash or other problem besides denial of the resource itself; these are likely examples of *other* vulnerabilities, not an insufficient resource pool.

Potential Mitigations 5
Phase: Architecture and Design
Do not perform resource-intensive transactions for unauthenticated users and/or invalid requests.
Phase: Architecture and Design
Consider implementing a velocity check mechanism which would detect abusive behavior.
Phase: Operation
Consider load balancing as an option to handle heavy loads.
Phase: Implementation
Make sure that resource handles are properly closed when no longer needed.
Phase: Architecture and Design
Identify the system's resource intensive operations and consider protecting them from abuse (e.g. malicious automated script which runs the resources out).
Demonstrative Examples 1
In the following snippet from a Tomcat configuration file, a JDBC connection pool is defined with a maximum of 5 simultaneous connections (with a 60 second timeout). In this case, it may be trivial for an attacker to instigate a denial of service (DoS) by using up all of the available connections in the pool.

Code Example:

Bad
XML
xml
Observed Examples 3
CVE-1999-1363Large number of locks on file exhausts the pool and causes crash.
CVE-2001-1340Product supports only one connection and does not disconnect a user who does not provide credentials.
CVE-2002-0406Large number of connections without providing credentials allows connection exhaustion.
References 1
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
ID: REF-7
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Operation
Taxonomy Mapping
  • PLOVER
  • OWASP Top Ten 2004
  • The CERT Oracle Secure Coding Standard for Java (2011)