Cloud Security Wire
AWS Azure GCP RSS
AWSAzureGCPMulti-Cloud CVE Analysis critical

PHP2Shell (CVE-2026-109618, CVE-2026-109619): Finding and Patching Vulnerable PHP Workloads on AWS, Azure and Google Cloud

Two critical PHP runtime RCE flaws were reportedly probed four days before disclosure. Google Cloud says its platform is not vulnerable but your PHP workloads may be. Here is what is reported, plus CLI commands to find and redeploy affected workloads.

By Cloud Security Wire · ·
#PHP2Shell#CVE-2026-109618#CVE-2026-109619#PHP#remote code execution#Cloud Run#App Engine#patch management#zero-day exploitation
Critical Severity

This issue has been assessed as critical severity. Review affected configurations immediately.

What has been reported

Two remote code execution flaws in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell”, were disclosed on 21 October 2026. We opened two sources: Google Cloud’s security bulletin GCP-2026-070 and The Register’s report. We also tried The Hacker News coverage, which returned HTTP 403, so anything only attributed to it in search snippets is not used here.

From Google’s bulletin (published 2026-10-21):

  • Severity: Critical.
  • Affected: all PHP versions from 5.4 through 8.5.
  • Fixed: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • Google Cloud’s position: Google Cloud itself is not vulnerable, but PHP users on it may be. The bulletin names App Engine Standard, Cloud Run and Cloud Run functions with automatic updates enabled as environments that may be patched automatically. Everyone else is told to redeploy workloads with updated dependencies.
  • Tooling: Artifact Analysis customers get notifications about the vulnerabilities on new and existing artifacts.

We did not see a fixed release listed for PHP 8.1 or older in either page we opened. A search summary said they will not receive fixes; we could not confirm that on a page, so check php.net before assuming a patch exists for your branch.

From The Register:

  • Both CVEs carry a 9.2 rating; the article does not name the CVSS version or vector.
  • Amazon’s MadPot honeypot network reportedly saw an exploit attempt on 17 October, four days before patches shipped. Amazon said it is unclear how the actor obtained exploit information during the embargo.
  • On 21 October Amazon saw multiple proof-of-concept exploits, the earliest around 02:00 UTC, about 12 hours before patches. Attempts from different anonymised infrastructure suggested multiple attackers. Whether any would have succeeded against real systems is unclear.
  • Cloudflare’s Matthew Prince said it saw thousands of attempts in the 10 hours before disclosure, rising to millions afterwards, and that attackers adapted payloads to evade its WAF.
  • Hadrian reportedly said most attacks abuse PHP’s session upload-progress path and expects more exploit paths.
  • The PHP Foundation reportedly accused Chainguard of publishing patched builds before the agreed disclosure deadline. We have not seen Chainguard’s response.

Amazon advises investigating suspicious activity back to at least 17 October.

Why this matters for cloud teams

The bug is in the language runtime, not in one CMS or plugin. In our assessment, that makes the inventory problem the hard part: PHP hides in base images, App Service stacks, VM images and vendor appliances, and managed platforms only patch what they control. The pre-disclosure probing also means a patch applied on 22 October does not rule out earlier compromise.

Step 1: find PHP workloads

The commands below are our own suggestions and are untested against these CVEs; adapt them to your environment.

AWS (Inspector enhanced scanning must be enabled):

aws inspector2 list-findings \
  --filter-criteria '{"vulnerabilityId":[{"comparison":"EQUALS","value":"CVE-2026-109618"},{"comparison":"EQUALS","value":"CVE-2026-109619"}]}' \
  --query 'findings[].{res:resources[0].id,sev:severity,status:status}'

Inspector only reports once its vulnerability database includes the CVEs; we did not verify that it does. Also grep images and AMIs for php in package lists, and check Lambda functions using custom runtimes or layers that bundle PHP.

Azure App Service:

az webapp list --query "[].{n:name,rg:resourceGroup}" -o tsv | while read n rg; do
  echo "$n $(az webapp config show -n $n -g $rg --query linuxFxVersion -o tsv)"
done | grep -i php

Custom containers will not show here; scan the images in your registry instead.

Google Cloud:

gcloud run services list --format="table(metadata.name,metadata.namespace)"
gcloud artifacts docker images list LOCATION-docker.pkg.dev/PROJECT/REPO \
  --show-occurrences --occurrence-filter='kind="VULNERABILITY"'

Step 2: patch and redeploy

  1. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. For container images, rebuild with --pull --no-cache so the base layer is refreshed; a redeploy of an unchanged image fixes nothing.
  2. Redeploy on Cloud Run: gcloud run deploy SERVICE --image NEW_IMAGE --region REGION.
  3. If you are on an unsupported PHP branch, treat the workload as exposed: restrict it behind authentication or take it offline until you have a fixed runtime.
  4. A WAF rule is a stopgap only. Cloudflare itself said its protections do not replace patching, and it reported attackers adapting payloads.

Step 3: look back to 17 October

Hadrian’s reported path is PHP’s session upload-progress feature. In our assessment, requests carrying the PHP_SESSION_UPLOAD_PROGRESS field are worth hunting, but POST bodies are rarely logged, so you may need WAF or reverse-proxy logs. Check also for new PHP or web-root files, unexpected child processes of php-fpm or apache2, and outbound connections from web tier hosts. If you find evidence of execution, rotate any credentials reachable from that workload (instance roles, service account keys, environment secrets) and review CloudTrail, Azure Activity Log or Cloud Audit Logs for use of those identities.

Unverified

  • Fixed versions beyond the four listed, and the end-of-life statement for PHP 8.1 and older.
  • The CVSS vector behind the reported 9.2.
  • The MadPot timeline and Cloudflare figures are single-source (The Register).
  • No IOCs were published in the sources we opened, so none are given here.

Sources

← All Analysis Subscribe via RSS