research/the-php-emergency-and-the-cost-of-falling-behind
The October 2026 PHP Emergency: Why Staying Current Always Costs Less
Original Research • October 21, 2026 • 9 minute read
Executive Summary
On 21 October 2026, the PHP project released fixes for two critical vulnerabilities that can let an attacker run code on a web server without logging in. CERT-EU, the cybersecurity team for EU institutions, had already advised organizations that could not patch quickly to consider taking their sites offline, and several government bodies did exactly that.
The day went very differently depending on one thing: how current the site’s PHP was. A site on a supported branch had a patch release waiting, often already packaged by its Linux distribution. A site on PHP 8.1 or older had no official release to install at all. Its owners faced an emergency upgrade across years of skipped changes, a hand-applied backport, or a dark website.
Staying current is not a cosmetic habit. It decides whether a security emergency costs you an afternoon or a week.
This paper sets out what happened, why the cost of falling behind compounds, and the simple cadence we have used with clients so that a day like this one is routine.
What happened in October 2026?
The sequence below is drawn from the PHP project’s own announcements and from reporting by The Register, The Next Web and Reuters. Some details were still developing when this was written on 21 October 2026.
On 20 October, the PHP security team gave advance notice of a security release scheduled for Wednesday 21 October at 14:00 UTC. It covered two critical vulnerabilities, both rated 9.2 on the CVSS v4.0 scale, and the team warned it would release early if details leaked or attacks began. Claims about the flaws were already circulating online before the scheduled disclosure.
On the evening of 20 October, CERT-EU published advisory 2026-018. It told organizations to identify every PHP application they run, prepare to patch them all at once, and where patching was not possible, to “consider isolating internet-facing applications from public networks until a fix can be applied.” Reporting named Finnish government services and the websites of the Dutch parliament, Dutch cybersecurity authorities and the Dutch data protection regulator among the sites taken offline as a precaution. The privacy group noyb temporarily withdrew its website too.
On 21 October, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advisory describes two flaws:
- CVE-2026-109618, remote code execution via out-of-memory corruption. Out-of-memory handling can interrupt PHP while request data is only partly set up, and cleanup can then treat that invalid data as valid.
- CVE-2026-109619, remote code execution via stale global state. Internal state from one request can survive after its memory is freed, and a later request handled by the same worker can use it.
The advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php, where “an unauthenticated request can trigger the attack before any application code runs.” In other words, it did not matter how carefully the application itself was written.
On exploitation, reports differed. The Register quoted watchTowr, a security firm, saying it had seen attempts in the wild but that nobody had been successful to date. Australia’s Cyber Security Centre said it was not aware of active exploitation.
Who had an easy day, and who had a hard one?
The PHP project supports each branch for a fixed period, then stops. On 21 October 2026 the supported branches were 8.2, 8.3, 8.4 and 8.5. Everything older was past end of life.
| Where the site stood on 21 October | What fixing it meant |
|---|---|
| A supported branch, kept on current patches | Install one patch release, often already in the distribution’s packages. Restart PHP. Done. |
| A supported branch, but months of patches behind | The same single update. Patch releases are cumulative and do not change behavior on purpose, so the gap costs little. |
| PHP 8.2 | Patched today, but its security support ends on 31 December 2026. The next critical flaw after that date will have no release for 8.2. |
| PHP 8.1 or older | No official release. Options: a vendor’s backported package, the minimal source backport PHP published for 7.4, 8.0 and 8.1, an emergency upgrade, or taking the site offline. |
The first two rows are the point. A site that stays on a supported branch can fall a little behind on patches and still recover with one routine update, because each patch release contains every earlier fix. What it cannot do is fall off the supported list, because that is where the updates stop.
The PHP team went out of its way here. It published source backports for 7.4, 8.0 and 8.1, which it does not normally do for end-of-life versions. Even so, applying a source backport means building PHP yourself, which most small businesses on shared or managed hosting cannot do. The help existed, but it was not help most of them could use.
Why does the cost of falling behind compound?
A skipped upgrade feels free in the month you skip it. Nothing breaks. The site keeps working. The cost does not disappear, though. It accumulates in three places.
The language itself. Every new branch deprecates some behavior and removes things the previous deprecations warned about. Moving one branch at a time means dealing with a handful of warnings. Moving across four or five at once means meeting all of them together, including the large break between PHP 7 and PHP 8.
Everything built on top. Plugins, themes, frameworks and libraries move with the language. A site that is several versions behind usually depends on plugins that are several versions behind too, some of which have since been abandoned. Upgrading PHP then means upgrading or replacing those as well.
The people who remember how it works. The longer a system goes without change, the fewer people understand it, and the less anyone trusts it to survive a change. That fear is itself a cost, and it is often why upgrades keep being postponed.
None of this is unique to PHP. The same pattern applies to Node.js, to frameworks, to the operating system under a server, and to mobile apps, where Apple and Google raise their build requirements every year. Software that is not moving forward is falling behind, because everything around it is moving.
Constant advancement is the cheaper path
The alternative to emergency upgrades is not heroic effort. It is small, boring, scheduled work. The cadence we have used with clients is quarterly preventive maintenance and an annual review, with urgent security releases applied as they arrive:
- Urgent security releases within days. Patch releases on a supported branch are designed to be safe to apply. When one fixes something critical, apply it promptly and restart.
- Preventive maintenance every quarter. Apply the updates that have built up across the whole stack: the language runtime, the framework or CMS, plugins and the server underneath. List every component with its version and the date its security support ends.
- A full review every year. Step back and plan the bigger moves, such as moving to the next PHP branch while the current one still has plenty of runway, on a date you choose and with time to test. Anything with less than a year of support left gets a planned upgrade.
Run that way, a day like 21 October becomes routine: check that the patch is installed, restart, confirm. The work that would have been a crisis was already done in small pieces, months earlier, when nobody was in a hurry.
This is not a theory for us. In the past, graphic designers and creative firms have run custom content management systems we built for them. Those systems were on quarterly preventive maintenance with an annual review, and when smaller security events of this kind came along, they came through without drama. Nothing in that schedule was clever. It was simply done every quarter, so there was never a large gap to close in a hurry.
We wrote a short script that checks a list of PHP installs against php.net and flags anything behind or out of support. It is in our engineering note Checking Every PHP Install Against php.net. For how to read an advisory like this one while details are still emerging, see Reading a Security Advisory in the First Hours.
What to do this week if you run PHP
If you have a website, there is a reasonable chance something in your business runs PHP even if you have never chosen it. WordPress, Drupal, Joomla and Magento all run on it, as do many hosting control panels. A short list for this week:
- Find every PHP install. Ask your host or developer which PHP version each site runs. Include staging sites, old microsites and anything on a hosting control panel.
- Update to a fixed release. That is 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. Restart PHP so every worker picks it up.
- If you cannot update yet, apply the configuration changes in the PHP advisory, knowing they reduce exposure but do not make the server safe, and consider taking the site offline as CERT-EU advised.
- If you are on PHP 8.1 or older, treat this as the push to upgrade, not just to patch. A backport gets you through this flaw. It does not get you through the next one.
- If you are on PHP 8.2, schedule your move to 8.3 or newer now. Support ends on 31 December 2026.
Where an audit fits
Most small businesses do not know which versions their systems run until something forces the question. That is the gap a regular review closes.
Our Audit Sprint maps the systems a business runs today and ends with a written plan. For a business running PHP, that plan covers exactly this: what runs where, what version it is on, when its support ends, and what to upgrade first. Our Care Plans keep it current after that, with updates applied as they ship and a quarterly review that looks at the whole stack again.
Conclusion
The October 2026 PHP emergency was serious, and the PHP project handled it well: advance notice, fixes for every supported branch, clear mitigation guidance, and backports for versions it no longer supports. The organizations that struggled were mostly not struggling with the patch. They were struggling with the distance between where their software was and where it needed to be.
That distance is a choice, made a little at a time. Keep it short, and the next emergency is an afternoon.
Sources
- PHP project, security advisory and release announcements, 20 and 21 October 2026
- PHP project, supported versions
- The Register, PHP devs publish critical bug fix as site owners warned: pull ‘em offline if you’re unpatched, 21 October 2026
- The Next Web, EU cybersecurity team says unpatched PHP sites may need to go offline
- Reuters, EU agency warns websites may need to be taken offline as PHP prepares patches, 21 October 2026
Related reading
- The Case for Boring Web Architecture
- A Runbook for a One-Person Operation
- Your Website Is an Asset You Own
Frequently asked questions
Which PHP versions fix the October 2026 vulnerabilities?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. They fix CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2, which can allow unauthenticated remote code execution. Linux distributions received the patches in advance, so updated packages may arrive under your distribution's own version numbers.
Is PHP 8.1 or older patched?
Not by the PHP project. Its advisory says PHP 8.1 and older no longer receive updates. Because of the severity, the security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source, and some distributions and long-term support vendors ship their own fixes. Otherwise the advice is to upgrade to a supported version.
Do the PHP vulnerabilities affect WordPress sites?
WordPress runs on PHP, so a WordPress site is exposed if the PHP underneath it is unpatched. The PHP advisory says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Updating WordPress itself does not fix it; the PHP runtime on the server has to be updated.
Can I mitigate the PHP flaws without updating?
Only partly. The PHP advisory lists configuration changes, such as disabling session upload progress and lowering post_max_size, that block known attack paths, and says plainly that they do not make an installation safe. CERT-EU advised isolating internet-facing applications that cannot be patched. Updating is the only complete fix.
Why does falling behind on versions make security fixes harder?
Security releases only go to supported branches. A site one patch behind installs one update. A site several major versions behind has no update to install, so the fix becomes an upgrade across every change it skipped, done under deadline. The cost of a missed upgrade does not disappear; it waits for the worst possible day.
How often should a small business review its software versions?
We use a simple cadence: apply urgent security releases within days, do preventive maintenance every quarter, and hold a full review once a year. The quarterly pass applies updates across the stack and lists every runtime and framework with its version and the date its security support ends. The annual review plans the bigger moves, such as a new PHP branch, well before the old one reaches end of life.