The PHP2Shell Vulnerability Made Global News. Our Customers Never Saw the Fix.

On Wednesday 21 October 2026 the PHP project shipped emergency fixes for two flaws that let a stranger run their own code on a web server without logging in. The press named it the PHP2Shell vulnerability, and within hours it was on BleepingComputer, The Register, the NCSC's news page and NHS England's cyber alert service. PHP runs 69.2% of websites whose server-side language is known, so the coverage wasn't out of proportion.

If you host with 365i, here's the short version. Every affected PHP version we run was patched within hours of the news breaking. You didn't have to raise a ticket, change a setting, upgrade anything or restart anything, and we've had zero incidents reported. If this is the first you've heard of PHP2Shell, that's exactly how it's supposed to work.

I'd still rather you understood what happened than simply took our word for it. So here's the whole thing in plain English, including what people running their own servers had to do that afternoon and the parts of your site's security a PHP patch doesn't touch.

What Is the PHP2Shell Vulnerability?

PHP is the language underneath WordPress, WooCommerce, Joomla, Drupal and a huge share of the rest of the web. When someone visits your site, PHP on the server builds the page they see. PHP2Shell is the nickname for two bugs inside PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS v4 scale, which is critical.

Both bugs come down to how PHP tidies up after a request goes wrong:

• CVE-2026-109618, remote code execution via out-of-memory corruption. When PHP runs out of memory part-way through setting up a request, it jumps straight out. In some places it had already started building internal data it hadn't finished, and the clean-up code later trusted that half-built data as if it were real. Make PHP run out of memory at the right moment, with a carefully malformed file upload, and you can steer what the clean-up does.
• CVE-2026-109619, remote code execution via stale global state. A PHP worker serves one request after another. If a request ended badly, some of the worker's internal pointers could be left aimed at memory that had already been freed, and the next request to land on that worker could use them. Security people call this a use-after-free. It's one of the oldest routes to taking over a program.

The part that made it front-page news is in the official advisory's own words: the confirmed impact is "unauthenticated remote code execution as the web worker account". No password, no WordPress login, no vulnerable plugin required. Datadog's researchers, who reproduced it independently, wrote that "application-level authentication can't block an attack: PHP processes the malicious request before any application code runs."

That sentence is why your security plugin couldn't help. A login limiter, two-factor authentication, a WordPress firewall plugin: they all run inside WordPress, and WordPress hadn't started yet when the attack happened. Updating WordPress didn't fix it either. The hole was in the floor the house stands on.

How it came to light is a story of its own. According to the PHP Foundation, the security firm Calif reported the memory bug on 11 August while auditing PHP under OpenAI's Patch the Planet programme, and Wiz and OpenAI reported further attack routes in August and September. The fix was due on 22 October. Then the CVE numbers leaked onto forums on the afternoon of 20 October with the wrong severity score attached, so PHP brought the release forward to 14:00 UTC on the 21st.

Which PHP Versions and Websites Were at Risk

Every supported branch of PHP needed the fix, and so did every older one. These are the versions from the PHP security advisory:

PHP2Shell, the October 2026 PHP vulnerability: affected and fixed versions

PHP branch	Status	Fixed in
8.5	Supported, affected	8.5.12
8.4	Supported, affected	8.4.27
8.3	Supported, affected	8.3.36
8.2	Supported until 31 December 2026, affected	8.2.35
8.1, 8.0, 7.4	End of life, affected	Source backports, no release
7.3 and older	End of life, affected	Nothing from the PHP project

Every way of running PHP for the web was in scope: Apache with mod_php, PHP-FPM, php-cgi, LiteSpeed and FrankenPHP. The PHP project rated the risk "highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." For PHP-FPM, the advisory on the memory bug called an attack plausible but said no complete FPM exploit had been shown, while the stale-state bug was validated against both.

The numbers were big. Palo Alto Networks' Cortex Xpanse counted more than 22.6 million internet-exposed instances potentially vulnerable. W3Techs puts 26.7% of PHP websites on version 7 and 7.7% on version 5, so more than a third of the PHP web runs branches the PHP project no longer patches at all. Closer to home, NHS England's cyber alert said researchers had demonstrated working exploits "in products integrating PHP such as WordPress, Drupal, and Joomla" and assessed future exploitation as "highly likely".

What about actual attacks? This is where I'd urge a bit of calm, because the first 48 hours of reporting ran ahead of the evidence. Amazon's honeypots caught an attempt on 17 October, before the patches existed. Unit 42 later withdrew its claim that a European government intrusion had started through PHP2Shell. Elizabeth Barron, executive director of the PHP Foundation, told The Register: "We have no evidence of successful exploitation of the two vulnerabilities from Wednesday prior to disclosure." In the same piece, Mandiant's chief technology officer put the other side of it:

