Google Cloud PHP2Shell status: is it patched? How to check

Google's own bulletin GCP-2026-070 says Google Cloud's infrastructure is not vulnerable to PHP2Shell, and that PHP workloads you run on it may be. Its instruction is to redeploy with updated dependencies. As of 26 October 2026, whether your service is patched depends on the product. Check the deployed revision, image or runtime, then confirm it started after the fix.

This page covers Google Cloud as a place to run your own PHP. It is not a status for Google Workspace or Google's consumer products. For what the flaw is and who it affects in general, see our plain-language explainer on the bug.

Who owns the fix on Google Cloud?

You do, in most cases. Google's bulletin separates "Google Cloud infrastructure", which it says is not vulnerable, from "customers running PHP on Google Cloud", who may be. A service you deploy carries its own PHP, and the bulletin asks you to redeploy it.

This differs from a shared host such as the ones in our Cloudways page, where one company patches a fleet. On Google Cloud there is no single fleet to wait for. Each App Engine app, Cloud Run service, function, VM and cluster has its own state. The other big clouds split the job differently: see what Microsoft says about Azure App Service and what AWS says about patching Lightsail instances, or browse the other host status pages.

What did Google correct on 22 October?

Google withdrew a statement. The App Engine and Cloud Run release notes each carry a 21 October entry now marked incorrect, with a pointer to follow the 22 October entry. The withdrawn entry had said PHP workloads were automatically patched.

The 22 October entry reads: "All supported versions of PHP 8.2 and later are patched. Take immediate protective action by redeploying your resources with updated dependencies." You can read it in the App Engine PHP release notes, the Cloud Run release notes and the Cloud Run functions release notes.

If you read a summary written on 21 October that says Google patched everything automatically, it predates the correction. Our own research snapshot of 22 October carried that earlier version for App Engine, and this page replaces it.

Which Google Cloud product are you on?

Find your row. The wording comes from Google's pages, dated at our 26 October check.

How do I check App Engine?

On App Engine standard the runtime id in app.yaml (for example php83) names the branch. Google's runtime page says App Engine updates patch releases automatically but not the minor version. The GAE_RUNTIME variable returns the runtime you configured.

None of that shows the build. So the check is the deployment itself.

• Redeploy each PHP version of each service after 22 October 2026.
• Note the new version's creation time in the console.
• Route traffic to the new version and stop the old one.
• Keep the deployment time next to the 22 October note in your records.

For flexible, Google's PHP runtime page says the runtime is regularly updated to the latest release version, and that a custom runtime picks its own base image, including Docker's PHP images. A custom runtime is yours to rebuild. Our Docker image page covers that route, and the Fly.io rebuild steps show the same image-owns-the-PHP pattern on another platform.

How do I check Cloud Run?

Cloud Run has the most moving parts. Google's automatic base image updates page says Google applies patches to the operating system and runtime without a rebuild, and that no new revision is created when the base image changes. It covers only Google's buildpacks base images. The page does not list PHP among its examples, so confirm on the service itself whether PHP gets this treatment.

Two checks follow from that.

• Is the setting on? Source deployments enable it with the --automatic-updates flag alongside --base-image. A service that never had it will not change by itself.
• Which base image version applied? Google says to look at the run.googleapis.com/base_image_versions label in the Cloud Run service logs.

If the service is built from your own Dockerfile, none of this applies. Rebuild from a fixed PHP and deploy. Google's revision documentation gives the commands to see what is serving:

gcloud run revisions list --service SERVICE --region REGION
gcloud run revisions describe REVISION --region REGION --format yaml

Read the image reference and the creation time. A revision created before 22 October 2026 predates Google's corrected note.

What about VMs, GKE and everything else?

Google's bulletin does not mention them, so there is no Google statement to quote. The responsibility is the same as on any server you run. Update the PHP package from your distribution or image source, then restart PHP-FPM, Apache or LiteSpeed.

PHP's security notice tells owners who apply the interim settings to restart every worker, and lists the fixed releases. A running worker keeps the code it started with, so after updating, replace or restart them. On GKE that means new pods from a rebuilt image. On a VM it means a restart after the package change. Our PHP-FPM restart page shows how to prove it.

Backported builds keep older version numbers, so read the package changelog for both CVE ids rather than the version. GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp describe the two flaws.

Can Google tell me which of my images are at risk?

Partly. Google's overview says it scans operating system packages and PHP packages, and keeps scanning images pulled within the last 30 days.

Two limits matter here. Refreshing metadata can take up to 24 hours. And a scanner that reads package lists can miss a vendor backport, so a missing finding is not a confirmation. Treat it as a list of leads.

What to ask your own team, or Google support

If someone else deployed the service, send this. Keep the reply.

For [service name, project and region], which PHP build is serving requests now? Please give the image digest or deployed version, the date it was created, confirm it was built after 21 October 2026 with a PHP release or backport that names CVE-2026-109618 and CVE-2026-109619, and say whether automatic base image updates are on.

An agency checking client projects can reuse the same wording across accounts. The agency triage page covers consent and ordering.

Am I affected? A three-state self-test

Was anything exploited before the redeploy?

Attempts came first. AWS reported honeypot attempts from 17 October, four days before disclosure, and said it is unclear whether they would have worked on real systems (AWS, vendor-claimed). At our check on 24 October the CISA catalog did not list either CVE, and its newest entries were dated 23 October.

If your service was reachable and unpatched from 17 October, look for unexpected PHP files, new admin users, scheduled jobs you did not create and unfamiliar outbound connections. Patching removes the hole and leaves anything planted earlier. After a real finding, rotate the secrets the service could read.

PHP also published a follow-up on 23 October for a separate issue, CVE-2026-115560, with the setting session.upload_progress.enabled=0 as a mitigation and a full advisory promised in the next release. It is a different issue from the two PHP2Shell CVEs.

Where does the free scan fit?

The free scan reads the stack your site serves and matches each version to known vulnerabilities. One per domain, no card. It is a lookup: it can say a version is affected, not whether your setup is exposed.

On Google Cloud that matters, because a load balancer, Cloud Run URL or custom domain hides which product sits behind it. The scan can give you "detected" or "unknown". Only the revision, the image or the build log gives you "confirmed".