This weakness occurs when an application fails to properly size, limit, or manage its resource pools—such as database connections, thread pools, or memory…
This weakness occurs when an application fails to properly size, limit, or manage its resource pools—such as database connections, thread pools, or memory buffers. When pools are too small, misconfigured, or lack proper cleanup, attackers can exhaust them with legitimate-looking requests, causing the application to become unresponsive or crash. Legitimate users are then denied service.
Applications typically maintain pools of expensive resources (database connections, worker threads, file handles) to avoid the overhead of creating and destroying them on every request. If the pool size is set too low relative to expected load, or if resources are not properly released after use (due to leaks, exceptions, or missing cleanup), the pool becomes exhausted. An attacker can trigger this by sending many concurrent requests, each holding a resource longer than necessary. Once the pool is empty, new requests queue indefinitely or fail immediately, and the application becomes unavailable.
The root cause is usually one of three patterns: a pool that is too small for the actual workload, resources that are not returned to the pool (leaks), or no timeout mechanism to reclaim stuck resources. Configuration mistakes—such as leaving default pool sizes in place for production—are common.
Service unavailability is the primary consequence. If a web application's database connection pool is exhausted, all database queries fail, rendering the site unusable. If thread pools are depleted, request handling stalls. In multi-tenant or shared-hosting environments, one misbehaving application can starve others. Recovery often requires manual intervention (restart, configuration change), and the outage may last minutes to hours depending on detection and response time.
import sqlite3
from threading import Thread
# Global pool with fixed, small size
connection_pool = [sqlite3.connect(':memory:') for _ in range(2)]
pool_index = 0
def get_connection():
global pool_index
# No waiting, no timeout — just grab the next one
conn = connection_pool[pool_index % len(connection_pool)]
pool_index += 1
return conn
def handle_request(user_id):
conn = get_connection()
# Long-running query; connection held for entire duration
result = conn.execute(
"SELECT * FROM users WHERE id = ?", (user_id,)
).fetchall()
# No explicit release; connection stays "in use"
return result
# Spawn many threads, each holding a connection
for i in range(10):
Thread(target=handle_request, args=(i,)).start()Why it's vulnerable:
The pool has only 2 connections but 10 threads are trying to use them concurrently. Connections are never explicitly returned, and there is no queue or timeout mechanism. Threads will block or fail, and the pool is quickly exhausted.
import sqlite3
from queue import Queue
from contextlib import contextmanager
class ConnectionPool:
def __init__(self, db_path, pool_size=5):
self.pool = Queue(maxsize=pool_size)
for _ in range(pool_size):
self.pool.put(sqlite3.connect(db_path))
@contextmanager
def get_connection(self, timeout=5):
conn = self.pool.get(timeout=timeout)
try:
yield conn
finally:
self.pool.put(conn)
pool = ConnectionPool(':memory:', pool_size=5)
def handle_request(user_id):
with pool.get_connection(timeout=5) as conn:
result = conn.execute(
"SELECT * FROM users WHERE id = ?", (user_id,)
).fetchall()
return result<?php
// Global array of connections, small fixed size
$connections = [];
for ($i = 0; $i < 2; $i++) {
$connections[] = new mysqli('localhost', 'user', 'pass', 'db');
}
$current_index = 0;
function get_connection() {
global $connections, $current_index;
// Round-robin, no queue, no timeout
$conn = $connections[$current_index % count($connections)];
$current_index++;
return $conn;
}
// Simulate many concurrent requests
for ($i = 0; $i < 10; $i++) {
$conn = get_connection();
// Long-running query; connection held indefinitely
$result = $conn->query("SELECT * FROM users WHERE id = $i");
// No explicit close or return to pool
}
?>Why it's vulnerable:
Only 2 connections are available but 10 requests are trying to use them. Connections are never closed or returned to the pool, and there is no mechanism to wait for availability or timeout. The pool is exhausted and subsequent requests fail.
<?php
class ConnectionPool {
private $connections = [];
private $available = [];
private $pool_size;
public function __construct($pool_size = 5) {
$this->pool_size = $pool_size;
for ($i = 0; $i < $pool_size; $i++) {
$conn = new mysqli('localhost', 'user', 'pass', 'db');
$this->connections[] = $conn;
$this->available[] = $conn;
}
}
public function get_connection($timeout = 5) {
$start = time();
while (empty($this->available)) {
if (time() - $start > $timeout) {
throw new Exception('Connection pool exhausted');
}
usleep(100000); // 100ms
}
return array_pop($this->available);
}
public function release_connection($conn) {
$this->available[] = $conn;
}
}
$pool = new ConnectionPool(5);
$conn = $pool->get_connection(5);
try {
$result = $conn->query("SELECT * FROM users WHERE id = 1");
} finally {
$pool->release_connection($conn);
}
?>with), try-finally blocks, or similar patterns to guarantee resources are returned to the pool, even if an exception occurs.
Watch for application slowdowns or timeouts that correlate with high traffic, especially if restarting the application temporarily fixes the issue. Check logs for "connection pool exhausted," "queue full," or "timeout waiting for resource" messages. Monitor database connection counts or thread counts over time; a steady climb without decline suggests resources are leaking and not being returned to the pool.
