A single line of PHP-FPM configuration decides how far an attacker travels after a remote code execution bug in your application. The pool’s user and group directives set the identity of every worker that runs your code. That identity is the blast radius of a successful exploit.

The detection commands below are read-only. The lockdown changes require a graceful reload (SIGUSR2 or systemctl reload php-fpm), which re-reads the pool configuration and cycles workers while in-flight requests finish. Plan each change as a deploy.

The master process runs as root by design. Workers must not. The three risks this guide targets: workers running as root, workers running as a shared user across multiple applications, and pools that look isolated but share enough state that one compromised app can read another.

What the blast radius actually is

PHP-FPM is a master-worker architecture. The master starts as root (typically via systemd), reads its configuration, and forks workers. Each pool’s user and group directives, set in the per-pool configuration file, decide the credentials workers drop to after fork.

A remote code execution in your PHP application runs as that worker user. What the worker can read, the attacker can read. What it can write, the attacker can write. What it can reach on localhost, the attacker can probe. The Unix user is the boundary; PHP-FPM enforces no finer-grained sandbox below it.

The two failure shapes to look for:

Workers running as root. PHP-FPM refuses to start a pool with user = root. The error is ERROR: [pool www] please specify user and group other than root. The -R (--allow-to-run-as-root) command-line flag bypasses this guard. It exists for containers and test harnesses and must never be used in production. If you find it in a systemd unit or container entrypoint, treat the host as effectively compromised the moment any PHP vulnerability fires.

Workers running as a shared user. Several applications or vhosts sharing one pool user (www-data, apache, or a generic php account) means any RCE in one app can read the others’ source, configuration files, session files, and locally cached secrets. PHP-FPM pools do not enforce filesystem isolation on their own. Adding a second pool under the same master does not help if both pools run as the same user.

