# PHP2Shell: patching fast takes preparation

URL: https://brainpowergroup.eu/en/blog/php2shell-patching-fast-takes-preparation
Date: 2026-10-21
By: Erik Schoorl, Brainpower Group

PHP shipped an emergency update for two critical flaws on 21 October. We were done the same day. If you do not know where PHP runs, you will not be.

On Wednesday 21 October the PHP project shipped an emergency update for two critical flaws, CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell. They let an attacker run code on your web server without logging in. We had it fixed on our side the same day. My advice is to set up now what you need to patch within a day next time too, because many organisations could not simply update this week.

## What happened

On 20 October the PHP security team announced a release for the next day at 14:00 UTC. It covered two flaws, both with a CVSS score of 9.2. Details would only follow with the release. Even so, according to VirusTotal technical details leaked hours earlier, and according to CERT-EU proofs of concept are circulating.

The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project says every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php. There, a demonstrated attack works with a single request without a login, before any of your own code runs.

The first flaw is in how PHP handles running out of memory. The second leaves state from an earlier request behind, which a later request on the same worker can still use. Your own code can be flawless and you are still exposed.

## Who could not keep up

In the Netherlands and Belgium sites went offline on 21 October, The Brussels Times reports, among them the Dutch government portal MijnOverheid and the Belgian school platform Smartschool. The Belgian Centre for Cybersecurity advised taking a site offline if you cannot install the update straight away. CERT-EU says the same: if patching is not feasible, isolate the application from public networks.

That so many organisations took that step does not surprise me. On 21 October VirusTotal counted about 1.1 million PHP servers that show their version. About 758,000 of them run PHP 5.4 to 8.1. The PHP project no longer releases updates for those versions. About 272,000 run a supported version, 8.2 to 8.5.

So if you are on PHP 7.4 or 8.1, you cannot simply update this week. For 7.4, 8.0 and 8.1 the security team only published small source patches. You compile those yourself, or you need a vendor who does it for you.

There are more reasons it goes slowly. The PHP project said the widely used rpms.remirepo.net repository would have no updates on the day itself. And CERT-EU points out that commercial and open source products with PHP inside may be affected too. You do not update those yourself; you wait for the vendor.

## What makes fast patching possible

Whether you get through a day like this is decided beforehand. On the day itself you can only carry out what you prepared.

Start with a list of everything PHP runs in: your own applications, the servers and containers under them, and the packages you bought or installed, such as a web shop, a wiki or a ticketing system. Note the PHP version for each and who looks after it. Without that list you spend the first hours searching.

Run a supported version. PHP 8.2 gets no security updates after 31 December 2026, so now is also the time to plan that one. I wrote about planning such an upgrade as fixed work every year in [Laravel in 2026](/en/blog/laravel-in-2026).

Give updates one fixed route. If you build images in a pipeline, a new PHP version is a new build and a deploy. If you install by hand on servers, someone has to log in to each server. With the first you start a build. With the second it depends on how many servers you have and whether anyone has time, and you still have not tested.

Agree who may decide to take a site offline, and have a maintenance page ready. You do not want to make that call on the day itself with five people.

A fixed update rhythm also helps with flaws that come without warning. Aleksa wrote last week about [patching without waiting for the CVE](/en/blog/patching-without-waiting-for-the-cve). In that case a flaw had been exploited for a month before the CVE appeared.

## What to do now

Check which PHP version runs on every server and in every container. If it is not 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched package from your distribution), update. Linux distributions and vendors with extended support received the patches in advance, so check with them first.

If you cannot update straight away, use the temporary measures from the PHP project's advisory, such as `session.upload_progress.enabled=0` in `php.ini` and a restart of every worker. The PHP project is clear: those measures reduce the risk, but they do not make your installation safe. My advice in that case is to take the site offline until the update is in.

Ask the vendors of packages with PHP inside whether they have an update and when. And if an application still runs on PHP 7.4 or 8.1, put the upgrade at the top of the plan. How to hand such an older application to a new team is covered in [handing over legacy code to a new team](/en/blog/handing-over-legacy-code-to-a-new-team).

## Sources

- [PHP: Security Advisory and release announcements, 20 and 21 October 2026](https://www.php.net/archive/2026.php)
- [PHP: advisory GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [PHP: advisory GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/)
- [VirusTotal: Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619](https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html)
- [The Brussels Times: Major websites go offline as critical PHP vulnerability triggers security fears](https://www.brusselstimes.com/belgium/2371464/major-websites-go-offline-as-critical-php-vulnerability-triggers-security-fears)

## Frequently asked questions

**Which PHP versions contain the fix for PHP2Shell?**

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no update from the PHP project. For 7.4, 8.0 and 8.1 the security team only published small source patches.

**Is turning off session.upload_progress enough?**

No. According to the PHP project, the temporary measures reduce the risk, but only an update fixes it. If you cannot update straight away, take the application off the internet until the fix is in, as CERT-EU advises.

**How do you make sure you can patch quickly next time?**

Know where PHP runs and which version, including products with PHP inside. Run a supported version, roll out updates through one fixed route and agree in advance who decides to take a site offline.

---

Source: https://brainpowergroup.eu/en/blog/php2shell-patching-fast-takes-preparation
Brainpower Group, contact: https://brainpowergroup.eu/en/contact, hello@brainpowergroup.eu