PHP2Shell: How We Patched Thousands of Servers Overnight

On October 21, 2026, the PHP project released fixes for two critical flaws in the language’s core, collectively known as PHP2Shell. Less than eight hours later, most of our servers were running patched versions of PHP. By the following morning, the rest had caught up.

For most of our customers, the whole episode required no action at all.

Two days later, the PHP project disclosed a third, separate vulnerability that’s still waiting for a fix. We’ve already applied the recommended mitigation on our servers, so that one doesn’t need any action from you either.

Here’s how serious PHP2Shell is, how our team handled both disclosures, and the one scenario where you still need to step in.

What Is PHP2Shell?

PHP2Shell is the name for two vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619. Both let a remote attacker run their own code on a vulnerable server without logging in, and the PHP security team rated each one 9.2 on the CVSS v4.0 scale.

The first is a memory corruption bug triggered when PHP runs out of memory partway through processing a request. The second is a use-after-free flaw, where leftover data from one request points to memory that a later request can abuse. You don’t need to follow the mechanics to understand the outcome: an attacker who exploits either flaw can take control of the affected website.

Three things set PHP2Shell apart from a typical security bulletin:

• The flaw is in PHP itself, not in your code. A fully updated WordPress site with a clean plugin list is as exposed as a neglected one, because the vulnerable code runs underneath every application. Updating WordPress or Laravel doesn’t change the PHP version that serves the requests.
• It reaches back more than a decade. Nearly every PHP release since version 5.4 is affected, across all the common ways servers run PHP, including PHP-FPM, Apache’s mod_php, and LiteSpeed.
• Attackers moved before the patch did. Amazon’s threat intelligence team spotted an exploitation attempt on October 17, four days before public disclosure, and security firm watchTowr reported active exploitation attempts shortly after the fixes went out.

The fixes didn’t arrive evenly, either. The PHP project shipped official releases only for the branches it still supports: 8.2.35, 8.3.36, 8.4.27, and 8.5.12. For PHP 7.4 through 8.1, which have reached end of life, it published source code backports but no official releases. Anything older than 7.4 received nothing.

That gap is where a hosting provider’s response matters most. Plenty of legitimate websites still run on older PHP versions, and whether they got patched depended entirely on who maintained their servers.

Rolling Out the Fix Across Our Infrastructure

Word of the vulnerabilities leaked on October 20, a day before the PHP project’s out-of-cycle release. At that point, nobody outside the PHP security team knew which versions were affected.

Once the PHP project published its advisory at 14:00 UTC on October 21, the picture became clear. Patched builds were available for every version from PHP 7.4 upward, so we could protect the vast majority of sites without changing anyone’s PHP version.

Our team started installing the security updates on all our servers (both managed and self-managed). The updates apply automatically, without interrupting the websites running on them. While the rollout was underway, we emailed our customers and the companies that run SPanel on their own infrastructure, explaining what PHP2Shell is and whether they needed to act.

When the whole internet updates at once

There was one obstacle no amount of preparation could prevent. Hosting providers and system administrators around the world were downloading the same patched packages at the same moment, and the main package repository buckled under the load. Requests kept timing out, and the mirror servers that normally share the traffic hadn’t synced the new packages yet.

Waiting in line wasn’t an option, so we got creative. One of our engineers set up a dedicated caching server in our European data center that downloaded each patched package from the main repository once and stored it. Our servers then pulled the updates from that cache instead of competing with the rest of the world for the overloaded source.

The result? Thousands of servers were patched in less than eight hours. Overnight and into the morning of October 22, our team tracked down the servers where the first pass hadn’t gone through, including a small batch of cPanel servers, and updated those too.

A Follow-Up Advisory: CVE-2026-115560

On October 23, the PHP project published an informational advisory about a third vulnerability, CVE-2026-115560. It’s separate from PHP2Shell, and the October 21 releases don’t fix it. Instead of shipping another emergency patch, the PHP project will fix it in its next regular release.

The reason for the slower timeline is that this flaw is much harder to reach. An attacker can only use it to run code when an application combines an unusual session configuration with code that changes that configuration while it runs, and only while a PHP feature called session upload progress is switched on. The PHP project considers that combination unlikely in practice, and no exploitation had been reported when the advisory came out.

