> ## Content Index
> Fetch the complete content index at: https://blog.ifirestone.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# When the Patch Skips Your Version: What PHP2Shell Cost Governments, and What EOL Adds on Top
- URL: https://blog.ifirestone.dev/when-the-patch-skips-your-version-what-php2shell-cost-governments-and-what-eol-adds-on-top/
- Published: 2026-10-22T15:55:32.000Z
- Updated: 2026-10-22T15:55:32.000Z
- Description: You can't predict the next critical CVE, but you can predict your PHP version's end-of-life date. What PHP2Shell cost in one day, and why running EOL turns a bad day into a forced migration.
- Author: Ivan Firestone
- Tags: php, security, legacy, migration, english

---

> You can't predict the next critical CVE, but you can predict your PHP version's end-of-life date. What PHP2Shell cost in one day, and why running EOL turns a bad day into a forced migration.

At 07:43 UTC on October 21, 2026, Cloudflare saw the first attacks. The fix would not exist for another six hours and seventeen minutes.

By lunchtime in Europe, the Dutch national cybersecurity agency had taken its own website offline. DigiD, MijnOverheid and the Tweede Kamer were dark. Finland's state IT provider had pulled government network services, and France's Interior Ministry had switched off local administrative sites. The cause was a pair of PHP flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 and both allowing code execution without logging in.

