PHP2Shell fix guide for Docker

Inspect the actual deployed image

Record the image tag and immutable digest for web, worker and scheduler services. Confirm whether the image uses official upstream PHP or distribution packages, and use the corresponding patch evidence. A mutable tag alone is not durable evidence.

docker compose images
docker compose ps

Before you change the runtime

Record the current package revision, runtime handler, configuration and deployment topology. Confirm a current fix for both CVEs from the responsible vendor. Back up application data and configuration using a tested restore process. If an incident is suspected, preserve evidence before changing processes or files.

Test the intended PHP build with the application, extensions, scheduled jobs and database in staging. Plan a maintenance window or a rolling change with health checks. Keep a configuration and application rollback plan; do not restore a vulnerable runtime to public traffic without restricting exposure.

Image-based Compose deployment

The following example applies only to an existing Compose service named php whose image reference has already been changed to a verified fixed image. Review the service definition, volumes, network and health check first. Run this through your tested deployment process.

docker compose pull php
docker compose up -d --no-deps php
docker compose exec -T php php -v

Dockerfile builds and orchestrators

For a custom Dockerfile, update the PHP base image to a verified fixed digest and rebuild with the tested build pipeline. Rebuilding application layers while keeping a cached vulnerable base does not address the engine.

For Kubernetes or ECS, deploy a new image revision and monitor rollout and health checks. Check all replicas and completed replacements rather than inspecting only a local image. Preserve persistent data in the established storage and backup system.

Do not patch only inside a running container

An interactive package upgrade inside one container can disappear on redeployment and leave other replicas unchanged. Fix the build source and redeploy all roles. Roll back application code independently where possible; a known vulnerable image should not silently return to public service.

Verify the result and handle a delayed patch

Check the actual web-serving binary, package revision or image on every instance. Replace old workers and verify their startup times. Validate application health, uploads, sessions, queue workers and scheduled jobs. CLI output alone does not prove what serves HTTP requests.

If a fixed deployment fails compatibility checks, restrict access and escalate to your vendor or administrator. Temporary WAF or configuration changes may reduce specific attack paths but are not a complete substitute for patching. Investigate suspicious activity separately: a successful update cannot establish that the system was never compromised.