$ guides / php-fpm / php-fpm-status-page-exposed ▌

Operations Guides

PHP-FPM status and ping page exposed: operational information disclosure

The PHP-FPM status page and ping endpoint are operational tools meant for monitoring and health checks from inside the network. When reachable from the public internet, they leak data that aids reconnaissance: pool names, process manager configuration, worker counts, PIDs, request durations, and in full mode the exact script paths and query strings of every active request. This is a binary condition. If the status page returns HTTP 200 from an external IP, it is exposed and needs immediate restriction.

The exposure is common because the fix is a configuration detail, not a code change. An operator enables pm.status_path during an incident, adds a web server location block to proxy the path to PHP-FPM, and forgets the access restriction. The page works from localhost during testing, so nothing looks wrong. The exposure persists until an external scan or a security audit catches it.

What this means

The status page (pm.status_path, typically /status or /fpm-status) and the ping endpoint (ping.path, typically /ping) expose different amounts of information.

The standard status page returns:

Pool name, process manager mode (static, dynamic, ondemand), start time
accepted conn: total connections since pool start
listen queue: current socket backlog depth
max listen queue: high water mark since start
listen queue len: configured backlog maximum
idle processes, active processes, total processes
max active processes: peak concurrency since start
max children reached: counter of capacity saturation events
slow requests: counter of requests that exceeded request_slowlog_timeout

The ping endpoint returns a fixed string (default: pong) with HTTP 200. It confirms the pool is alive and reveals that PHP-FPM is in use, but leaks no further operational detail.

The full status variant (?full) is the most sensitive. It adds per-worker detail for every process in the pool:

PID and state (Running, Idle, etc.)
request URI: the exact request path and query string being processed
script: the full filesystem path to the PHP file executing
request duration: elapsed time in microseconds (not milliseconds or seconds)
last request cpu: CPU percentage of the last completed request
last request memory: peak memory of the last completed request
user: the HTTP authentication user, if applicable

The status page also supports output format parameters: ?json, ?html, ?xml, and ?openmetrics (added in PHP 8.1). These change the output format but not the data exposed.

