PHP2Shell: Why Websites Went Offline and What It Taught Me

If a website you rely on was down or showing a maintenance page yesterday, there is a good chance PHP2Shell was the reason. Two serious flaws in PHP, the language behind a huge share of the web, were disclosed and fixed on Wednesday 21 October, and hosting providers rushed to apply the patches. Some took sites offline while they did it.

I look after websites for clients, so I spent a good part of the day watching this unfold. Here is a plain English account of what happened, followed by what I think we should take from it.

In this article

• What happened
• What PHP2Shell actually is
• Why some sites were taken offline
• Does downtime mean a site was hacked?
• What to ask your hosting provider
• Reflections
• Need a hand with your website?
• Sources

What happened

On 21 October the PHP project released emergency security updates for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Security researchers nicknamed the pair “PHP2Shell”. Both are rated 9.2 out of 10 for severity, and both can be used by someone with no login at all.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosting companies, who run PHP on behalf of millions of websites, then had to work out how quickly they could get those versions onto their servers.

What PHP2Shell actually is

PHP is the software that builds pages on the server before they reach your browser. WordPress, Joomla, Drupal and a great many bespoke sites all run on it. A flaw in PHP itself is different from a flaw in a plugin, because it sits underneath everything.

In simple terms, both bugs are memory handling mistakes. One involves how PHP cleans up when a request runs out of memory. The other involves old data from one request being reused after it should have been thrown away. Either could allow an attacker to run their own code on the server, with the same permissions as the website.

The part that worried people most is that, in some server set-ups, a malicious request can trigger the problem before your website’s own code has even started. That means a well-maintained site with a tidy set of plugins is not automatically protected. The fix has to happen at server level.

Attacks were reported quickly. Amazon’s threat intelligence team said it saw an attempt against its test systems on 17 October, before the flaws were public, and more on the day of disclosure. Cloudflare also reported early attacks, and added firewall rules to help, although it described those as a stopgap rather than a cure.

Why some sites were taken offline

If a patch cannot be applied straight away and attacks are already under way, a host has a hard choice. Leave the sites running and accept the risk, or switch some of them off until the server is updated. Some chose the second option, and visitors saw maintenance pages while the updates were installed.

I think that is a defensible call. A few hours of downtime is annoying but recoverable. A server taken over by an attacker, with customer data exposed or a backdoor hidden in the files, can take weeks to put right.

It is worth knowing that the guidance from CERT-EU was along the same lines: identify your PHP applications, patch quickly, and if you cannot, isolate them from the public internet until you can.

Does downtime mean a site was hacked?

No. A maintenance page is much more likely to mean the host was being careful. If you visit a site that was briefly unavailable, you do not need to do anything on your own device.

That said, it is sensible to stay alert for a few days. Unexpected redirects, strange downloads, odd pop ups or repeated requests to log in again are all reasons to close the page.

What to ask your hosting provider

If you have a website, a short message to your host is worthwhile. Ask them:

1. Has the fixed PHP version been installed, or only scheduled? There is a big difference.
2. Does that cover every site and application on my account? Old staging copies and forgotten subdomains count too.
3. Which PHP version is my site running? If it is 8.1 or older, the PHP project no longer issues routine security updates for it. Only minimal backports have been published, so you need your vendor’s confirmation or an upgrade.
4. Have you seen any sign of a compromise on my account?

One common misunderstanding is worth flagging. Updating WordPress or its plugins does not update PHP. They are separate things, and this particular fix lives in PHP.

Reflections

A few things stood out to me from the past 24 hours.

Updates are not optional housekeeping. The gap between a vulnerability being disclosed and attackers using it is now measured in hours, and in this case an attempt was seen days before the public announcement. A patching routine that works on a monthly rhythm is no longer enough for the serious ones.

Your hosting is part of your security. It is easy to treat hosting as a commodity and pick the cheapest option. Yesterday was a reminder that the quality of a host shows up on the bad days: how fast they patch, how clearly they communicate, and whether they are willing to take a site down to protect it. I would rather work with a host that is quick and upfront than one that stays quiet.

Old PHP versions are a debt that comes due. Anything on PHP 8.1 or earlier is outside normal support. PHP 8.2 reaches the end of its security support at the end of this year, so it is time to plan upgrades now rather than in a rush. I have been working through this with my own clients, and it is much calmer when it is planned.

Stay calm and check the facts. Early reports of any incident contain mistakes. Some early listings of these flaws gave a score of 10, which the PHP team later said was wrong. It is not yet clear how many servers were affected or how many compromises there have been. I would be wary of anyone claiming certainty about that this early.

Layers matter. A firewall in front of your site, regular backups, limited file permissions and prompt updates each make a bad day less bad. None of them replaces patching, but together they buy you time.

Keep it simple. Fewer plugins, fewer old copies of sites and fewer forgotten servers mean fewer things to patch. The static sites I build on Astro and Cloudflare do not run PHP at all, which is one reason I like them. For clients who need PHP, I keep it patched and up to date.

Need a hand with your website?

If you are not sure which PHP version your site uses, or you would like a second opinion on whether your hosting is keeping up, I am happy to take a look. No jargon, no hard sell, and I will tell you plainly what is worth doing.

Take a look at my website packages, or get in touch on 07859 925 041 or hello@darrenhodson.co.uk.

Sources

• PHP2Shell: Why websites are going offline for emergency security updates, Malwarebytes
• php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ, Tenable
• php2shell: Critical PHP RCE (CVE-2026-109618 and CVE-2026-109619), Intruder
• Security advisory: Critical unauthenticated RCE in PHP (“php2shell”), University of Toronto