CME-917

Worker Process Recycling (MaxConnectionsPerChild / max_requests)

Harden Application High Confidence

Description

Configures application servers to periodically recycle worker processes after handling a fixed number of requests, bounding the cumulative impact of per-request memory leaks. When a worker reaches its request limit, it is gracefully terminated and replaced with a fresh process, releasing all leaked memory. Applicable to Apache HTTP Server (MaxConnectionsPerChild), PHP-FPM (pm.max_requests), Gunicorn (--max-requests with --max-requests-jitter for staggered recycling), Puma (worker_timeout), and Unicorn (after_fork with request counting). The recycling threshold should be set low enough to prevent OOM conditions but high enough to avoid excessive process churn — typical values range from 500 to 10000 requests per worker depending on application memory profile.

CVSS Vector Impacts

Metric	Transition	Rationale
Availability (A)	H → L	Per-request memory leaks are bounded by the worker lifecycle; each worker is recycled after a fixed number of requests, releasing accumulated leaked memory before it can cause resource exhaustion. The application experiences brief per-worker restart latency rather than system-wide memory starvation.

CWE Relationships

CWE-772 CWE-401

Verification

Check that application server worker recycling is configured with a finite request limit

$ grep -i MaxConnectionsPerChild /etc/httpd/conf/*.conf /etc/httpd/conf.d/*.conf 2>/dev/null
# Expected: A positive integer value (not 0, which means unlimited)

Platform: linux

$ grep pm.max_requests /etc/php-fpm.d/*.conf /etc/php/*/fpm/pool.d/*.conf 2>/dev/null
# Expected: A positive integer value (not 0)

Platform: linux

$ grep -E 'max.requests|max-requests' /etc/gunicorn/*.py /etc/gunicorn/*.conf 2>/dev/null
# Expected: A positive integer value

Platform: linux