On 21 October at 4 pm German time, the PHP project released patches for two critical vulnerabilities. By that evening the internet was full of articles whose headline essentially read "PATCH NOW!".
That was a good three weeks ago. The excitement has faded, the headlines have moved on. The vulnerable servers, unfortunately, have not all followed.
So this isn't another alarm piece, just a friendly question: So, patched yet? And if not – what's actually holding it up?
What happened, briefly
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and the reporting has settled on the nickname PHP2Shell – a not entirely accidental nod to Log4Shell. Both are rated 9.2 out of 10 under CVSS 4.0. In plain terms: attackers can execute code on web servers running PHP applications, without logging in and without anyone having to click anything.
All known PHP versions back to at least PHP 5 are affected, wherever PHP handles web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. The PHP security team rates mod_php as the highest risk, because an attack can take effect there before a single line of application code runs. The vulnerabilities were found with the involvement of Wiz.io and Calif.io, together with OpenAI.
The German Federal Office for Information Security (BSI) issued a security advisory with criticality level 3, orange, and has updated it twice since. The good news from the latest update: the BSI is not aware of any successful compromises in regulated industries or the federal administration. The less good news: automated exploitation attempts have been observed, and according to search engines the number of vulnerable systems worldwide is still very high.
The facts about the vulnerabilities come from the BSI security advisory (in German, version 1.2 of 22 October 2026). Status of this article: 13 November 2026.
The two-minute self-check
The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below that in its branch is vulnerable, unless someone has patched it in another way.
The first look goes to the server:
php -v
That's only half the story, though, because php -v shows the command-line version. The web server doesn't necessarily use the same binary. On Debian and Ubuntu it's worth checking FPM and the installed packages too:
php-fpm8.3 -v # adjust the version number to your installation
dpkg -l | grep php # Debian / Ubuntu
rpm -qa | grep php # Red Hat & co.
And here's the catch many people trip over: distributions like to patch without changing the version number. A Debian or Ubuntu package can carry an "old" version number and still contain the fix, because it was backported. The PHP version number alone isn't enough. What counts is your distribution's security advisory – Ubuntu, Debian and Red Hat list which package version contains the fix.
Docker is a chapter of its own. The PHP inside the container is the PHP from the base image, in exactly the state it was in at the last build. Deploying a new version of your application changes nothing about that. The image has to be rebuilt with a freshly pulled base image:
docker build --pull -t my-app .
docker exec <container> php -v # then check inside the running container
If your Dockerfile pins an exact patch version, you obviously have to bump it too. --pull only fetches what the tag points to.
And then there are the devices nobody thinks of when they hear "PHP". According to the BSI, products from F5, Citrix NetScaler, Palo Alto, OPNsense, Netgate pfSense, QNAP, Synology and cPanel are at least partially affected, because their web interfaces run on PHP. So the firewall in the server rack and the NAS in the office belong on the list as well. No apt upgrade helps there – only the vendor's firmware update.
"Why isn't it patched yet?"
Now for the entertaining part. In twenty years of web development I've heard every one of these reasons.
"It's running fine."
True. A vulnerable server runs just as well as a patched one. It doesn't notice, you don't notice. That's exactly the problem. "Running" is a server's normal state, not proof of security.
"The hosting provider takes care of that."
Maybe. With classic shared hosting or genuine managed hosting, the provider usually looks after the PHP runtime. Two questions are still worth asking: is it really managed hosting, or a VPS where the provider just pays the electricity bill? And did you at some point select an older PHP version in the control panel because the plugin from 2017 wouldn't run otherwise? Then the provider may be patching everything except the thing you actually use.
"But the container is up to date."
The code in the container is up to date. The PHP underneath is as old as the base image at the last build. The BSI is pretty clear about it: updating the application isn't enough, the PHP runtime itself has to be patched. If your last docker build was before 21 October, the container isn't up to date – it's just freshly deployed.
"We have a WAF."
Good. Cloudflare, Bunny Shield and others have published rules, and they stop quite a bit. But according to the BSI, full protection only comes from patching or taking the system offline. The same goes for the configuration workarounds doing the rounds: they reduce the attack surface, nothing more. A WAF is a seatbelt, not a reason to skip fixing the brakes.
"We're on PHP 7.2, there's no patch for that."
This is the most honest excuse on the list, because it's true. The PHP security team provided backport patches for the already unsupported versions 7.4, 8.0 and 8.1. For anything older there is no official fix. Some Linux distributions and LTS vendors ship patches for older versions – whether that applies to your environment needs checking. It's not something to rely on.
"Nobody dares touch the Laravel update."
My personal favourite, because I understand it so well. The application is eight years old, the developer who built it is long gone, and tests exist mostly in spirit. And an old framework version only runs on an old PHP version. So everything stays as it is, and everyone hopes it won't blow up on their shift.
That's not laziness. It's perfectly rational behaviour when an update feels like playing Jenga in the dark. It just doesn't do anything about the vulnerability.
The real point
Look closely and you'll notice: most of these excuses have little to do with the patch itself. Moving to a new PHP patch release takes minutes if the infrastructure is in good shape. Some operators even took servers offline as a precaution on patch day until it was done.
The actual problem sits one level deeper. A patch only helps if your version still receives patches. And the BSI is quite clear about where all those vulnerable systems come from: either they weren't patched, or they run on versions that have long been out of support and no longer get updates.
If you're on a version with a fix, you have a ten-minute ticket. If you're stuck on 7.2, you have a project. And that project doesn't get smaller with every month – it gets bigger.
That's where it pays to tackle the issue properly once, instead of trembling from one vulnerability to the next: lift the old application onto a supported PHP version, bring the framework along step by step, add tests where things creak. It isn't rocket science, but it takes someone willing to do it who knows where the usual traps are. If that's your bottleneck right now: that's exactly what my Laravel and PHP development is for – including version upgrades for applications that have a few years under their belt.
The next one is coming
What strikes me about PHP2Shell is less the vulnerabilities themselves than how they were found: by security companies working together with OpenAI. In its update, the BSI explicitly notes that the increased attention on PHP and AI-driven vulnerability research could lead to further vulnerabilities being found.
That doesn't mean the world ends every week from now on. It means "we'll patch when something comes up" ages worse as a strategy than it used to. The question is no longer whether the next critical vulnerability will arrive, but whether you'll be able to close it within an hour or have to plan a migration first.
So: type php -v, compare against the list above, check your distribution's advisory, rebuild your containers, don't forget the firewall. If everything is green afterwards – great, go get a coffee. If not, and you don't know where to start: drop me a line. No alarm bells, promise.
A patch is installed quickly. It only gets expensive when there's no patch left for your version.