flowchart TD
    A["GET /fpm-status from external IP"] --> B{"nginx location priority"}
    B --> C["location = /fpm-status
exact match, restricted"]
    B --> D["broad PHP handler
no restriction"]
    C --> E["403 Forbidden"]
    D --> F["200 OK: status served"]
    F --> G["pool config, worker counts,
PIDs, script paths leaked"]

An attacker can use this to map application structure from script paths, identify slow endpoints and backend dependencies from request durations, time attacks during peak load windows (visible from worker counts), and harvest query parameters that may contain tokens or internal identifiers from request URIs.

Common causes

Cause	What it looks like	First thing to check
Missing access restriction on status location	Status returns 200 from any IP; no `allow`/`deny` in the location block	Web server config for access rules on the status path
Broad PHP handler catching the status path	No explicit location block for status; a catch-all or broad regex routes it to PHP-FPM	Whether `location /` or a broad regex passes unrecognized paths to FPM
Restrictive block overridden by higher-priority match	Status location has restrictions but a regex location matches first	nginx location matching priority: exact, then `^~`, then regex, then prefix
Leftover debugging configuration	Status page was enabled during an incident and never locked down	Git history or mtime of the web server config file
Reverse proxy passthrough	Load balancer or CDN forwards `/status` without filtering	Whether the upstream proxy strips or blocks internal paths

Quick checks

# Test status page from an external IP (not localhost)
curl -s -o /dev/null -w "%{http_code}\n" http://your-public-domain/fpm-status
# 200 = exposed. 403/401/404 = restricted or not found.

# Test the ping endpoint
curl -s -o /dev/null -w "%{http_code}\n" http://your-public-domain/ping

# Check full mode (most sensitive: script paths and query strings)
curl -s 'http://your-public-domain/fpm-status?full' | head -30

# Check JSON format
curl -s 'http://your-public-domain/fpm-status?json' | python3 -m json.tool | head -20

# Check what paths PHP-FPM has configured
grep -E "pm.status_path|ping.path|ping.response" /etc/php/*/fpm/pool.d/*.conf

# Check nginx config for status/ping location blocks and restrictions
nginx -T 2>/dev/null | grep -B2 -A10 "fpm-status\|/status\|/ping"

# Check Apache config
grep -rn "fpm-status\|/status\|/ping" /etc/apache2/ /etc/httpd/ 2>/dev/null

A 200 from localhost tells you nothing about exposure. Always test from outside the server. Use a separate machine, a cloud shell, or a mobile connection.

How to diagnose it

Confirm which paths are configured. Check the PHP-FPM pool config for pm.status_path and ping.path. The paths may differ from the defaults shown above.
Test from outside the network. A request from the server itself will always succeed because the web server and PHP-FPM are co-located. Use a genuinely external source.
Check how the web server handles these paths. Look for explicit location blocks that proxy to PHP-FPM. Verify whether each has access restrictions (allow/deny in nginx, Require ip in Apache).
If the status page is accessible, capture the ?full output to understand the scope of disclosure. This reveals exactly what an attacker can see: script paths, query strings, PIDs, per-worker durations.
Check whether the exposure has already been discovered. Search web server access logs for external requests to the status path.

# Look for external access to status/ping paths
grep -E "fpm-status|/status|/ping" /var/log/nginx/access.log \
  | grep -v "127.0.0.1\|::1\|10\.\|172\.\|192\.168\." | tail -20

If you find external requests with a 200 status code, assume the information has been collected. Rotate any secrets that appeared in query strings visible in the ?full output.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
External HTTP 200 on status path	Binary indicator of exposure	Any 200 from a non-internal IP
Status page request rate from external IPs	Indicates active reconnaissance or scraping	Sustained or repeated requests from unknown IPs
`request URI` fields in full status	Leaks query strings, parameters, internal paths	Any external access to `?full`
Script paths in full status	Reveals application directory structure and entry points	External access correlates with probing in access logs
Pool configuration fields	Reveals worker capacity for targeted load attacks	Any external access to the status page

Fixes

Restrict access in nginx

Add explicit allow/deny rules to the status and ping location blocks. Use exact match (location =) to give these blocks the highest priority in nginx’s location matching algorithm, preventing a broader PHP handler from intercepting the request first.

location = /fpm-status {
    allow 127.0.0.1;
    allow 10.0.0.0/8;
    deny all;

    fastcgi_pass unix:/run/php/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location = /ping {
    allow 127.0.0.1;
    deny all;

    fastcgi_pass unix:/run/php/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Adjust the socket path to match your pool’s listen directive. Validate before reloading:

nginx -t && nginx -s reload

Restrict access in Apache

<Location "/fpm-status">
    Require ip 127.0.0.1
    Require ip 10.0.0.0/8
</Location>

<Location "/ping">
    Require ip 127.0.0.1
</Location>

Use a separate status listener

PHP 8.0+ supports pm.status_listen, which binds the status endpoint to a separate socket. The main pool listener no longer serves status requests, so the web server does not need a location block for the status path at all. This removes the web server as an exposure vector.

; Pool config (e.g. /etc/php/8.3/fpm/pool.d/www.conf)
pm.status_path = /status
pm.status_listen = 127.0.0.1:9001

A monitoring tool connects directly to 127.0.0.1:9001. No external path exists.

Disable the endpoints entirely

If you do not use the status page for monitoring, remove both directives from the pool config:

; Comment out or remove
; pm.status_path = /status
; ping.path = /ping

Reload PHP-FPM (adjust the service name for your PHP version and distro):

systemctl reload php8.3-fpm

Verify the fix

After applying any restriction, test again from an external IP. The expected response is 403 (access denied), not 200.

# Must return 403, not 200
curl -s -o /dev/null -w "%{http_code}\n" http://your-public-domain/fpm-status
curl -s -o /dev/null -w "%{http_code}\n" 'http://your-public-domain/fpm-status?full'
curl -s -o /dev/null -w "%{http_code}\n" http://your-public-domain/ping

Confirm monitoring still works from localhost:

curl -s http://127.0.0.1/fpm-status | head -5

Prevention

Audit the web server config immediately after enabling status monitoring. The most common path to exposure is adding the location block for a monitoring tool and forgetting the allow/deny rules. Treat a status location block without access restrictions as incomplete.
Test from outside after every config change. A localhost test always passes. Add an external probe to the deployment checklist for any change touching PHP-FPM or web server configuration.
Use exact match locations in nginx. location = /fpm-status takes priority over regex locations like ~ \.php$. This prevents ordering issues where a broad PHP handler serves the status page without restrictions.
Prefer pm.status_listen on a separate socket. If your monitoring tool can connect to a custom address, this removes the web server from the exposure path entirely.
Include status paths in security scans. External scanners flag exposed PHP-FPM status pages as information disclosure. Add /fpm-status, /status, and /ping to your routine attack surface checks.
Alert on external access attempts after restriction. Even after locking down, monitor for 403 responses on status paths from external IPs. Repeated probing indicates targeted reconnaissance.
Review query string exposure in access logs. If ?full status was previously accessible, query strings captured by the status page may have contained tokens or session identifiers. Check whether rotation is needed.

How Netdata helps

Netdata’s PHP-FPM collector scrapes the status page at per-second cadence from the same host, so the operational data it surfaces (active workers, idle workers, listen queue depth, max children reached, slow requests) is available without ever exposing the status page publicly.

No public exposure needed for monitoring. Netdata connects via localhost or the Unix socket. The status page can remain restricted to internal IPs while Netdata collects every field.
Correlate web server access logs with status path requests. If the status page was previously exposed, the nginx and Apache collectors show whether external requests to the status path correlate with reconnaissance patterns in the access logs.
Alert on HTTP status code regressions. After restricting the status page, any 200 response from an external IP is a config regression. Netdata’s synthetic HTTP checks can probe the public-facing status URL and alert if it returns 200 instead of 403.
Per-pool visibility without the raw status dump. The ?full endpoint exposes sensitive per-worker data including script paths and query strings. Netdata surfaces the same operational signals (request duration distribution, per-worker memory, active/idle breakdown) through its own collection pipeline, without making the raw endpoint accessible.
Continuous configuration verification. Netdata can run a periodic external HTTP check against the status path and alert on exposure, catching misconfigurations introduced by deploys or config changes before an attacker finds them.