PHP Site AuditDeployment and operations
How do I patch PHP2Shell in a PHP container?
Update the PHP base image or package in the artifact that actually serves requests, rebuild it, deploy the new image, and verify that every running replica and worker uses the patched build. Editing a Dockerfile or moving a tag alone does not prove that production containers were replaced.
Identify the deployed artifact first
Map each public hostname and workload to its running container image, registry digest, PHP package and SAPI. A site may use separate images for web requests, queue workers, scheduled jobs and administrative tools. The image called php in a compose file may not be the image currently running if the service was not rebuilt or redeployed.
PHP's advisory applies to installations serving web requests and names PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed. Containerization does not change the need to patch the PHP runtime inside the image. Check the relevant runtime package and vendor release notes; do not assume the host operating system's package update changed an application image built from an older base layer.
Build and roll out with evidence
Update the image reference or package to a documented fixed vendor build, rebuild through the normal trusted pipeline, and retain the resulting image digest and build provenance. If a vendor backport keeps the version string, keep its advisory or package metadata with the build record. Promote the tested artifact rather than rebuilding a different image during production deployment.
Roll out all replicas and any PHP-FPM or application workers that keep processes alive. Depending on the orchestrator, an image tag can point to a new artifact while old containers continue running. Confirm the actual digest, process start time and runtime package in each serving replica. Include cron, queue and secondary regions in the inventory if they execute PHP code.
Check health and application behavior
After replacement, verify readiness and error rates, then exercise representative flows: anonymous page reads, login, file uploads if used, scheduled tasks, queues and payment or publishing workflows. Compare these checks with a known-good baseline and watch logs for startup failures, missing extensions or compatibility regressions. A passing health endpoint alone may not exercise the PHP worker or all traffic paths.
Keep the previous image available for rollback, but do not roll back to an unpatched runtime without a risk decision. If an incident is suspected, preserve relevant logs and evidence before rotating or recreating containers. The patch addresses the PHP flaw; it does not establish whether an earlier request was exploited or whether exposed credentials need rotation.
Common questions
Is rebuilding enough?
No. The new artifact must be deployed and old serving replicas and workers replaced.
Can a public version banner confirm all containers?
No. It only reflects a response path and may omit private workers or other replicas.
What evidence should I save?
The vendor advisory, build metadata or digest, deployment record, replica list and verification results.