flowchart TD
    master["PHP-FPM master
runs as root by design"]
    subgraph poolA["Pool A"]
        wa["workers run as user: appA"]
    end
    subgraph poolB["Pool B"]
        wb["workers run as user: appB"]
    end
    shared["Shared OPcache segment
one per master process"]
    master -- "forks, setuid per pool" --> poolA
    master -- "forks, setuid per pool" --> poolB
    poolA -- "shares bytecode" --> shared
    poolB -- "shares bytecode" --> shared
    poolA -. "filesystem boundary:
appA cannot read appB files" .-> poolB

Why separate pools are not a complete fix

Adding more pools under the same master does provide some isolation: each pool has its own workers, its own pm.max_children, its own socket, and (if you configure it) its own user. But pools under a single master share two surfaces you should not ignore.

The first is OPcache. The PHP documentation is explicit that pools are not a security mechanism: they do not provide full separation, and all pools under one master share a single OPcache instance. A worker in one pool can read cached bytecode from another pool’s PHP files. If those files were included with credentials inline, the cached bytecode and file paths are visible across pools.

The default OPcache directives make this worse. opcache.validate_permission and opcache.validate_root both default to 0. With both off, OPcache does not check whether the requesting worker’s user actually owns the file whose cached bytecode it is about to serve. The fix is to set both to 1. These directives were added in PHP 5.6.29, 7.0.14, and 7.1.0; any modern PHP has the knobs, you just have to enable them.

The second shared surface is the master process itself. The master communicates with workers over shared memory, and that channel has been a privilege escalation path before. CVE-2021-21703 was a local privilege escalation from an unprivileged worker to root via shared memory corruption with the master. It was patched in PHP 7.3.32, 7.4.25, and 8.0.12 and all later releases. On older PHP, even a non-root worker user can escalate to root. This is a second reason, independent of filesystem permissions, to keep PHP patched and to never run workers as root.

Detection and audit

All checks are read-only. Run them from the host that runs PHP-FPM.

# Show user and group of every FPM process, including the master
ps -C php-fpm -o pid,user,group,args

You should see one root process (the master) and every other line running as a non-root user. On Debian-family systems the process name may be version-suffixed (for example php-fpm7.4); use pgrep -af php-fpm if ps -C php-fpm returns nothing. If master and workers share the root user, the -R flag is in effect. If two different applications’ workers both run as www-data (or any shared account), you have a shared-user problem.

# List every pool configuration file with its user and group directives
grep -RHnE "^[[:space:]]*(user|group)[[:space:]]*=" \
  /etc/php/*/fpm/pool.d/ /etc/php-fpm.d/ 2>/dev/null

Adjust directories to your distribution. Debian and Ubuntu use /etc/php/<version>/fpm/pool.d/. RHEL-family uses /etc/php-fpm.d/. Each .conf file inside represents one pool.

# Confirm the -R flag is not being passed to the master
ps -o args= -p "$(pgrep -f 'php-fpm: master' | head -1)"
# Or read the systemd unit
systemctl cat php-fpm 2>/dev/null | grep -E "ExecStart="

If you see -R or --allow-to-run-as-root in either output, the pool’s user = directives are being overridden at the master level. Remove it.

# Find applications whose workers run as the same user
ps -C php-fpm -o user,args --no-headers | awk '{print $1}' | sort | uniq -c | sort -rn

A single user accounting for more than one pool is your shared-user exposure. Confirm by mapping pool names to applications; the args column shows php-fpm: pool <name>.

# Check whether OPcache enforces file ownership across pools
php -r 'echo "validate_permission: " . ini_get("opcache.validate_permission") . "\n";
        echo "validate_root: "      . ini_get("opcache.validate_root")      . "\n";'

An empty string or 0 for either directive means OPcache is not enforcing per-file ownership. php -r runs in CLI context, which may differ from the FPM SAPI. For the per-pool FPM value, inspect the pool config or call ini_get from a web-accessible script and remove it immediately after.

Lockdown checklist

Each item is a deploy. A graceful reload (systemctl reload php-fpm) applies pool configuration changes and cycles workers; in-flight requests complete on the old workers while new workers come up under the new config.

One pool per application or tenant. Separate pm.max_children, separate logging, and a clean place to pin a user identity. Mixing tenants in one pool means one tenant’s slow request can saturate another tenant’s workers, and one tenant’s compromise touches the other’s filesystem namespace.

A distinct, least-privilege Unix user per pool. This is the actual security boundary. Create a system user per site (useradd -r -s /usr/sbin/nologin sitename) and set user = sitename and group = sitename in that pool’s configuration. The user should own the application’s files and nothing else.

A unique listen socket per pool. Avoids the web server talking to the wrong pool and gives per-pool backpressure at the kernel level. Set listen = /run/php/sitename.sock (or a unique TCP port) per pool.

Correct socket ownership and permissions. The web server needs to connect, but no other user should. Use listen.owner = www-data, listen.group = www-data, and listen.mode = 0660 so only the web server can reach the socket.

OPcache cross-pool hardening. The per-pool Unix user is not enforced by OPcache unless you ask it to. Set opcache.validate_permission = 1 and opcache.validate_root = 1 in php.ini or per pool via php_admin_value[]. Both are no-ops on single-pool hosts and a strict improvement on multi-pool hosts.

Per-pool open_basedir. Defense in depth. open_basedir constrains which paths PHP can read at all, so even a same-user bug in one pool cannot trivially read another pool’s files. Set php_admin_value[open_basedir] = /var/www/sitename/:/tmp/sitename/ per pool.

Per-pool disable_functions. Shrink the post-exploit surface. At minimum disable exec, system, passthru, shell_exec, popen, proc_open, and pcntl_exec for applications that do not need them. Some frameworks (Composer, image processing) require a subset, so tune per application.

Patched PHP. CVE-2021-21703 turned the worker-to-master shared memory channel into a privilege escalation path. The fix is in PHP 7.3.32, 7.4.25, and 8.0.12 and all later releases. Any deployment older than those versions is exposed regardless of pool configuration.

Signals to monitor

SignalWhy it mattersWarning sign
Worker user from ps -C php-fpm -o user,group,argsConfirms runtime identity matches configurationAny worker running as root, or two applications sharing one user
-R / --allow-to-run-as-root on the master command lineIndicates the root-user guard is bypassedFlag present in systemctl cat php-fpm or ps -o args= output
Per-pool socket file ownership (ls -l /run/php/*.sock)Confirms only the web server can connectSocket world-readable or world-writable, or owned by the wrong pool’s user
OPcache validate_permission and validate_rootConfirms cross-pool reads are blocked by file ownershipEither directive at 0 on a multi-pool host
PHP version vs CVE-2021-21703 patch levelConfirms the worker-to-master escalation is closedPHP 7.3 below 7.3.32, 7.4 below 7.4.25, or 8.0 below 8.0.12
open_basedir and disable_functions per poolDefense in depth if the worker user is ever bypassedEmpty open_basedir on a multi-tenant host

How Netdata helps

  • The PHP-FPM collector exposes per-pool process counts, active and idle workers, and the listen queue depth. A sudden divergence between two pools that previously tracked each other is often the first sign of one tenant’s problem spilling into another.
  • Per-process CPU and memory views let you confirm the worker identities you expect (the user column from ps -C php-fpm) match the resource usage you are graphing. An unexpected root-owned process consuming CPU on an FPM host is a high-signal event.
  • Anomaly detection learns each pool’s normal worker count, accepted-connection rate, and request duration. A sustained spike in one pool’s worker count without a corresponding traffic increase is consistent with a slow-request cascade or an attacker probing internal endpoints from a compromised worker.
  • Correlating PHP-FPM signals with system-level signals (per-process file descriptors, outbound connection counts, syslog entries from su and sudo) puts the worker-user-to-host-privilege boundary in one view.
  • Collectors run per host at per-second resolution, the polling cadence you want for spotting a pivot between pools in real time rather than after the fact.