PHP Site AuditOperations
PHP-FPM vs mod_php: what a runtime patch must reach
PHP can serve web requests through PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, LiteSpeed, and other setups. The October 2026 PHP advisory covers web-serving installations broadly and notes highest demonstrated risk for mod_php. Operators should identify the active SAPI and restart or roll out the processes that actually serve the domain.
Different request paths use different runtimes
PHP-FPM is a FastCGI process manager that runs PHP workers behind a web server. Apache can also embed PHP as mod_php; other configurations use CGI or different servers. A single machine may have several versions, pools, containers, or service units. This is why a host-level package update or CLI output does not automatically show what a public website is running.
The PHP project says its October 21 flaws affect installations serving web requests across several server models. The advisory describes mod_php as the highest-risk configuration in its demonstrated exploit, but that detail is not a reason to ignore a different SAPI.
Restart the right service
A package update must be followed by the provider's supported reload, restart, or container rollout so old workers stop serving requests. The exact command depends on the distribution, service manager, container orchestrator, and web server. PHP's FPM documentation describes process control, but operators should follow their platform's runbook rather than copy an unrelated host's command.
On a pool-based setup, record the pool and service that maps to the domain. On Kubernetes or another container platform, verify the running workload has the new image and old replicas have drained. Include background workers and scheduled jobs in the inventory if they execute the same runtime, although they are distinct from the internet-facing web path.
A deployment record should name the affected service and the action that activated the new package, such as a pool reload or application restart. Ask whether cron and queue processes use the same PHP installation; they can remain on a separate binary even after the public web pool changes.
Prove service health after rollout
Check deployment logs and service health, then make a normal request to the website and exercise a low-risk application path. Confirm the assigned package or image build through the platform's inventory. Keep this evidence in the change record. A response header is not a substitute for knowing which workers loaded the updated runtime.
Common questions
Does switching from mod_php to FPM remove the need to patch?
No. PHP includes both SAPIs in its update guidance; changing handlers is not a replacement for the fixed package.
Why does restarting matter?
Long-running workers may continue using loaded code until the platform activates the updated runtime; confirm the host's restart procedure.
What should be checked after a restart?
Confirm serving pools use the documented fixed package, then test representative requests, logs and background workers.