PHP-FPM
The FastCGI process manager for PHP, used to manage PHP processes and support high-concurrency scenarios by separating PHP process management from the web server.
Timeline (last 90 days)
PHP-FPM's default pm.max_children is 150, and requests are assigned to idle workers by the kernel or the FPM scheduler, with the assignment strategy not guaranteeing that a request lands on a particular worker.
The actual exploitability of PHP RCE depends heavily on the runtime environment; disable_functions, open_basedir, SELinux/AppArmor, container isolation, and PHP-FPM permission configurations can all limit code execution to a limited scope.
Running PHP-FPM as a non-root user, restricting file access scope via open_basedir, and disabling unnecessary dangerous functions (such as eval and system) can shrink the blast radius after a successful exploitation.
If PHP-FPM's pool configuration item security.limit_extensions is set improperly, it may allow execution of non-PHP files, thereby worsening the impact of vulnerabilities.
PHP-FPM is a running mode that separates PHP process management from the web server and communicates via the FastCGI protocol, and it is widely used in high-concurrency scenarios.
If PHP-FPM's listening socket is misconfigured (for example, listening on 0.0.0.0 with no access control), attackers may communicate directly with FPM and bypass the web server's security rules.
In the PHP-FPM process pool model, each worker handles only one request at a time, and a pending downstream request monopolizes the worker; max_execution_time typically does not count time blocked on socket reads.
PHP-FPM handles FastCGI requests by maintaining a process pool and supports three process management modes: dynamic, static, and on-demand.
All Facts (8)
PHP-FPM's default pm.max_children is 150, and requests are assigned to idle workers by the kernel or the FPM scheduler, with the assignment strategy not guaranteeing that a request lands on a particular worker.
50%UnverifiedThe actual exploitability of PHP RCE depends heavily on the runtime environment; disable_functions, open_basedir, SELinux/AppArmor, container isolation, and PHP-FPM permission configurations can all limit code execution to a limited scope.
50%UnverifiedRunning PHP-FPM as a non-root user, restricting file access scope via open_basedir, and disabling unnecessary dangerous functions (such as eval and system) can shrink the blast radius after a successful exploitation.
50%UnverifiedIf PHP-FPM's pool configuration item security.limit_extensions is set improperly, it may allow execution of non-PHP files, thereby worsening the impact of vulnerabilities.
50%UnverifiedPHP-FPM is a running mode that separates PHP process management from the web server and communicates via the FastCGI protocol, and it is widely used in high-concurrency scenarios.
50%UnverifiedIf PHP-FPM's listening socket is misconfigured (for example, listening on 0.0.0.0 with no access control), attackers may communicate directly with FPM and bypass the web server's security rules.
50%UnverifiedIn the PHP-FPM process pool model, each worker handles only one request at a time, and a pending downstream request monopolizes the worker; max_execution_time typically does not count time blocked on socket reads.
50%UnverifiedPHP-FPM handles FastCGI requests by maintaining a process pool and supports three process management modes: dynamic, static, and on-demand.
50%