The PHP project announced on Wednesday, October 21st, 2026 that there are two critical vulnerabilities affecting PHP itself.
This was well-managed, and everything is fine. The gloom and doom is, quite simply, sensationalism. Let's put this into perspective, shall we?
TL;DR
Don't panic.
Action is required if and only if you are self-hosting, or using containers (Docker, Podman, etc). If you're hosting a site with a commercial provider there's nothing to do.
Two critical PHP vulnerabilities were discovered and patched. The patches are in the latest versions of PHP 8.2, 8.3, 8.4, and 8.5 available. If you are self-hosting, updating PHP – and remember to restart your PHP-FPM and web server processes. If you are hosted on a commercial provider, relax, your host has (hopefully) installed those patches.
If you're on PHP 8.1 or earlier you may or may not have access to a patched version. Ask your upstream provider / host. If you can upgrade to the latest PHP 8.2, 8.3, 8.4, or 8.5 you should do that instead.
At the time of this writing, well over 24 hours after the patches were made available, there is no publicly known, working exploit.
Critical vulnerabilities like that are discovered and fixed across software used in web sites dozens of times every year. Most of them get no attention. This was blown out of proportion for comically mundane reasons. But we're getting ahead of ourselves.
What is actually going on
PHP discovered two vulnerabilities which affect every PHP version. While the PHP Foundation doesn't say which versions are affected, the consensus is that at least every version from 5.0 onwards – every version published in the last 22 years – is vulnerable. The vulnerabilities have a very high score: 9.2 out of 10.
If you read that and are quaking in your boots, relax. Let's reframe this more pragmatically.
PHP versions 8.1 and earlier are out of support for anything between 1 and 21 years. They have countless other bugs and security issues. Most of them don't run on anything modern. The vulnerabilities are also fixed at the same time as they are announced.
Therefore:
- Sensationalist framing: All PHP versions released the past 22 years are vulnerable!
- Pragmatic framing: All suppirted PHP versions released before October 21st, 2026 were vulnerable.
The vulnerability score follows a set of rules. It's a combination of the effort necessary to exploit it, who can exploit it, and what they can do once they exploit it.
A vulnerability score of 9.2 doesn't mean it's easy to exploit. In fact, it's pretty damn hard in this case. What it reflects for these two vulnerabilities is that it can be exploited by a random visitor (zero authentication necessary), and if they exploit it they can run any code they want as the user running the PHP process (usually not root, but could still mess up your site).
If you followed the link above, you have seen that whether a vulnerability is classified as None, Low, Medium, High, or Critical depends entirely on the score.
Both the score and classification are a mesure of how urgent patching this is. A "critical" vulnerability should have the patch applied a.s.a.p. to prevent the worst. It does not mean the world is ending, it just tells us techies that we really need to drop everything and apply the patch. This happens several times a year in operating systems, web servers, databases, programming languages (including PHP and Node.js – which also had a "critical" vulnerability fixed the same day!), our IDEs, and just about anything.
Therefore:
- Sensationalist framing: PHP IS HACKED! IT'S THE END OF THE INTERNET!
- Pragmatic framing: Systems administrators need to install the PHP patches as soon as possible.
You may have noticed that the pragmatic framing strictly adheres to reality, it's mundane, it's muted, and makes for a supremely lousy headline. Which headline would you click? “Every version of PHP from the last 22 years is hacked! THE INTERNET IS IN SHAMBLES!” or “PHP announces patches for two critical vulnerabilities, patches are available and already being installed”. You get it now.
Are they easy to exploit?
No.
Both require pretty specific conditions to trigger. Since the POC (Proof of Concept – working code demonstrating the vulnerability) has NOT been released yet it's proven very difficult for attackers to reproduce. The people who discovered it have said that it would take a very skilled attacker about a week to work out, and a team of developers about a month.
Attackers have tried to use AI coding assistants to develop exploits against these vulnerabilities. I am writing this roughly 24 hours after the announcement, and there's still no publicly known working exploit. There are several failed attempts discovered in the wild, and they all came after the announcement, after everyone and their dog had already patched.
Can you mitigate them?
If you can update to the patched versions no mitigation is necessary or recommended. If you can't update, there are mitigations, and they do come with caveats.
Because the vulnerabilities are in PHP itself, PHP-based firewalls – like Admin Tools – cannot address them. The vulnerability triggers before the code written in PHP runs; it affects the code (interpreter) which loads and executes PHP itself.
The PHP project itself has published mitigation guidelines, explicitly stating it is for people who are unable to update. Moreover, Web Application Firewalls like mod_security2 on Apache, CloudFlare, Sucuri, Immunify360 etc can mitigate the problem, at least to a very large extent, by blocking the requests which fit the exploitable shape.
That said, I would advise you to not use either of these mitigations, unless you have a pragmatic reason you are unable to upgrade to a non-vulnerable version of PHP. The mitigations have side-effects which may be just as bad as the vulnerability itself.
PHP's mitigations remove the PHP memory limit. This can lead to memory exhaustion on your server in case a plugin or module goes off the rails and starts consuming too much memory.
Both PHP's and third party WAF mitigations block long form submissions and large uploads to your site.
Finally, PHP's mitigations disable backtraces in error exceptions which makes troubleshooting a broken site outright impossible.
Knee-capping your site is only worth it if you have absolutely no other way to protect it. Updating to a patched, non-vulnerable version of PHP is the correct way to handle this, and makes these mitigations obsolete. You can have a safe site without knee-capping it.
Why all the panic?
As it's always the case, there are comically mundane reasons: someone messed up, and herd mentality took over.
The PHP Foundation managed this vulnerability in an exemplary fashion.
On Tuesday, October 20th they made a public announcement of the upcoming security patch. The idea was to provide a 24 hour ahead warning to everyone.
At the same time, they contacted people distributing PHP binaries – the compiled software running on your servers and computers – to give them enough time to prepare new releases. This is the standard way to handle such critical fixes. Distributors need time to compile new versions, package them, test them, and prepare the infrastructure to distribute them. As is also typical, there was an embargo: this code and the compiled binaries were note to be released until Wednesday, 21 October 2026 at 14:00 UTC.
Then, the mess-ups happened – by other people.
The company who discovered the issue accidentally released the video showing their exploit running against a server. They quickly deleted the video, but the thing about the Internet is that nothing is ever really deleted. This created a lot of panic because it showed a no-authentication attack which resulted in a shell on a server, just by virtue of the server running PHP. You may have noticed the missing context here: there was no indication of how difficult it is to construct this attack, only that it exists and can be used, and there's no indication you can get root (the highest privilege user on a server). It's like someone released a video of them breaking down a door at a house and the entire world going mad saying that no house door ever made is or can ever again be safe. I believe you've spotted the logical fallacies here.
The second mess-up was a different company breaking the embargo by a whooping six hours which forced the PHP Foundation to rush the release after all. Breaking the embargo was demonstrably unwise. It led to a lot of misinformation floating about by people who took a quick look (or, most likely, had their AI agent take a very quick and probably very hallucinating look) at the patch and make all sorts of wild claims.
Mundane mess-ups. Logical fallacies. Herd mentality. Rumor mill. It's all so comically mundane and so transcending time and domains of human endeavor it makes one wonder if maybe we are the least, not most, intelligent species on the planet.
But companies and governments took their sites off-line!
What you need to understand about both companies and government is that they are neither run by techies, nor on common sense.
The world is run by middle managers. Middle managers panic easily, especially when reading sensationalist headlines. No techie worth their salt would've put an entire web server off-line in anticipation of a security patch – unless their employment was threatened by a sufficiently spooked middle manager.
The same fear-mongering punters writing the sensationalist headlines see that these sites were taken off-line, and take it as a direct confirmation that their nonsense is real. More middle managers read the, now updated, fear-mongering articles and watched increasingly frantic videos, leading to even more sites getting taken down for no reason at all.
I believe the technical term for this phenomenon is “circle jerk”.
Do I need to do anything?
It depends on how you are hosting your sites.
If you are self-hosting: You need to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you are on an older version of PHP, check with your upstream distribution to see if they have backported the fixes. If they have, install them a.s.a.p. If they haven't, you either get to upgrade to a supported version of PHP (as you should have done already), or you get to apply the aforementioned mitigations which may or may not cripple your site.
If you are using containers: Most container images for PHP software come with the entire environment: web server, database server, and PHP. You need to update the container image, assuming its provider has created a new image with a new PHP version. We just released new images for Akeeba Panopticon for this reason.
If you are using a commercial hosting provider: They should have already updated their servers. Check their support pages. In most cases they will have put a sticky notice to let you know.
What should I not do?
Do not panic.
Do not take your site off-line.
Don't implement random changes you read on-line / watched in a video / were told by AI.
Do not even entertain the thought that going for a proprietary site service would magically make you immune to security issues. They, too, have security issues – and I can assure you they do not run on pixie dust and unicorn tears, they run on a lot of the same software you'd perceive as running away from.
cPanel and the PHP version conundrum
You know how the PHP Foundation said to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35? That's because these are the versions released by the PHP Foundation which include the fix for the two vulnerabilities.
CloudLinux, what cPanel is using, decided to follow a different approach. They applied the patches to the previous PHP versions, PHP 8.5.11, 8.4.26, 8.3.35 or 8.2.34. The vulnerable versions are, therefore, PHP 8.5.11, 8.4.26, 8.3.35 or 8.2.34, whereas the patched versions are _also__ PHP 8.5.11, 8.4.26, 8.3.35 or 8.2.34.
It's not a typo. The vulnerable and patched versions of PHP in cPanel are identical.
Thankfully, there is a way to find out if you are running a vulnerable version or not – just not one I would consider “sensible” even in the loosest definition of the word.
On Joomla go to System, System Information, PHP Information. Otherwise, create a phpinfo.php file with <?php phpinfo(); in it and access it over the web. Near the top of the page, the second table row reads "Build Date". If it's anything on or after "Oct 21 2026", you're safe. It it's older than that, you're running a vulnerable version.
AI coding agents and vulnerabilities
I have said quite often the last year or so that in the age of AI coding assistants you either upgrade or you are hacked. I usually follow that up with the observation that before AI coding assistants it took attackers an average of 8 hours to develop an exploit after a security patch was released. AI coding assistants accelerate that work, which has brought down the average exploitation time to an hour. Therefore, you either update as fast as you can, or you risk getting hacked.
But here I am today, telling you that 24 hours after PHP published a patch for two critical vulnerabilities with a 9.2 out 10 exploitation score there's still no publicly known, working exploit.
Two observations here.
First of all, no publicly known, working exploitation code does not mean there is no working exploit. It only means that if it does, it's not publicly known. It also doesn't mean that there's no public known exploit; it only means it's not working.
The second observation is that word I've been using for the past year that does a lot of heavy lifting. “Average”. I have not been saying that every security patch leads to an exploit within the hour. I only said that this applies on average. Some issues are simple enough to knock out an exploit in minutes, some take days.
My observation and warning still holds true: update, or get hacked. It didn't happen this time, mostly thanks to the tireless and thankless work of countless people in the PHP Foundation, Linux distributions, security companies, hosting companies, and I'm sure I'm forgetting a bunch. It might happen next time, when a non-critical issue gets exploited really fast, and becomes an integral part in a critical exploit chain.