Google Cloud Flags Critical PHP Vulnerability Affecting Cloud Run and App Engine

What Happened

Google Cloud published a security bulletin for a critical PHP vulnerability that affects all PHP versions between 5.4 and 8.5. Google Cloud itself is not vulnerable, but customers running PHP on Google Cloud may be. The bulletin, GCP-2026-070, covers two remote code execution vulnerabilities in the open-source PHP language.

Google Cloud says customers should take immediate action to protect their workloads by redeploying workloads with updated dependencies. In an update on 2026-10-28, Google Cloud said that for Cloud Run, Cloud Run functions, and Google App Engine Standard, all supported versions of PHP 8.2 and later are patched. Some workloads on those services may be automatically patched and updated to the latest PHP if automatic updates are enabled.

Timeline

• 2026-10-21Google Cloud publishes GCP-2026-070, covering two critical remote code execution vulnerabilities in PHP.
• 2026-10-24Google Cloud publishes GCP-2026-072 for Apigee, stating the impact is limited to Drupal-based Apigee developer portals.
• 2026-10-28Google Cloud updates GCP-2026-070, noting that Cloud Run, Cloud Run functions, and Google App Engine Standard have all supported PHP 8.2 and later patched.

Who Is Affected

The affected language versions are all PHP versions between 5.4 and 8.5. That means any workload running PHP on Google Cloud is in scope, including Cloud Run, Cloud Run functions, and Google App Engine Standard. If you are an MSP and you manage PHP applications for clients on those services, this bulletin applies to you.

Google Cloud also published a separate bulletin, GCP-2026-072, for Apigee. The impact there is limited to Drupal-based Apigee developer portals, which customers deploy and operate. Other Apigee products don't use PHP and aren't affected.

About This PHP Vulnerability

PHP is a server-side scripting language used across a large share of web applications. When a flaw in PHP core allows an unauthenticated attacker to run code remotely, the risk is not limited to one function or one endpoint. In general, remote code execution in a core language should be treated as urgent, because the attacker gets the same privileges as the application.

The fix is at the language level, so the response is to update the PHP version and redeploy the workload. As a standing practice, rebuilding from updated dependencies is safer than trying to patch a running container or instance, because it ensures the fix is baked into the image and there are no stale artifacts left behind.

Technical Details

The two CVEs are CVE-2026-109618 and CVE-2026-109619, also called PHP2Shell. They are vulnerabilities in PHP core. An unauthenticated attacker can execute code remotely on a server running a vulnerable PHP version. All PHP versions between 5.4 and 8.5 are affected. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. No fixed release exists for PHP 8.1 or earlier.

What to Do This Week

Work through this list in order. The goal is to know which of your workloads are exposed, get them onto a fixed PHP version, and confirm the redeploy actually happened.

1. Inventory every PHP workload you run on Google Cloud, including Cloud Run services, Cloud Run functions, App Engine Standard apps, and custom PHP containers.
2. Redeploy workloads with updated dependencies, as Google Cloud advises. Rebuild containers and functions with a fixed PHP version.
3. For Cloud Run, Cloud Run functions, and Google App Engine Standard, check whether automatic updates are enabled. Google Cloud says some workloads may be automatically patched and updated to the latest PHP when automatic updates are on.
4. Use Artifact Analysis if you have it. Google Cloud says customers using Artifact Analysis receive notifications of these vulnerabilities on both new and existing artifacts.
5. If you manage Drupal-based Apigee developer portals, follow the Apigee security bulletin for instructions and more details.
6. For any workload stuck on PHP 8.1 or earlier, plan an upgrade to a fixed version, since no patched release exists for those versions.

How to Handle the Response

Treat this like a change window. Pick a time when the redeploy will cause the least disruption, tell the client what is happening, and do the work. For each workload, record the previous PHP version, the fixed version, and the date it was redeployed. That gives you a clean record if a client asks later.

After the redeploy, verify the new version is actually serving traffic. A container image can be rebuilt and pushed, but the running service only changes after you redeploy it. In general, it is worth checking the running version rather than assuming the image update is enough.

Use the same routine for your own systems. If you run any PHP on Google Cloud internally, those workloads count too. The clients are not the only ones exposed.

What to Tell Clients

Google Cloud has published a critical vulnerability in PHP. It affects all PHP versions from 5.4 through 8.5, and it can let an unauthenticated attacker run code on a server. We are checking every PHP workload we manage on Google Cloud.

If your application runs on Cloud Run, Cloud Run functions, or App Engine Standard, the fix is to redeploy with an updated PHP version. Some of those services can apply the update automatically. We will confirm which of your workloads were updated and which need a manual redeploy.

If you run a Drupal-based Apigee developer portal, we will follow Google Cloud's Apigee security bulletin. No action is needed for other Apigee products.

Frequently Asked Questions

Sources

• GCP-2026-070 (Google Cloud Security Corrected)
• GCP-2026-072 (Google Cloud Security Corrected)