On 21 October 2026 the PHP project released urgent fixes for two critical security flaws, now known as PHP2Shell. If we host your site, here’s the short version: it’s done, and you don’t need to do anything.
In short: PHP2Shell is a pair of critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619) that can let attackers run code on a web server without logging in. PHP fixed them in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. We rolled the fix out across the servers we manage within 24 hours of PHP’s release.
What is PHP2Shell?
PHP2Shell is the name given to two security vulnerabilities in the PHP engine, the software that runs behind WordPress, WooCommerce, Magento, Laravel and a huge chunk of the web. Both are rated 9.2 out of 10 on the CVSS v4 severity scale, which is firmly in “critical” territory.
The worrying bit is the type of flaw: unauthenticated remote code execution. In plain English, that means someone on the internet could potentially make your server run their own commands, without needing a username or password.
Why is a flaw in PHP itself such a big deal?
Most security problems live in a particular plugin or platform, so only sites using that thing are affected. PHP2Shell is different. The flaws sit in PHP, underneath everything else, so a perfectly well-maintained Magento store or WooCommerce shop can be exposed even if its own code is spotless.
Researchers also noted that the malicious request can be handled before any of the site’s own code runs, so a login page or security plugin doesn’t stand in the way.
Which PHP setups are affected?
According to PHP’s own advisory, every PHP installation serving web requests is at risk. That includes:
- Apache with mod_php, which PHP considers the highest risk, because a working exploit was demonstrated against it.
- PHP-FPM, the setup used with NGINX and many modern hosts. It’s still affected.
- php-cgi, FrankenPHP and LiteSpeed, which PHP also lists as at risk.
The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get official releases. The PHP security team did publish minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions have backported the fix into their own packages, but many old servers simply won’t get one.
Are these PHP flaws being exploited?
Yes. Security firms reported attacks in the wild, and on 26 October 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 to its Known Exploited Vulnerabilities catalogue, the list of flaws it has evidence are being used in real attacks.
How widespread those attacks are is still being debated. Some researchers have found that public exploit code doesn’t work against a default setup without extra conditions. But “it’s harder than it looks” isn’t a reason to wait.
When a critical flaw lands in PHP itself, the question isn’t whether your code is good. It’s how quickly your servers get the fix.
How did we patch PHP2Shell in 24 hours?
We jumped on it. PHP released the fixed versions on 21 October, and we had them rolled out across the servers we manage within 24 hours.
Our hosting runs on our own NGINX and PHP-FPM stack, so we weren’t on mod_php, the setup PHP flagged as highest risk. But FPM was still affected, and we didn’t see that as a reason to hang about.
Why did speed matter so much?
The moment a security fix is public, attackers can compare the old and new code to work out exactly what was broken. The gap between “fix released” and “people trying to exploit it” can be very short. Every hour a server sits unpatched is an hour it’s an easy target.
That’s the whole point of managed hosting and support: you shouldn’t have to read security advisories at 7am and wonder whether your shop is safe. Someone who knows their onions should already be on it.
Do our clients need to do anything?
No. If we host your site, the fix is already in place. You don’t need to change anything, restart anything or reply to anyone. If you’d like to check which PHP version your site is on, just ask and we’ll tell you.
What should other website owners do about PHP2Shell now?
If someone else hosts your site, or nobody in particular is looking after it, here’s a calm checklist.
- Check your PHP version. In WordPress, go to Tools > Site Health > Info > Server. Otherwise, ask your host or developer which version serves your site.
- Update to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. If you’re on 8.1 or older, ask your host whether their packages include a backported fix, and plan an upgrade to a supported version.
- Ask your host directly whether they’ve patched, and when. A good host will give you a straight answer.
- Make sure PHP was restarted. PHP’s guidance is to restart every worker after updating, so the patched version is actually the one running.
- Look for signs of compromise, especially if your server was unpatched for a while: unfamiliar PHP files (particularly in upload folders), new admin users, scheduled tasks you didn’t create and unexpected outgoing traffic.
- Rotate secrets if in doubt. Researchers say one of the flaws can also leak server memory, which might include passwords and API keys. If you can’t rule out exposure, change them.
PHP did publish temporary configuration changes to reduce some attack paths, but it’s clear that only updating is a complete fix. Treat those settings as a stopgap at most.
What’s the lesson for website owners?
Two things. First, old PHP is a real risk: sites on unsupported versions are the ones left without a straightforward fix. PHP 8.2 itself reaches end of life on 31 December 2026, so if you’re on it, now’s the time to plan.
Second, it’s worth knowing who’s responsible for patching your server. If the honest answer is “not sure”, that’s worth fixing. Our hosting, Magento support and website support plans all include keeping the server side current.
If you’re not sure where your site stands, get in touch for a no-obligation chat.