"Nonetheless, exploitation may have already begun in a limited fashion and the threat is viable and very serious."

Charles Carmakal, CTO, Mandiant, speaking to The Register, 23 October 2026

I like that sentence because it refuses both of the easy stories. It doesn't say the internet is on fire, and it doesn't say the whole thing was a false alarm. As of today the public record holds plenty of attempts and very little confirmed harm, but the exploit itself was real, published and working in labs. When a flaw is in that state, the only sensible move is to close it before the evidence catches up, because by the time a compromise is confirmed it's somebody's website. That's why "within hours" was the right speed, not an overreaction.

How 365i Patched PHP2Shell for Every Customer

Here's what happened on our platform, and I'll keep to what I can stand behind:

• Every affected PHP version we run was patched within hours of the news breaking.
• No customer had to do anything. No ticket to raise, no PHP version to change, nothing to restart.
• Zero incidents have been reported to us.

I'm not going to dress that up with a minute-by-minute timeline. You'd have no way to check it, and a security post that asks you to trust detail you can't verify has missed its own point.

The reason you didn't need to act is simple once you see where PHP lives. It isn't part of your website. It's part of the server your website runs on. On our managed WordPress hosting and web hosting, you choose a PHP version for each site in the My365i control panel, and the runtime underneath that choice is ours to maintain. When PHP needs patching, we patch the platform, and your site is fixed along with everyone else's.

There's one more detail I can give you, because it's published on our platform page: we run PHP through PHP-FPM, not Apache's mod_php. Under the advisory, that put us on the lower-risk side before a single patch landed. Lower risk isn't no risk, though, and it wasn't a reason to wait.

Speed mattered more than usual this time, because the gap between disclosure and exploit had shrunk to nothing. Amazon's threat intelligence team saw that 17 October attempt four days before the fixes were public. Its chief information security officer drew the lesson in his write-up:

"For critical vulnerabilities in internet-facing systems, measure patch and mitigation timelines in hours. A 7-day or 30-day SLA assumes a delay that no longer exists."

CJ Moses, CISO of Amazon Integrated Security, AWS Security Blog, 21 October 2026

Read his second sentence again, because plenty of business IT policies still say "critical patches within 30 days" and treat that as diligent. If you ran your own server on a monthly patch cycle, PHP2Shell sat open on it for weeks with a working exploit circulating. That isn't negligence by any normal standard. It's a process built for a slower world. The fix isn't working harder at it. It's handing the job to people for whom patching the server is the day's work, not an interruption to it.

What a Self-Managed Server Owner Had to Do on 21 October

If you run your own VPS, dedicated server or a cloud instance you set up yourself, PHP2Shell was your job. Here's roughly what that afternoon looked like on an Ubuntu server with PHP 8.3 under PHP-FPM:

# 1. Find the PHP that actually serves the site
#    (php -v only shows the command-line build)
php -v
ls /etc/php/
systemctl list-units --type=service | grep -i php

# 2. Pull the fixed packages
sudo apt update
sudo apt full-upgrade

# 3. Restart every PHP worker so the old code leaves memory
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx     # or: sudo systemctl restart apache2

# 4. Prove the fix landed, not just the version number
dpkg -l | grep php8.3-fpm
zgrep -m1 "CVE-2026-10961" /usr/share/doc/php8.3-common/changelog.Debian.gz

# The same job on AlmaLinux or RHEL with the Remi packages
sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm
rpm -q --changelog php-fpm | grep -m1 "CVE-2026-10961"

Two traps caught people out that day. First, php -v reports the command-line PHP, which isn't always the build serving your pages. Second, Ubuntu, Debian, Red Hat and CloudLinux often backport security fixes without changing the version number, so a fully patched server can still report an old-looking version. That's why step 4 checks the package changelog for the CVE rather than comparing numbers with php.net.

Then there's everything the code block doesn't show: testing that the site still works after the restart, doing it all again on every other server, and coming back two days later when PHP published a follow-up. It isn't hard if you live in a terminal. It's an afternoon nobody planned, it has to be right first time, and on that afternoon a mistake leaves the door open.

We're upfront about this with our own products. When we built a product on one of our own unmanaged VPS plans, patching that machine was our job, not the platform's. Our VPS hosting is the right choice when you need root access, and the wrong one if you'd rather somebody else handled days like 21 October.

What a PHP Patch Doesn't Cover

