PHP2Shell on AWS, Google Cloud and Azure: Managed Runtimes vs Your Own VMs

As of 23 October 2026, AWS, Google Cloud and Microsoft Azure have each published PHP2Shell guidance, and none of them says its own infrastructure is the problem. AWS says "AWS services are not impacted by these issues." Google says "While Google Cloud itself is not vulnerable, users of this language running on Google Cloud may be vulnerable." The question for you is narrower: on the service you use, who installs the fixed PHP?

The short answer: managed PHP runtimes were patched by the cloud, but some only update when you redeploy or have automatic updates turned on. Virtual machines, containers you build and old end-of-life runtimes are yours to fix. PHP2Shell is two critical flaws in the PHP engine (CVE-2026-109618 and CVE-2026-109619), fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (backported builds for older branches are in our PHP2Shell fixed versions list). If you need the background first, read what PHP2Shell is.

The Rule: Who Runs the Server Patches PHP

Every cloud splits security work between itself and you. This split is called the shared responsibility model, and our guide to the shared responsibility model for websites explains it in plain terms. For PHP2Shell it comes down to one question: did you install PHP, or did the cloud?

AWS's own shared responsibility page says customers who deploy an EC2 instance "are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer." Microsoft's shared responsibility page says the same for infrastructure services: "You manage virtual machines, operating systems, and applications." For platform services such as App Service, "You deploy applications without managing VMs or operating systems."

So a managed runtime usually means the cloud updates PHP. A VM or a custom container means you do. Below is where each service falls.

AWS: Service by Service

AWS bulletin 2026-143-aws (last updated 22 October 2026) and the service documentation give this picture:

Elastic Beanstalk

If Managed Platform Updates are off, update the environment to platform 4.13.13 yourself. One detail matters. AWS's first 21 October platform release switched session upload progress off by default. The patched releases on 21 and 22 October "Restored the default values" (see the 22 October release notes). On 23 October, PHP advised setting session.upload_progress.enabled=0 until its next regular release because of a related issue, CVE-2026-115560. That means a patched Beanstalk environment is back to upload progress on. AWS documents adding a .ini file that sorts after aws.ini, such as zz-custom.ini, to change these settings. This is our reading of two dated pages; AWS has not published anything about CVE-2026-115560 that we found.

Lightsail

AWS's Lightsail PHP update guide covers the WordPress, WordPress Multisite, LAMP and Nginx blueprints. Its steps are an apt update and upgrade, a restart, then php -v:

sudo apt update
sudo apt upgrade
sudo systemctl restart apache2 (WordPress and LAMP)
sudo systemctl restart php8.2-fpm (Nginx; replace 8.2 with your version)

The AWS bulletin says "AWS cannot update running Lightsail instances in place" and suggests new instances from updated blueprints. Both can be true: AWS will not patch your instance for you, but you can patch it yourself.

Bitnami blueprints are different. AWS says they "include their own copy of PHP under /opt/bitnami/php. This copy is not updated by apt upgrade." Check it with /opt/bitnami/php/bin/php -v. AWS recommends moving to a Lightsail blueprint.

App Runner

App Runner lists no PHP2Shell fix, and its PHP 8.1 runtime is past end of support. Our reading: move the service to a container image with a fixed PHP, or to another AWS service. AWS steers new customers to Amazon ECS Express Mode.

Google Cloud: Service by Service

Google's bulletin GCP-2026-070 says "All PHP versions between 5.4 and 8.5" are affected. Its PHP2Shell blog post (updated 22 October) gives the split:

Google is blunt about old runtimes: "applications on PHP 5.5, PHP 7.2, PHP 7.3, PHP 7.4, or PHP 8.1 remain vulnerable and must be upgraded to PHP 8.2 or newer." It also says "Container images you build yourself are your responsibility."

Azure: Service by Service

The Azure App Service team's 21 October post covers the main PHP hosting service:

• App Service on Linux, built-in PHP: fixed images (8.2.35, 8.3.36, 8.4.27 and 8.5.12) rolled out to the Latest and Standard Platform Release Channels. Microsoft says to "Move away from the Extended channel," which "receives this fix last."
• EOL PHP on Linux: "End-of-life (EOL) PHP versions will not receive these security patches." Changing release channel "does not upgrade an EOL runtime to a supported version."
• App Service on Windows: the built-in PHP runtimes are end of life, and "No security patch for these runtimes is currently planned." The same applies on Azure Stack Hub.
• Custom containers or your own PHP: "App Service does not patch it."
• WordPress on App Service: patched, "except for apps still using the older Alpine-based images."
• Azure Virtual Machines: you manage the operating system and PHP.

To verify an App Service app, Microsoft says to open an SSH session at https://<appname>.scm.azurewebsites.net/webssh/host and run php --version.

Your Own VMs on Any Cloud

An EC2 instance, a Compute Engine VM and an Azure VM are ordinary Linux or Windows servers. The cloud does not touch PHP on them. Patch them as you would any server:

1. Install your distribution's fixed PHP packages. On Debian or Ubuntu that is sudo apt update then sudo apt upgrade. On RHEL-family systems it is sudo dnf update.
2. Restart every PHP process: PHP-FPM (for example sudo systemctl restart php8.3-fpm, replacing 8.3 with your version) or Apache if it runs mod_php. Our guide to restarting PHP workers covers each setup.
3. Verify. Distribution packages often backport the fix without changing the version number, so php -v alone can mislead. Our guide on how to check your PHP version shows the package changelog checks.

If your VM came from a marketplace image with its own bundled PHP (like Bitnami on Lightsail), the operating system update may not reach that copy. Check which PHP binary your web server actually runs. For a routine you can keep after this week, see our security patching best practices.

Containers: Rebuild, Don't Just Restart

If your app runs in a container on ECS, EKS, GKE, Cloud Run or Azure Container Apps, the PHP is inside the image. Microsoft puts it plainly: "Rebuild and redeploy container images that include their own PHP runtime, since updating the host does not update PHP inside an image." Google says the same for GKE and Cloud Run.

That means bumping your base image to a fixed tag, rebuilding, and redeploying every service and every environment, including staging. Our PHP2Shell guide for Docker covers base images and how to confirm what is inside.

Cloud WAFs Help, but They Are a Layer, Not a Fix

Each cloud also published firewall guidance. AWS WAF added PHP2Shell rules to its PHP managed rule group. Google Cloud Armor says customers with active managed rules are covered automatically. Azure Front Door's response-side rule is off by default. Every one of them still says to update PHP. AWS calls its WAF "a defense-in-depth control in this situation, not a replacement for the PHP upgrade." Our PHP2Shell WAF coverage guide compares them.

Conclusion

On AWS, Google Cloud and Azure, the cloud patched the PHP it manages. Where you chose the PHP, by running a VM, building a container or staying on an end-of-life runtime, it is still yours to fix. Go through every account and project, list each place PHP runs, and match it to the tables above. Then patch, restart, verify and keep upload progress off where you don't need it. If you want help working through a cloud estate, our emergency PHP patching team can take it on. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions