PHP2Shell: what to patch this week

What happened

On 21 October 2026 the PHP team shipped emergency security updates for two flaws in the PHP core interpreter. Both are rated critical (CVSS v4.0 score 9.2) and can let an unauthenticated attacker run code on the server.

• CVE-2026-109618 is an out-of-memory handling flaw. It can leave request data partly initialised.
• CVE-2026-109619 is a stale state flaw. A later request on the same worker can use request state that was already freed.

Attackers did not wait. Amazon’s honeypots logged an exploit attempt on 17 October, four days before disclosure. Cloudflare reported attempts rising into the millions by 22 October. Some campaigns try to install a Mirai botnet variant.

Who is affected

Any PHP that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Google lists PHP 5.4 through 8.5.11 as affected. Google Cloud itself is not vulnerable, but the PHP workloads you run on it can be.

Branch	Fixed in
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and older	No fix. Upgrade to 8.2 or newer.

What to do this week

1. Find every PHP you run. Not only servers. Look at container images, base images, CI runners, WordPress and Drupal hosts and managed platforms.

# On a host
php -v

# Inside an image
docker run --rm your-image:tag php -v

# Kubernetes: which pods run a PHP image
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i php

2. Update and restart. Installing the new package is not enough. Restart PHP-FPM, Apache or FrankenPHP so the patched binary is actually loaded.

3. On Google Cloud, follow the service you use.

Service	What you need to do
App Engine standard	PHP 8.2+ runtimes are patched automatically. On PHP 8.1 or older, upgrade and redeploy.
App Engine flexible	Not patched automatically. Redeploy on a supported runtime.
Cloud Run and Cloud Run functions	Patched automatically only with automatic base image updates. Otherwise rebuild and redeploy.
GKE	Update the container image to a fixed PHP version and redeploy the pods.
VMs and self-built containers	Update PHP, then restart the web process.

4. If you cannot patch today, reduce the risk first. These settings come from PHP’s advisory and Google’s guidance. They do not replace the patch.

session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 4M
max_input_vars = 250
max_file_uploads = 10
expose_php = Off
display_errors = Off

At the edge, block multipart/form-data on routes that never take uploads, limit request body size and turn on the Cloud Armor File Upload and RFI managed rules in enforce mode. In Cloud Armor, also add a body size limit so large payloads are not left uninspected.

5. Contain and watch. Run PHP workers as an unprivileged user with a read-only document root and memory limits set by cgroups. Block outbound internet access from PHP servers. Search your logs for unusual multipart POST requests since 17 October. If a host looks compromised, capture memory before you restart it.

A third, separate issue

On 23 October PHP published an advisory for CVE-2026-115560. The 21 October releases do not fix it. PHP considers it unlikely to matter, and no exploitation has been reported.

It only affects applications that set session.serialize_handler to php_binary or php_serialize, switch it to php with ini_set() before session_start(), and keep session upload progress enabled. PHP will fix it in a routine release. Setting session.upload_progress.enabled=0 covers it, so if you applied step 4 you are done.

How we can help

If you are not sure how many PHP versions you run, or where, that is the first thing to fix. We can inventory your PHP across AWS, Azure and Google Cloud, patch it and put the temporary controls in place. Book a call from the button below.