PHP2Shell fix guide for AWS

Separate the service from the runtime supplier

• EC2: inventory the AMI, distribution packages, third-party repositories and the service serving each virtual host.
• ECS and EKS: identify the PHP image digest in task definitions or workloads; update and replace all running replicas.
• Elastic Beanstalk: inspect the environment platform version and its release notes. Test a supported fixed platform in a separate environment before switching traffic.
• Custom Lambda runtimes or images: update the runtime or base image you supply and publish through the normal deployment path.
• A load balancer or CloudFront distribution does not update the origin PHP engine.

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.

Deploy without losing track of old instances

Use your existing image pipeline, launch template or workload deployment system. Test the updated runtime, create a new revision, and monitor health checks while replacing instances. Check autoscaling templates so future instances do not recreate the vulnerable build.

For EC2 package changes, follow the guide for that distribution rather than assuming an Ubuntu command applies to Amazon Linux. Review the vendor notice for the exact operating system release.

Evidence and incident scope

Retain deployment events, image identifiers and relevant CloudTrail, load balancer and application logs. Investigate unexpected role use or credential access when other evidence suggests compromise. Do not assume patching a web instance revokes credentials already exposed to an attacker.

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.