Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 - Google Cloud

Security & Identity Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 October 22, 2026 Chris Betz CISO, Google Cloud Raluca Ada Popa Head of Gemini Security, Google DeepMind Try Gemini today The front door to AI in the workplace Try now Editor's note : This blog was updated on Oct. 21, 2026 at 3:30 p.m. PDT with additional guidance on Cloud Armor, and at 4:25 p.m. PDT with additional guidance on monitoring, patching, and remediation. PHP and Wiz Research disclosed today two critical vulnerabilities in the core PHP language runtime that can expose applications to unauthenticated remote code execution and memory disclosure. Wiz used a mix of models to identify and help remediate these vulnerabilities. Notably, Gemini 4 Argon made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch. While Google Cloud itself is not vulnerable, users of PHP running on Google Cloud may be vulnerable . At Google Cloud, we understand the severity of these vulnerabilities, and are sharing guidance to help our customers take immediate action to secure their applications. Vulnerability background PHP is a widely-used, server-side scripting language that powers many websites, content management systems, and web applications. On Oct. 21, 2026, CVE.org assigned the vulnerabilities as CVE-2026-109618 and CVE-2026-109619. The official Common Vulnerability Scoring System (CVSS) base severity score for each of the PHP flaws has been determined as Critical, a severity of 9.2. Generally, this ranking means that threat actors can crash and hijack the affected system, and can easily steal, alter, and wipe its data — although mitigating circumstances can make it harder to exploit the flaw. CVE-2026-109618 : Out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid. CVE-2026-109619 : Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. Vulnerable versions : All versions of PHP from 5.4 through 8.5.11 Patched in : PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Not patched : The PHP project is not releasing fixes for PHP 8.1 or earlier, which have reached end of life . Fix : CVE-2026-109618 ( GHSA-w8hw-w9fx-j79w ) and CVE-2026-109619 ( GHSA-6wmf-4rv5-p3rp ): Announcement : PHP has published a security advisory on these two vulnerabilities. Wiz Research has published a detailed description of the research and the coordinated disclosure process. Update PHP and redeploy your applications We urge all customers running PHP applications on Google Cloud to immediately update to PHP 8.2 or newer, and redeploy their services using a patched version. This applies specifically to applications deployed on: App Engine standard environment : Supported runtimes are patched automatically. If you are on PHP 8.1 or earlier, upgrade to PHP 8.2 or newer and redeploy. App Engine flexible environment : Redeploy your PHP runtimes using a supported runtime. If you are using a custom runtime, update your PHP dependencies to a patched version and redeploy your application. Cloud Run : If automatic base image updates are not enabled, or you deploy your own container image, rebuild with a patched version of PHP and redeploy. Google Kubernetes Engine (GKE) : Update your container images with a patched version of PHP and redeploy your pods. Google Cloud Marketplace : If you run a Marketplace solution that includes PHP, such as a content management system or LAMP stack, apply the update from the solution provider or update PHP directly. Automatic patches for serverless platforms Google Cloud is rolling out updated serverless base images for all supported PHP versions on App Engine Standard, App Engine Flexible, Cloud Run, Cloud Run function, and Cloud Functions for Firebase. What this means for you: App Engine standard environment (PHP 8.2 and newer): Applications are updated automatically. No action is required. App Engine flexible environment (all PHP versions): Applications are not updated automatically. Redeploy your application as soon as possible to PHP 8.2 and newer. Cloud Run functions (PHP 8.2 and newer): Functions with automatic base image updates enabled are updated automatically. Functions without automatic base image updates enabled must be redeployed. Cloud Run (PHP 8.2 and newer): Services with automatic base image updates enabled are updated automatically. Services built without automatic base image updates must be rebuilt and redeployed to pick up the patched runtime. Important considerations: Unsupported runtimes will not be patched . The upstream PHP project is not backporting these fixes to PHP 8.1 or earlier. 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. See the following runtime support schedules for serverless lifecycle dates: Google App Engine Standard Google App Engine Flexible Cloud Run Cloud Run functions Container images you build yourself are your responsibility . If you have deployed your own container image to Cloud Run or App Engine Flexible (such as with a custom runtime), rebuild it with a patched version of PHP and redeploy. Mitigating CVE-2026-109618 and CVE-2026-109619 with Cloud Armor Cloud Armor has issued recommended mitigations that use Cloud Armor managed rules . Customers with active managed rules do not need to take action; protection against these vulnerabilities is applied automatically. If you have not yet deployed Cloud Armor managed rules, doing so now can still help you mitigate these vulnerabilities. The Cloud Armor managed rules protections are available now through automatically-updated threat intelligence rulesets. These rules are intended to help protect your internet-facing PHP applications and services that use global or regional application load balancers. Follow these steps to deploy the rules immediately as a frontline defense-in-depth mitigation while your vulnerability management program updates and verifies all vulnerable PHP instances in your environment. 1. Deploying canary and stable managed rules (preview and enforce mode) for automatic updates: In order to protect your workloads from these CVEs, customers should minimally enable the File Upload and RFI categories . We recommend that you configure all ruleset categories in the canary version in preview mode, and ruleset categories in the stable version in enforced mode. 2. Mitigate risk on request bodies that exceed configured inspection limits: Create a rule in your security policies to help ensure that no uninspected or unnecessarily large content reaches your backends. This is particularly important for these CVEs, which may use large payloads to trigger out-of-memory conditions. Verifying WAF rule safety for your application and consuming telemetry Because PHP applications and content-management platforms (such as WordPress and Drupal) vary widely in how they structure query parameters, form submissions, and custom error handlers, we strongly recommend deploying the rules described above in preview mode first so you can test and monitor the expected impact without actively blocking traffic. Once you’ve verified that the new rule is behaving as expected for your application traffic, disable preview mode to allow Cloud Armor to actively enforce the deny(403) action. Cloud Armor per-request web application firewall (WAF) telemetry is emitted as part of the application load balancer logs in Cloud Logging. To inspect Cloud Armor's decision on every request load balancer request logging first needs to be enabled on a per-backend-service basis . Once enabled, all subsequent Cloud Armor enforcement and preview decisions can be queried in Cloud Logging by following these instructions . We recommend consulting our Cloud Armor best practices guide and accounting for service limitations (such as maximum inspected request body sizes, covered above) to minimize risk and optimize performance. Monitoring and auditing Google Cloud and Wiz are currently supporting customers with active monitoring, auditing, and runtime detection across its native security offerings. Customers can use: On-Demand Scanning AP I to manually scan images stored locally on your computer or remotely in Artifact Registry. Customers using Artifact Analysis will be notified of these vulnerabilities on both new and existing artifacts to identify at-risk workloads. Security Command Center to enable container threat detection for GKE and Cloud Run threat detection to monitor their workloads for intrusions. Google Security Operations now has 23 new curated detections added to the Mandiant Frontline Threats rule pack. We recommend verifying that this rule pack is enabled and reviewing your detections to assess any potential impact to your environment. Enterprise Plus customers can additionally use the Emerging Threat Center and search for “GLOBAL.26.015” for further details. Enterprise plus customers who have enabled the Threat Hunt Agent in Public Preview can also perform a hunt on GLOBAL.26.015 from the Emerging Threats Center. Wiz customers can refer to the Wiz Threat Intel Center advisory for PHP2Shell, which includes built-in coverage for agentless and runtime vulnerability detection, exploitation detection via Wiz Defend and Sensor, and automatic response policies, alongside remediation and threat hunting guidance. More information is available here on response steps with Wiz. Additionally, Mandiant Threat Defense is actively supporting customers by monitoring curated detections in Google Security Operations and hunting for evidence of intrusion activity related to this campaign. Patching and remediation The PHP security release has been published. You should update PHP across every server environment, container image, and deployment pipeline. In addition: As part of Wiz's zero-day response commitment, WizOS PHP images are available at zero billable units for all customers for the next 60 days. WizOS PHP base images, both standard Alpine-hardened and FIPS-compliant builds, are already patched against CVE-2026-109618 and CVE-2026-109619, built from source. Wiz customers can use the Green Agent to translate the PHP2Shell Threat Intel advisory into resource-tailored remediation guidance, including prescribing the correct PHP patch versions, identifying the right WAF mitigations, recommending opportunities to swap in for hardened WizOS PHP images, and suggesting enabling runtime blocking where there are gaps. We will continue to monitor the situation closely and provide further updates and guidance as necessary. For the most current information and detailed steps, please refer to the Google Cloud security bulletin . Posted in Security & Identity Related articles AI infrastructure Hardware-backed security at global scale: Confidential G4 with NVIDIA Blackwell is GA By Meghna Sreenivasan • 4-minute read Security & Identity Announcing Wiz Runtime Sensor add-on for GKE: Turnkey threat detection for Kubernetes By Daniel L’Hommedieu • 5-minute read Security & Identity Modernizing perimeter security: Scalable perimeters with VPC Service Controls By Pratik Bhangale • 5-minute read Security & Identity Cloud CISO Perspectives: New Gemini Notebook can help CISOs and policymakers prepare for PQC By Stephanie Kiel • 8-minute read