Unlikely isn’t the same as impossible, though. With thousands of different applications running on our servers, we didn’t want to bet on every one of them avoiding that combination. So we followed the PHP project’s recommendation and disabled session upload progress (the session.upload_progress.enabled setting) on all our servers. The same change was already listed as a mitigation for CVE-2026-109619, one of the PHP2Shell flaws, so it adds a second layer of protection there too.

Files still upload normally. The setting only controls PHP’s built-in tracking of how far an upload has progressed, so the most you might notice is an upload progress bar that no longer moves in an application that relies on this feature.

Our Support Team Kept Pace

A vulnerability with a catchy name and a 9.2 severity score makes headlines, and headlines make website owners understandably nervous. In the aftermath of the disclosure, tickets and live chats about PHP2Shell kept pouring in.

Our support team worked through the night shift, and senior engineers joined in the following day. Instead of pointing customers to a general status update, the team checked each customer’s server individually whenever someone reached out, so every answer reflected that specific server’s state.

Do You Need to Do Anything?

If your websites run PHP 7.4 or newer on a ScalaHosting server, no. Your sites already run patched versions of PHP, and there’s nothing to change. The same goes for CVE-2026-115560: the mitigation is already active on our servers, and we’ll install the PHP project’s fix once it’s released. If you manage custom PHP settings for your sites, leave session upload progress turned off until then.

If any of your sites still use PHP 7.3 or older, including PHP 5.6, switch them to at least PHP 7.4 as soon as possible. No patch exists for those versions, so no update from our side can protect them. In SPanel, open PHP Manager, pick the domain from the list, and select the new version. Older applications don’t always work on a newer PHP release right away, so if you’re unsure, our support team can help you check compatibility before you switch.

One more recommendation, even though it isn’t urgent. PHP 7.4 through 8.1 are now patched against PHP2Shell, but they’re past end of life, so the PHP project won’t fix the next vulnerability in those branches. PHP 8.2 joins them on December 31, 2026. Planning a move to PHP 8.3 or newer now saves you from repeating this exercise under pressure.

Security Starts Below Your Code

PHP2Shell is a reminder that a website’s security doesn’t end with its own code. The runtime underneath it, the servers it runs on, and the people maintaining them matter just as much, especially on the night a critical flaw goes public. And as the follow-up advisory showed, the work doesn’t always end when the patch lands. It’s the same principle behind how we secure our cloud infrastructure day to day.

If you’d rather have that layer handled for you, managed cloud VPS hosting puts patching, monitoring, and a support team that works through the night on our side of the table.

PHP2Shell FAQ

Q: Is my website on ScalaHosting affected by PHP2Shell?

A: If your site runs PHP 7.4 or newer, it’s already protected. We installed patched PHP builds on every server we manage, so no action is needed on your side. Sites on PHP 7.3 or older remain vulnerable until you switch them to a newer version.

Q: Which PHP versions fix PHP2Shell?

A: The PHP project fixed the flaws in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 7.4 through 8.1 received source code backports rather than official releases, and our servers run patched builds of those versions as well. No fix exists for PHP 7.3 or older.

Q: Is CVE-2026-115560 part of PHP2Shell?

A: No. CVE-2026-115560 is a separate vulnerability the PHP project disclosed on October 23. It only affects applications with an unusual session configuration, and the PHP project will fix it in its next regular release. We’ve already disabled session upload progress on our servers, which is the recommended mitigation, so no action is needed on your side.

Q: How do I check which PHP version my website uses?

A: In SPanel, open PHP Manager to see and change the PHP version for each domain on your account. Each domain or document root can run its own version, so check every site you host, not just the main one.

Q: Do I need to update WordPress or my plugins to fix PHP2Shell?

A: No. PHP2Shell is a flaw in the PHP runtime, so updating WordPress, a theme, or a plugin doesn’t affect it. Only a patched PHP version closes the hole, although keeping your applications updated is still good practice.

Q: What should I do if I think my site was compromised?

A: Contact our support team right away. Signs worth reporting include unfamiliar files in your website’s folders, cron jobs or user accounts you didn’t create, and unexplained errors or slowdowns. Our team can inspect the server and help you clean up and restore from a backup if needed.