# PHP2Shell: what UK organisations should do about CVE-2026-109618 and CVE-2026-109619

URL: https://computecloud.co.uk/blog/php2shell-cve-2026-109618-109619/
Last updated: 2026-10-24
Published: 2026-10-21 by ComputeCloud Team

> Two critical PHP flaws allow unauthenticated remote code execution. Fixed versions, Windows Server and IIS, Azure App Service and WAF, and what to do today.

On 21 October 2026 the PHP project released emergency fixes for two critical vulnerabilities, nicknamed PHP2Shell, that can let an attacker run code on a web server without logging in. Updating PHP is the only complete fix. Here's what's affected, what to update to, and what it means if your PHP sites run on Windows Server, IIS or Azure.

## Key points

- **PHP2Shell is two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution.** The PHP project rates both CVSS v4.0 9.2.
- **Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35**, released on 21 October 2026. The PHP project says there are no complete mitigations.
- Every PHP installation that serves web requests is in scope, including **PHP-FPM, Apache mod_php and php-cgi**. That includes PHP on **IIS**, which runs through FastCGI and php-cgi.exe.
- **PHP 8.1 and older get no fix from the PHP project.** Upgrade to a supported branch, or get a backported fix from your Linux distribution or LTS vendor.
- In Azure, rebuild container images and patch VMs yourself. Azure WAF mitigations help in the meantime but **don't replace patching**.

## Key facts

- **Released:** 21 Oct 2026
- **Severity:** CVSS v4.0 9.2 (both)
- **Fixed in:** 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
- **No fix from PHP:** 8.1 and older

## What is PHP2Shell?