I'd be doing you a disservice if this post left you thinking a patched PHP makes a website safe. It closes one door, an important one. These are the others:

• Plugins and themes. They're a separate layer with their own security updates. When the Avada Builder SQL injection landed in May, the fix was a plugin update, and plugin updates are still decided inside WordPress. Weeks like the one where WordPress shipped three security patches in 24 hours are the norm, not the exception. Our sister studio tracked 661 WordPress vulnerabilities in a single week earlier this year.
• Passwords and logins. A shared admin password or an old account belonging to a former developer is a risk no server patch can fix. Two-factor authentication helps.
• Your own custom code. If a developer wrote PHP for your site, a patched PHP runs their code faithfully, bugs and all.
• Anything already planted. The NCSC's PHP2Shell alert told organisations that couldn't patch straight away to look for signs of compromise and backdoors. A patch closes the hole. It doesn't evict anyone who got in before. Our shared hosting platforms are scanned daily for common malware, which is one more layer, not a replacement for keeping the others tidy.
• An unmanaged server. If you run your own VPS, everything above the operating system is yours, PHP included.

One more thing for completeness. On 23 October PHP published an informational advisory for a third issue, CVE-2026-115560. It only affects applications with an unusual combination of session settings, and Barron told The Register it "requires a very unlikely combination of configuration and specific PHP application code, which we do not expect to occur in practical use of PHP." PHP's interim advice is to set session.upload_progress.enabled=0 until its next regular release. That's a server setting, so on shared hosting it sits with your host. On your own server it goes in php.ini or the FPM pool, followed by a restart of every worker.

If you'd like a quick look at the layers you do control, our guide to checking your WordPress site's security in 30 seconds walks through it, and our free WordPress Scanner checks for exposed logins, version leaks and debug output. Press Forge keeps a WordPress security checklist for small businesses that covers the rest.

How to Check Which PHP Version Your Site Runs

1. On 365i: sign in to the My365i control panel and open the PHP settings for the site. The version is set per website, so check each one if you have several.
2. In WordPress: go to Tools, then Site Health, then the Info tab, and open the Server section. The PHP version is listed there.
3. Anywhere else: ask your host, in writing, whether its PHP builds include the fixes for CVE-2026-109618 and CVE-2026-109619. Because of backports, a version number alone won't settle it.

The version matters even when somebody else does the patching. In January a customer's Elementor site threw a fatal error after a WordPress update. We fixed it in about 35 minutes and didn't charge, but the real finding was underneath: the site was still on PHP 7.4.33, a branch that had been out of support for more than three years. Nobody had changed it because nothing had forced them to.

PHP2Shell is that forcing moment. When a flaw like this lands, the PHP project fixes supported branches and leaves older ones to whoever is willing to backport, and even a good backport for an end-of-life branch is a favour rather than a promise. If your site is on PHP 8.1 or older, it's time to move up. PHP 8.2 reaches end of life on 31 December 2026, so if you're moving anyway, aim for 8.3 or newer. We wrote about the risks of staying behind when PHP 8.1 reached end of life. Test the change on a staging copy first. A one-click staging site takes most of the nerves out of it.

Managed Hosting: Why the Best Security News Is No News

Hosting companies love a dramatic incident write-up. All hands on deck, midnight war room, heroic engineers. I understand the appeal, but I think it sells the wrong thing. The real test of managed hosting is how boring a day like 21 October was for you.

The UK's National Cyber Security Centre made this argument years before PHP2Shell, in its guidance on what a good cloud service should do for its customers:

"Prompt deployment of security fixes (also called patching) remains the single most important thing you can do to secure your technology."

National Cyber Security Centre, Security benefits of a good cloud service

Notice the ranking in that sentence: "the single most important thing". Not the firewall, not the clever monitoring, not the security plugin with the reassuring dashboard. Prompt patching. And the most valuable security work is also the least visible. Nobody leaves a review saying their website didn't get hacked on Wednesday. Nobody notices the restart that happened at the platform level instead of on their own laptop.

We saw the same shape when WordPress 7.0 shipped in May. Hundreds of sites on our platform upgraded, and we had zero tickets, zero rollbacks and zero white screens. That's what a well-run platform feels like from the outside: nothing. PHP2Shell was the security version of the same day. It's also the part of hosting that never shows up on a price comparison, which is the argument we make in the hidden costs of cheap hosting.

So if PHP2Shell passed you by, I'd take that as good news. It means the system worked. If you want the same for a site that's hosted somewhere else, the useful question to ask any host isn't "do you take security seriously?" Everyone says yes. Ask what they did on 21 October, and how long it took.

Frequently Asked Questions