PHP2Shell: A Look Back at Our Work

In this article, we will be looking back at our response to what history will surely long remember as “the two PHP2Shell vulnerabilities”.

We will begin by providing some general information about PlanetHoster’s response and explaining why our customers do not have to worry. Afterwards, those familiar with the more technical aspects can consult the details that may be of interest to them.

PlanetHoster’s Response

As we all know, the Web never ceases to spring surprises on us. We saw a striking example of this very recently – on 20 October, to be precise. Had it not been for PlanetHoster’s caution and sense of responsibility towards its customers, the consequences could have been disastrous.

Fortunately, absolutely nothing untoward happened.

PlanetHoster, ever reliable, has been there for you over the last few days, providing 100 per cent support. See for yourselves.

A Look Back: What Happened?

On 20 October 2026, the PHP security team announced to the world that an emergency release would be issued the following day, 21 October at 14:00 UTC, to fix two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619, rated 9.2 on the CVSS v4.0 scale¹.

A name soon became the talk of the town when referring to them: PHP2Shell.

Unfortunately, the technical details were leaked before the announced patch was released. The vulnerabilities affect session.upload_progress, a core PHP function enabled by default. These vulnerabilities allowed remote code execution, without authentication, on any website that accepts a multipart form². In other words, any file-upload form became a point of entry.

As early as the morning of 21 October, attempts to exploit the vulnerabilities were observed on the Internet, even before the patch existed. For a Web host like PlanetHoster, this is the worst possible scenario: everyone knows how to attack, and no one yet has the means to defend themselves. To draw an analogy, the hosting provider may feel like the occupant of a fortress surrounded by enemies whose numbers and strength are unknown.

In situations like this, it is vital not to panic. You must keep a cool head. And take action. That is what we did.

We Did Not Have to Wait Long For A Reply…

The best thing is to take a preventative approach. Prevention is better than cure.

It was clear that malicious actors would act very quickly. Consequently, we did not wait for PHP’s patch. Protective measures were put in place before the patch was released. What is more, they were only lifted after verification, server by server.

HybridCloud N0C Made All The Difference

On N0C, no accounts needed to change their PHP version; on cPanel, accounts running 7.4 had to be migrated. Later on, we will see that the reason for this lies in three technologies included in N0C, at no extra licence cost.

So, Is There Anything I Need To Do Now?

No, our customers can rest assured. No action is required on their part.

Please note that PlanetHoster has deployed the patches and they have been verified. Our systems continue to carry out updates around the clock in parallel.

Should an error be found on a form, we would ask our customers to contact our support team.

For those using HybridCloud cPanel with a customised configuration or who are running a version of PHP earlier than 7.4, our technicians can assess what is possible or assist them with a migration to HybridCloud N0C. Free of charge. There, they will find their version of PHP, which is maintained, along with the live kernel patch and project isolation as an added bonus.

Details…

For those of our readers with the relevant technical knowledge, we offer further details here which we hope will be of interest.

• We shall begin by analysing our counter-attack in detail.
• We shall revisit some key events.
• We shall explain the three technologies that account for why HybridCloud N0C made all the difference.

Our Response, Hour By Hour

As mentioned above, the protective measures were in place before the patch was released and were only lifted after verification had been carried out on a server-by-server basis.

Here is what we did (Montreal times).

Key Events

Here are a few key points to bear in mind.

Protected before the patch, not after. The protective measures were active before the patch was released, and therefore before the first attempts to exploit the vulnerability. The sites remained online throughout the operation.

The version number does not tell the whole story. On cPanel, the patches were backported into existing packages. In other words, ea-php74 remains at 7.4.33 whilst ea-php85 remains at 8.5.11, even though they both contain the two patches. This is why our checks focus on the contents of the packages, not on the displayed version number. A simple php -v proves nothing.

No protection removal without verification. Protection was only removed from a server once all its PHP packages had been analysed and cross-checked against the two CVEs. The risk to avoid: patching, removing protection, then seeing a customer switch to an unpatched version and become compromised as a result.

All versions, not just the recent ones. PHP has only patched branches 8.2 to 8.5. On HybridCloud N0C and The World, our versions 5.2 to 5.6, 7.0 to 7.4 and 8.0 to 8.5 have all received the patches thanks to our long-term support. On cPanel, excluding CloudLinux, versions prior to 7.4 are no longer patched: affected accounts have been migrated to 7.4.

PHP 4.4 and 5.1 are being phased out. Some servers still included these two versions in their range, to ensure maximum compatibility. They have received backported patches for years, but have now been withdrawn.

Node.js too. At the same time, patches for CVE-2026-111497 (Node2Shell) have been deployed across all our servers.

Why Did HybridCloud N0C Make The Difference?

We have already noted that this incident highlighted a practical difference between our infrastructures, as on N0C no accounts needed to change their PHP version, whilst on cPanel, accounts running version 7.4 had to be migrated. The reason for this lies in three technologies native to N0C.

On cPanel (excluding CloudLinux), PHP versions prior to 7.4 no longer receive patches. This is exactly the sort of constraint that N0C’s long-term support eliminates: you choose the version your application needs and we take care of keeping it secure.

Follow-Up

The full announcement and update history remain available at php21oct.planethoster.live.

1. CVSS v4.0 (Common Vulnerability Scoring System version 4.0) is an open and universal standard, managed by FIRST.Org. It enables the severity of IT security vulnerabilities to be assessed, measured and communicated objectively. ↩︎
2. A multipart/form-data is an HTTP content type that allows mixed data (text and files or binary content) to be sent in a single HTTP request. ↩︎ ↩︎