PHP2Shell is two vulnerabilities in the PHP runtime itself, not in any particular application. The [PHP project's advisory](https://www.php.net/archive/2026.php) describes them like this:

| CVE | PHP's name | What goes wrong |
|---|---|---|
| **CVE-2026-109618** | RCE via OOM corruption | Running out of memory can interrupt PHP while request data is only partly set up. Clean-up then treats that half-built data as valid. |
| **CVE-2026-109619** | RCE via stale global state | Some per-request state can survive after its memory has been freed, and a later request on the same worker can use it before it's reset. |

The PHP project rates both **CVSS v4.0 9.2**. Both can be triggered over the network, without credentials and without user interaction. It considers the risk highest for Apache with mod_php, where it has a demonstrated exploit that works **before any application code runs**. So a well-written application gives no protection.

Details leaked online on 20 October. The PHP project announced an emergency release the same day and published the fixes on 21 October.

## Which PHP versions are fixed?

| PHP branch | Fixed version | PHP project security support ends |
|---|---|---|
| 8.5 | **8.5.12** | 31 Dec 2029 |
| 8.4 | **8.4.27** | 31 Dec 2028 |
| 8.3 | **8.3.36** | 31 Dec 2027 |
| 8.2 | **8.2.35** | **31 Dec 2026** |
| 8.1 and older | No fix from the PHP project | Already ended |

Sources: [PHP advisory](https://www.php.net/archive/2026.php) and [supported versions](https://www.php.net/supported-versions.php), both checked 21 October 2026.

If you're on 8.2, patch now and plan the move to 8.3 or later. PHP 8.2 gets no more security fixes after 31 December 2026.

## Am I affected?

Almost certainly, if you serve anything with PHP. The PHP project says **all PHP installations serving web requests** are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Places PHP often hides in UK organisations:

- **Public websites and intranets** built on WordPress, Drupal, Joomla or Laravel.
- **Line-of-business web apps** on an old Windows or Linux server that nobody has touched in years.
- **Vendor products and appliances** that bundle their own copy of PHP, such as helpdesks, monitoring tools and some phone systems. These won't be fixed until the vendor ships an update.
- **Container images** with PHP baked in. Updating the host doesn't update PHP inside the image.

Updating your CMS or application **does not** fix this. The PHP version comes from the server, your hosting provider or your container image.

## What should I do today?

1. **Find every PHP runtime.** Check web servers, containers, vendor appliances and any Windows server with a `php.exe` or `php-cgi.exe` on it. Internet-facing systems come first.
2. **Update to a fixed release**: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On Linux, use your distribution's packages. Distributions received the patches in advance, but check the package changelog for the CVE numbers rather than relying on the version string, because backports keep the old version number.
3. **Restart every PHP worker** (PHP-FPM pools, Apache, IIS application pools) so nothing keeps running old code.
4. **Rebuild and redeploy container images** that include PHP.
5. **If you're on PHP 8.1 or older**, upgrade the branch. If you can't do that this week, get a backported fix from your distribution or LTS vendor, and limit who can reach the site meanwhile.
6. **Check for signs of compromise** (below) on anything that was exposed before you patched.

Cyber Essentials also requires fixes for "critical" or "high risk" vulnerabilities to be installed **within 14 days of release** ([requirements v3.3](https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf)). For PHP2Shell that means by 4 November 2026 at the latest, though you shouldn't wait that long.

## What about PHP on Windows Server and IIS?

IIS runs PHP through FastCGI using `php-cgi.exe`, and php-cgi is on the PHP project's list of affected setups. The fixed Windows builds were published on [php.net's Windows download page](https://www.php.net/downloads.php?os=windows) on 21 October. For IIS, use the **Non Thread Safe (NTS)** x64 build.

To update a typical IIS server:

1. Note the current PHP folder and its `php.ini`.
2. Download the matching NTS build for your PHP branch, and check its SHA-256 hash against the one on the download page.
3. Unzip it to a new folder, copy across your `php.ini` and any extra extensions, and point the IIS FastCGI handler at the new `php-cgi.exe`. Keeping the old folder makes rollback easy.
4. Recycle the application pools (or run `iisreset`) and check `phpinfo()` or `php -v` shows the new version.

If the server runs **PHP 8.1 or older on Windows Server 2012 or 2016**, you have two unsupported layers at once. The PHP project's 7.4–8.1 backports are source patches only, so there's no ready-made Windows build. Windows Server 2012 stopped getting security updates on 13 October 2026, and Windows Server 2016 follows on [12 January 2027](https://computecloud.co.uk/blog/windows-server-2016-end-of-support-options/). It's usually quicker to move the site to a supported PHP version on a supported platform than to patch around both. Our [Windows Server migration service](https://computecloud.co.uk/azure/migration/windows-server/) covers exactly this.

## What about PHP in Azure?

Microsoft's [guidance for Azure customers](https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/addressing-php2shell-cve-2026-109618-and-cve-2026-109619-upgrade-guidance-and-az/4566623) (21 October 2026, updated 22 October) is the same as everyone else's: **upgrade PHP**. It treats the Web Application Firewall (WAF) measures as a temporary extra layer.

| Where PHP runs in Azure | Who patches PHP | What to do |
|---|---|---|
| **Azure VMs** (Windows or Linux) | You | Update PHP as you would on-premises, then restart the workers. |
| **Containers** (AKS, Container Apps, App Service custom containers) | You | Rebuild images on a patched PHP base image and redeploy. Updating the host doesn't change PHP inside the image. |
| **App Service on Linux** (built-in PHP) | Microsoft | App Service controls PHP minor and patch versions and updates stacks after the PHP project releases fixes ([policy](https://learn.microsoft.com/en-us/azure/app-service/language-support-policy)). When we checked on 24 October, Microsoft hadn't published a rollout date. If you can't wait, switch to a custom container. |
| **App Service on Windows** | Nobody | PHP on Windows App Service [reached end of support in November 2022](https://learn.microsoft.com/en-us/azure/app-service/configure-language-php). Anything still running there needs moving. |

**Azure WAF stopgaps while you patch** (from Microsoft's post):

- **Azure Front Door WAF:** a new managed rule, ID **99006001** in the **MS-ThreatIntel-Response-CVEs** group, was rolling out when Microsoft published its guidance, with completion expected on **28 October 2026**. It works with Default Rule Set 2.0, 2.1 and 2.2, is **disabled by default**, and only takes effect when the rule action is Block on anomaly. It doesn't block requests. Instead it strips suspicious elements from responses, and it doesn't create WAF log entries. If you need it before the rollout reaches you, contact Microsoft Support.
- **Application Gateway WAF (v2):** no managed rule yet, though Microsoft says one is expected. Microsoft publishes request-side custom rules (added on 21 October) and a header-rewrite rule that deletes suspicious `PHPSESSID` `Set-Cookie` headers. It changed the rewrite rule's regular expression on 22 October, so copy the current version from Microsoft's post, and test it on a non-production gateway first.
- **Application Gateway for Containers:** header rewrite isn't supported, so patching is the only option for now.

## What if I can't update today?

The PHP project lists measures that **reduce exposure to known attack paths but don't make a server safe**:

- **CVE-2026-109618:**
  - set `memory_limit=-1` in a way applications can't override, such as `php_admin_value` in the FPM pool or Apache configuration;
  - keep `post_max_size` low: 8M if you don't need uploads, 32M if you do;
  - enforce request-size limits at the web server or proxy;
  - use a container or cgroup limit rather than `RLIMIT_AS` or `RLIMIT_DATA`.
- **CVE-2026-109619:**
  - set `session.upload_progress.enabled=0` in `php.ini` or the pool configuration (not `ini_set()` or `.user.ini`) and restart every worker;
  - on PHP 8.5, also set `fatal_error_backtraces=0`.
- **CVE-2026-115560:** on 23 October the PHP project published an informational advisory about a separate, less likely issue in session upload progress. It only affects applications that switch `session.serialize_handler` to `php` at runtime with `ini_set()`. The same `session.upload_progress.enabled=0` setting protects against it, and the fix comes in the next regular release.
- **Reduce exposure:** take the site off the internet, or restrict it to known IP addresses or a VPN, until it's patched. The Dutch NCSC gives the same advice.

## How would I know if I've been attacked?

When we checked on 21 October, early exploitation attempts had been reported but no confirmed compromises. The Dutch NCSC says it has no sign of active exploitation yet but [expects large-scale exploitation in the short term](https://github.com/NCSC-NL/php2shell), and public proof-of-concept code is circulating. Security researchers ([Huntress](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities) among them) suggest looking for:

- unusual multipart POST requests followed by memory-limit errors or bursts of HTTP 500 errors;
- unusually large `PHPSESSID` cookies in responses;
- PHP worker processes (`php-fpm`, `php-cgi`, `php-cgi.exe`, `httpd`) starting shells or tools such as `sh`, `bash`, `cmd.exe`, `powershell.exe`, `curl`, `wget` or `certutil.exe`;
- new files in the web root, new scheduled tasks or cron jobs, and new local accounts.

If you find any of these, treat the server as compromised. Isolate it, preserve the logs, and rebuild rather than clean. The NCSC's [incident management guidance](https://www.ncsc.gov.uk/collection/incident-management) is a good starting point.

## Need a hand?

If PHP2Shell has turned up old PHP sites on Windows Server 2012 or 2016, or a pile of servers nobody owns any more, that's a migration problem as much as a patching one. A [free assessment](https://computecloud.co.uk/assessment/) will tell you which workloads to patch, move or retire, and what a move to Azure would cost.

## Frequently asked questions

### What is PHP2Shell?

PHP2Shell is the name given to two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, disclosed and fixed on 21 October 2026. Both relate to how PHP handles memory when a request ends abnormally, and both can allow an attacker to run code on the server without logging in. The PHP project rates each one CVSS v4.0 9.2.

### Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. Any earlier release in those branches is vulnerable. PHP 8.1 and older get no fix from the PHP project, though some Linux distributions and LTS vendors provide backports.

### Does updating WordPress or my application fix PHP2Shell?

No. The flaws are in the PHP runtime, not in your application. Updating WordPress, Drupal, Laravel or any other PHP application doesn't change the PHP version underneath it. That comes from the server, your hosting provider or your container image.

### Is PHP on IIS and Windows Server affected?

Yes. The PHP project lists php-cgi among the affected setups, and IIS runs PHP through FastCGI using php-cgi.exe. Download the fixed Windows build (Non Thread Safe for IIS) from php.net, replace the PHP folder, and recycle the IIS application pools so no worker keeps running the old version.

### Is Azure App Service patched for PHP2Shell?

App Service on Linux controls the PHP patch version itself and updates its stacks after the PHP project releases fixes. When we checked on 24 October 2026, Microsoft hadn't published a rollout date. If you can't wait, run your app in a custom container with a patched PHP image, and consider the Azure WAF mitigations in the meantime.

---

Get a free Azure migration assessment: https://computecloud.co.uk/assessment/