The critical PHP vulnerability patched on 21 October 2026 is fixed by updating the language your software runs on, and no change to your own code will close it. If you paid for a custom app and assumed someone else keeps its engine current, today's the day to check who that is.
The short version
- The PHP flaws patched on 21 October 2026 are in the language runtime, so no change to your own code fixes them.
- The runtime is the part of a software project that most often has no owner, especially in older apps and containers.
- PHP 8.1 and older get no fixes from the PHP project, which turns a delayed upgrade into a real risk.
- AI has shortened the gap between a fix being announced and attacks starting from weeks to hours.
- A firewall buys time, but the support agreement for any PHP app should name who updates the runtime and how quickly.
What happened with PHP on 21 October?
On 21 October the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two flaws that can let someone with no login run their own code on a server, and told every user to update immediately. Both are rated 9.2 out of 10, they affect every PHP installation that serves web pages, and the project's own advice is that there are no complete workarounds, so updating is the only safe choice.
Researchers have nicknamed the pair PHP2Shell. They're in how the language cleans up after a request goes wrong, which has nothing to do with the quality of the code your developers wrote, and researchers at Wiz showed them working against fresh installs of WordPress, Drupal and Joomla. The same weakness can also expose passwords, tokens and API keys sitting in the server's memory, and Unit 42 counted more than 22.6 million exposed installations online that could be vulnerable.
Why your developer's code can't fix this
If you've paid for custom business software, it's almost certainly built in layers. Your developer writes the part that's yours, the screens and the business rules and the connections to your other tools, and it sits on top of a runtime, the engine that actually runs that code on the server. Cloudflare's write-up is plain about it, saying that updating website code or plugins alone does not fix these vulnerabilities, because they live in the runtime.
That matters because the runtime is the part of a project that very often has no owner. Plenty of apps built a few years ago were handed over with the code in one place, the hosting in another and a support agreement that covers bugs in the app but says nothing about the software underneath it. Some were packaged into containers, a sealed copy of the app and everything it needs to run, which is a sensible way to ship software, except that the PHP version is sealed in with it and only changes when someone rebuilds the container and puts it live again.
Is my business affected by the PHP critical vulnerability?
If you run anything built in PHP, assume you're affected until someone shows you otherwise, and don't let your own memory of what you've got be the final word. That covers apps written with Laravel or Symfony, a client portal, a WooCommerce or Magento shop, an internal tool on a server nobody has logged into since 2022, and the staging copy your developer made for testing and then forgot about. Patchstack's advice is to list every PHP install you have, including test sites, containers and any third-party software that quietly bundles PHP inside it.
Age makes it worse. The PHP project no longer sends fixes for version 8.1 or anything older, and Help Net Security reports that the project's only help for 7.4, 8.0 and 8.1 is a set of minimal fixes for people who build PHP themselves from source, so anything older depends on a backport from your hosting vendor or an upgrade. If your app is stuck on an old version because upgrading it always looked expensive, this is the week when not upgrading starts to cost more.
AI has shortened the time you have
These flaws aren't new. Help Net Security reports that they had been in the language for decades, and that frontier AI models substantially reduced the effort needed to turn them into a working attack. The identifiers also leaked on a forum the day before the planned announcement, and by the morning of the announcement hosting companies were already reporting attempts to exploit them to Patchstack.
We used to be able to tell clients they had a week or two between a fix being announced and attacks becoming common. For a flaw like this one that window is now measured in hours, and we'd expect it to keep shrinking as the same AI tools that help us write software help other people break it. That changes what a sensible support arrangement looks like, because "we'll get to it in the next maintenance window" was fine when the next window came before the attackers did.
What to ask whoever runs your software this week
You don't need to understand the technology to get a useful answer. Ask which version of PHP each of your systems runs, including test copies and anything in a container, whether today's update has been applied and when, and what the plan is for anything stuck on 8.1 or older. Then ask whether there's a firewall in front of the app, because Cloudflare made protective rules available on every plan, including free ones, and switched them on at 03.02 UTC on 21 October, hours before the details were public.
A firewall buys time while the update is applied, and nobody should treat it as the fix. If your developer sees signs that someone got in, such as strange errors or the server restarting itself, Patchstack's advice is to treat the server as compromised and change every password and API key it holds. If you want to know for certain how exposed you are, an authorised test from a security tool like Barb will find the holes before someone else does.
How we build so the runtime isn't your problem
For new projects at Swarm Labs, we lean towards platforms where the provider keeps the runtime patched. Our own Foundation CMS runs on Cloudflare Workers, where Cloudflare looks after the engine and there's no PHP server for a client to keep current, which is why nothing built on it needed touching today.
Plenty of good software is written in PHP, and we wouldn't tell anyone to rewrite a working app because of one bad week. If a project does run on PHP, though, the support agreement should name who updates the runtime and how quickly, and that's something we'd put in writing before launch rather than after an incident. It's one of the first things we look at when we take on custom software development that somebody else started.
The software you paid for still needs an owner
An app isn't finished when it launches, because the engine underneath it keeps changing whether anyone is watching or not. Find out today who owns that engine for each system you run, and if the honest answer is nobody, fix that before the next critical vulnerability arrives.
If this is a problem in your business, talk to us about it.
Sources
- PHP: Security advisory, critical remote code execution vulnerabilities
- Cloudflare: Cloudflare deploys protections against php2shell vulnerability
- Unit 42: Threat brief, critical vulnerabilities in PHP
- Help Net Security: PHP2Shell, critical PHP vulnerabilities patched, update now
- Patchstack: Major security alert, PHP vulnerable to critical RCE
- Infosecurity Magazine: Critical PHP vulnerabilities leaked ahead of scheduled security patch