This is not an article about how the exploit works. It is about the bill. Part of that bill nobody could have avoided. Part of it was scheduled years ago, with a date printed on [php.net](http://php.net/?ref=blog.ifirestone.dev). The useful skill is telling the two apart.

## The Part Nobody Could Schedule

Here is the timeline as [Sansec reconstructed it](https://sansec.io/research/php2shell?ref=blog.ifirestone.dev). Researchers reported the first bug to the PHP project on August 11\. A second team reported more on August 24\. On October 20 the details leaked, and the PHP team pulled its release forward. On the morning of the 21st the attacks began, and at 14:00 UTC the fixed versions shipped. Reuters reported that an AI model helped find the first flaw, which is one more reason to expect the next one to arrive faster.

Nobody running a PHP site had a calendar entry for any of this. If your security plan depended on knowing the day, it was never a plan.

And for most of October 21, the price was the same for everyone. PHP's own release notice for 8.4.27 said [updating is the only safe choice](https://github.com/php/php-src/releases/tag/php-8.4.27?ref=blog.ifirestone.dev), and until 14:00 UTC there was nothing to update to. Taking a site offline was the one control that worked. Dutch sites such as the Tweede Kamer and Tweakers [came back after the patch](https://www.rd.nl/a/geen-signalen-van-misbruik-php-lek-websites-komen-weer-online?ref=blog.ifirestone.dev).

A caution before going further. None of the reports I found say which of the blacked-out sites ran unsupported PHP. A blackout is what you pay when you cannot be sure what you run, or cannot change it quickly. EOL does not explain it. EOL is what makes it worse.

## The Part Printed on a Calendar

PHP's policy is simple. Each branch gets two years of active support, then two more of security fixes only, and then it ends. The [supported versions page](https://www.php.net/supported-versions.php?ref=blog.ifirestone.dev) has shown the dates for years.

| Branch | Security support ended / ends |
| ------ | ----------------------------- |
| 7.4    | 28 Nov 2022                   |
| 8.0    | 26 Nov 2023                   |
| 8.1    | 31 Dec 2025                   |
| 8.2    | 31 Dec 2026                   |
| 8.3    | 31 Dec 2027                   |

At 14:00 UTC the project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35\. Nothing came for 8.1 and older. Laravel Forge's advisory is blunt about it: [8.1 and earlier get no official fix and stay vulnerable](https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026?ref=blog.ifirestone.dev).

Some vendors stepped in. Plesk, for example, [rebuilt its 8.1 and 8.0 packages](https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-Remote-code-execution-in-PHP-shipped-with-Plesk?ref=blog.ifirestone.dev) on October 21\. That is a vendor decision, made on the vendor's schedule. Even the supported path was uneven: Sansec noted that the Remi repository, common on RHEL-based servers, did not have the fix on release day.

So the same alert produced two very different afternoons.

## Two Teams, One Alert

Imagine two teams. This is a hypothetical, with no numbers attached.

The first runs PHP 8.3 in containers behind a pipeline. Their afternoon: bump the base image to 8.3.36, rebuild, deploy, restart the workers. It is a patch release, so the application code does not change. The hard part is the speed of the pipeline, and they built that pipeline long before today.

The second runs a ten-year-old application on 7.4\. There is no official patch to wait for. Their options are all partial. They can set the interim configuration PHP suggested, which blocks one attack path and is not the fix. They can wait for a vendor backport and hope it arrives soon. They can take the site down. Or they can start the migration that was postponed every quarter, now with an attacker's clock running.

That migration is not a patch release. It is several minor versions of removed features and changed behavior, plus every Composer dependency that stopped supporting the old version. Done in an emergency, it has no test window, no rollback plan and no one who remembers why the strange workaround on line 214 exists.

The first team paid for maintenance, in small amounts, all year. The second pays the whole balance in one afternoon, at the worst possible price. That is the cost of EOL: not the vulnerability itself, but losing the option to respond calmly.

## Patching the Wrong Layer

There is a trap here for teams that think they are careful. Many organizations update WordPress, Drupal or Joomla and their plugins on a strict schedule. That is good hygiene, and it does not touch this problem. According to [Automattic's statement](https://www.newsweek.com/php-vunerability-php2shell-issue-websites-hack-server-12601225?ref=blog.ifirestone.dev), updating the CMS or its plugins does not fix the PHP runtime underneath. Researchers demonstrated the attack against current WordPress, Drupal and Joomla installations.

If the interpreter is frozen on a version nobody patches, a perfectly maintained application sits on top of an unmaintained foundation.

## The Long Tail

The emergency does not end when the sites come back. The Dutch NCSC said that experience with similar flaws suggests attackers keep exploiting them for a long time, and that this is likely to hold here too.

A patched site stops being a target. An unpatched one stays on the list. And a lot of sites are on that list: a September analysis of [WordPress.org](http://wordpress.org/?ref=blog.ifirestone.dev) data, [published by a hosting software vendor](https://www.xictron.com/en/blog/php-8-2-end-of-support-wordpress-upgrade/?ref=blog.ifirestone.dev), put the branches already past end of life at 37.6 percent of reporting WordPress installations, with 7.4 alone at 16.7 percent. Treat those as indicative, since they come from a secondary source.

## The Fair Objection

EOL does not always mean unprotected. Linux distributions often maintain old PHP versions for years. A 2023 report noted that Red Hat listed 7.4 as supported on RHEL 8 until May 2029, while Azure App Service followed the community end of life. If you run a supported distribution with backports, you have a real option.

It has costs, though. You depend on someone else's timeline, including on a day like October 21\. You still owe the migration, only later and bigger. And you need to know exactly which package gets the fix, which brings us back to inventory. Backports are a bridge. They are not a destination.

## What to Check This Week

Start with the question the blackouts forced on everyone: what PHP do we actually run? Not what the documentation says. What is installed, and what is running.

```bash
# Host: the installed CLI, and the PHP-FPM actually serving requests
php -v
php-fpm8.4 -v   # replace 8.4 with your branch

# Containers: first line of `php -v` in every running container
for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -v 2>/dev/null | head -n 1)
  echo "$c: ${v:-no php found}"
done

```

A new package on disk does not change a worker that is already running, so restart PHP-FPM or the web server after any update. Then write the answers down: every service, its PHP branch and its end-of-life date.

Three more habits follow. Put the EOL dates in a shared calendar with a six-month lead, and treat 8.2 on December 31, 2026 as the first entry. Budget the yearly minor upgrade as maintenance, since PHP ships a new version every November. And measure how long it takes you to ship a patch release end to end, because that number decided who spent October 21 restarting workers and who spent it making decisions.

## Conclusion

Nobody scheduled October 21\. Cloudflare's 07:43 alert came from an August report, a leak and a race that no application team could see. That part you can only survive, by being fast and knowing what you run.

But someone did schedule December 31, 2026, and it is on [php.net](http://php.net/?ref=blog.ifirestone.dev) for anyone to read. Written on October 22, PHP 8.2 has ten weeks left. The vulnerability was a surprise. The deadline never was.