Updated 21 October 2026. Emergency patches are available.
CVE-2026-109618 and CVE-2026-109619 are PHP runtime vulnerabilities that can allow unauthenticated remote code execution. The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A vendor-confirmed backport is also a valid fix. Updating your application alone does not update its PHP runtime. PHP release guidance
Identify the runtime that serves real requests, update it, replace its old workers and check for compromise. PHP-FPM is affected too.
Identify where PHP is running
Inventory EC2 instances, Auto Scaling groups, ECS services and standalone tasks, EKS workloads and scheduled jobs. Record the runtime version, image or package source, deployment owner and internet exposure. A managed AWS control plane does not establish that PHP in your guest OS or application image is patched.
Patch EC2 and its replacement images
For EC2, AWS assigns guest operating system and application patching to the customer. Apply the appropriate operating-system procedure, verify each instance, and update the images or templates used to create replacements. Otherwise, scaling or recovery can reintroduce an old runtime. AWS Systems Manager Patch Manager can help coordinate supported fleets. EC2 security responsibilities, EC2 update management
For Ubuntu or Debian guests, use the linked Linux guide. For Amazon Linux or another RPM distribution, use that distribution's security advisory and package tooling to identify a fixed candidate; do not run apt commands copied from an Ubuntu guide. Inspect the actual web runtime as well as CLI PHP.
Back up configuration and data, drain one instance and patch it first. Validate configuration, restart the PHP-serving process and test the application before returning it to service. Repeat across the fleet. Build a corrected AMI, update the launch template version selected by the Auto Scaling group, and replace older instances through your normal controlled refresh process. Keep capacity and health-check requirements in place.
Build a corrected container image
Update the PHP base image or build inputs to a publisher-confirmed fixed release. Rebuild the application and its extensions, test it and push a new immutable image digest to your registry. Pulling a tag or restarting an old container does not by itself prove that PHP changed. Inspect the resulting runtime and record its digest.
If the image uses FrankenPHP, update or rebuild that binary or image with fixed embedded PHP. A package update on the EC2 host, EKS node or inside an unrelated system PHP installation will not patch the embedded runtime.
Deploy the image to ECS
Create a task-definition revision that references the corrected image digest and update each service to that revision using its configured deployment method. Preserve task roles, secrets, networking, logging and health checks. Monitor rollout events and application health; verify that all replacement tasks use the intended revision and digest. Fargate does not remove your responsibility for the PHP code inside the image.
Update standalone task launchers and scheduled tasks as well. Replacing service tasks does not change a separate scheduled task definition. A forced deployment with the same vulnerable image cannot fix PHP. ECS service update documentation
Deploy the image to EKS
Update the image reference in your Helm values, Kubernetes manifests or GitOps source, then roll out the changed workload through the established deployment process. Include Deployments, StatefulSets, Jobs and CronJob templates that contain PHP. Preserve probes, resource settings and disruption controls.
For an example Deployment named web in namespace production, these read-only checks show rollout progress and the image IDs on its app=web pods. Substitute your real names and labels:
kubectl -n production rollout status deployment/web
kubectl -n production get pods -l app=web -o wide
kubectl -n production get pods -l app=web \
-o jsonpath='{.items[*].status.containerStatuses[*].imageID}'Confirm every relevant container uses the fixed image. A rollout restart with unchanged old images is insufficient, and upgrading the EKS control plane or node AMI does not update application PHP. Check PHP through the application's protected runtime diagnostic after deployment.
Verify the running application
Record the installed package revision or image digest and the advisory that confirms it is fixed. Check the web runtime through an authenticated internal diagnostic or the hosting control panel; do not expose a public phpinfo page. The default command-line PHP may be different.
Confirm that old workers have stopped. Test login, sessions, uploads, important transactions and background jobs. Check error rates and service health. Update the images and deployment templates used for new instances so the next deployment cannot restore vulnerable PHP. Keep a tested recovery plan, but do not return a vulnerable runtime to public service as a rollback.
Check for compromise before closing the incident
Preserve access, error, application and security logs, then review activity from 20 October 2026 onward. Look for unexpected PHP files, new administrator accounts, changed scheduled tasks, unusual outbound connections and web workers launching shell commands. Correlate findings with deployments and legitimate administrative work.
For a Linux webroot, this is a starting point, not a malware scanner:
sudo find /var/www -type f -newermt "2026-10-20" -lsThe date is pinned to the leak date rather than a moving two-day window. Replace /var/www with the actual application paths and account for the server timezone. Attackers can alter timestamps, so a clean result does not prove the server is clean. Compare with trusted deployment artifacts and review logs as well.
If you find suspicious activity, isolate the affected workload, preserve evidence and involve your incident responder. Restore or rebuild from trusted material and rotate exposed secrets from a clean environment. Patching alone does not remove a backdoor.
Get your PHP update completed
Send this guide to the person responsible for your server and ask for confirmation of the fixed runtime, completed worker restart and compromise review. If you need help, contact your hosting provider or development team with the package version, hosting platform and affected sites so they can act quickly.
Related guides
- Main PHP2Shell security advisory
- How to fix PHP on Ubuntu and Debian
- How to fix PHP on AWS EC2 ECS and EKS
- How to fix PHP on DigitalOcean
- How to fix PHP on Laravel Forge
- How to fix PHP on WordPress and shared hosting
