PHP2Shell: How Web Hosts Worldwide Responded in 48 Hours

PHP2Shell is a pair of critical remote code execution flaws in PHP itself, which means your exposure depends heavily on who runs your server. And that makes the boundary of responsibility unusually important. The PHP project fixed them in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 and says updating is the only safe choice. Some hosts patched on behalf of customers within hours. Others shipped packages or a guide and left the update to you. This post covers the bugs briefly, a UTC timeline, a provider by provider table taken from each host's own announcement, the control panel layer, and a plain list of who must act. Everything is as of 22 October 2026.

What PHP2Shell is, in plain terms

There are two bugs, both in PHP core. Both are rated CVSS v4.0 9.2 (Critical) in the PHP security team's pre-announcement, which is about as clear a signal as administrators should need.

• CVE-2026-109618 is remote code execution via out-of-memory corruption. Per the PHP Foundation, if a request hits PHP's memory limit at exactly the wrong moment, PHP can leave half-initialised internal data behind and later treat it as valid. On Apache with mod_php, an unauthenticated request can trigger it before any application code runs.
• CVE-2026-109619 is remote code execution via stale global state. A fatal error can leave internal state pointing at memory from a previous request, and a later request in the same worker can use that freed memory. That is a use-after-free.

The release email for PHP 8.3.36, sent at 14:00:57 UTC on 21 October, puts it bluntly: "There are no complete mitigations, updating is the only safe choice." That line is doing real work here.

This is the part that trips people up. The flaw is in the PHP runtime, not in your CMS. Cloudflare is explicit that updating website code or plugins alone does not fix it, and that if a hosting provider manages PHP, you should ask them to apply the update. So updating WordPress, a theme or a plugin does nothing here. Cloudflare says PHP is used by almost 70% of websites; Krebs on Security puts it at nearly 70 percent. That is why the hosting layer matters more than usual.

Help Net Security reports that every PHP installation serving web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php setups facing the greatest danger. That breadth is what makes this a hosting problem, not just an application problem.

The timeline, in UTC

The disclosure did not go to plan. The Foundation says the CVE IDs began circulating on forums and social media around 15:00 UTC on 20 October, with a wrong release time and a wrong CVSS score of 10.0. That forced the schedule forward. Timestamps below are from each source; where a source gives a rounded time, I say so, because precision matters when patches and exploits are moving this quickly.

Two things stand out. Cloudflare's rules were live roughly nine hours before the patch existed. And Amazon says that once the embargo lifted, more proof-of-concept exploits appeared within hours and PHP2Shell is now being broadly exploited in the wild. The Foundation's own account is a little more cautious: its security team did not identify any functional exploits at the time of release. Sources differ on that, so treat it as a fast-moving picture rather than a settled record.

A window of a day or less between public fixes and public exploits is the real story for the hosting layer. A host that needs two weeks to roll packages is a host whose customers sit exposed for two weeks. That is not a process quirk, it is the risk.

How the hosting layer responded, provider by provider

The table below reports only what each provider published, as of 22 October 2026. It is not a ranking, and it says nothing about any provider's current state beyond its own post. Statuses can change, so open the linked announcement before you rely on a row. Treat the table as a trail of public statements, not a live assurance.

AWS sits slightly apart. Its bulletin 2026-143-AWS says AWS services are not impacted, but customers running affected PHP versions inside listed services could be, and no cross-customer propagation has been established to date. Its mitigation guidance includes an AWS WAF custom rule named PHP2Shell. But the responsibility still depends on where PHP is actually running.

Three different kinds of response

Read the table and you see three patterns, not one.

1. Patch it for you. Cloudways WordPress instances, supported App Engine runtimes, Hetzner's managed products. You do nothing, ideally after confirming.
2. Ship the packages, you apply them. Hetzner's dedicated and cloud customers, Droplets, OVHcloud VPS. The provider may have given you a guide or an email, but the server is yours.
3. Block first, patch after. Hostinger's ModSecurity rules, Cloudflare's WAF. Useful, fast, and explicitly not the finish line.

Hetzner's timeline is worth a second look. It applied the mitigations PHP recommended before the release, then had PHP 7.4 and 8.0 through 8.5 patched across Webhosting and Managed Servers by 17:50 UTC, under four hours after the 14:00 UTC release. That is Hetzner's own account, dated, and I would rather you read it than take my summary. The timing is the point.

The control panel and tooling layer

Most small and mid-sized hosts do not build PHP themselves. They install it through a control panel vendor's packages, so their patch speed is capped by what the vendor ships. If cPanel or Plesk has not published the build, a perfectly competent host has nothing to install. That dependency chain is easy to miss until a day like this.

• cPanel released updated ea-php74 and above, per its support article. Hosts then have to pull those packages and restart services.
• Plesk rebuilt PHP 8.2 to 8.5 for Linux and Windows. It also shipped fixed builds of end-of-life 7.4.33, 8.0.30 and 8.1.34 with the same version number but a 21 October build date, per its advisory. That detail matters: the version string looks unchanged, so you cannot tell by eye alone.
• CloudLinux tracked its alt-php and ea-php packages on a status page, and says its Imunify360 ModSecurity ruleset 8.83 blocks the public exploit shape.
• Laravel Forge says its automatic security updates do not patch PHP, so customers must update each server themselves, per the Forge knowledge base.

Forge is the instructive one. "Automatic security updates" sounds reassuring, and for a lot of OS packages it is. For PHP on a provisioned server it is not, and you only find that out by reading the notice. The label does less work than people assume.

One more wrinkle from Help Net Security: users of the volunteer-maintained rpms.remirepo.net repository were advised to switch to distribution packages or build from source, because that repository would not have updates on 21 October. If your own server pulls PHP from a third-party repo, check what that repo says. And check it directly, not through habit.

If you are choosing a host and care about this, our list of cPanel hosting providers is a reasonable place to start comparing panel-based plans. The panel is not the whole story, but it is often where the PHP package story begins.

Managed or self-managed: who has to act

The single most useful question is: who has root on the box? If it is you, the patch is yours.

Decision list

• Shared hosting: the host patches PHP. Confirm with their status page or email.
• Managed hosting (managed WordPress, managed servers, platform runtimes the host maintains): the host patches PHP. Confirm it.
• VPS and dedicated servers: you patch, unless you pay for a managed tier that explicitly covers PHP.
• Cloud servers and Droplets: you patch.
• Forge-style provisioned servers: you patch, per Forge's own notice.
• Containers, Cloud Run, Kubernetes, App Platform: you rebuild and redeploy.
• Marketplace and 1-Click images already deployed: you patch. Delisting an image stops new installs, not the ones already running.

A managed host patching PHP for you is the whole point of paying more. If you are on a plan where you are the sysadmin and would rather not be, managed WordPress hosting moves that job to the provider. So make sure the plan really includes that work, not just friendly wording around it.

Firewalls buy time

Cloudflare, Imunify360 and ModSecurity rules help. Cloudflare calls its protections defence-in-depth and tells customers to patch PHP anyway, and paid-plan customers (Professional, Business, Enterprise) should confirm the Managed Ruleset is deployed in block mode. The PHP project says there are no complete mitigations. Both point the same way: a rule in front of PHP is a delay, not a fix.

The UK NCSC, as reported by Help Net Security, urged organisations to patch PHP systems immediately and to consider taking offline any system that cannot be fixed right away. That is the sharp end of the advice. It is also the part nobody enjoys applying.

The end-of-life gap

The PHP project is not releasing fixes for PHP 8.1 or earlier. According to Help Net Security, the security team did release minimal source backports for PHP 7.4, 8.0 and 8.1, meant for people who build from source or lack an LTS vendor. That is not a package you simply install from a dashboard. But it is a clear hint about who is expected to know what they are doing.

Some providers are filling the gap themselves, in their own words:

• Plesk's rebuilt 7.4.33, 8.0.30 and 8.1.34 builds.
• Hetzner patching PHP 7.4 and 8.0 on Webhosting and Managed Servers.
• Hostinger saying sites on 8.1 and older are covered on its managed hosting.
• TuxCare, which says its Endless Lifecycle Support for Runtimes is rolling out fixed builds for end-of-life branches.

That is useful if you are on one of those plans. It is no help if you run an old PHP on a VPS you set up years ago and forgot. Nobody is backporting for you there. And silence from the server is not the same thing as safety.

How big is that group? Counts vary by scanner, and they are banners, not confirmed-vulnerable systems:

• Picus reports one rapid-response scan counting roughly 884,000 internet-facing hosts reporting PHP 8.1 or older on 20 October, about 59% of the roughly 1.5 million that reported any version.
• Recorded Future cites VirusTotal data: about 1.1 million of about 5.1 million PHP-running IP addresses disclose a version, and among those about 758,000 run an end-of-life branch (5.4 to 8.1) against about 272,000 on a supported branch.

Note the other half of that figure: most servers do not disclose a version at all. You can peek at your own response headers with our HTTP header checker, though a hidden X-Powered-By header tells you nothing either way. It is not a patch check. At best, it is one small clue.

So if you manage your own server and sit on an end-of-life branch, move to PHP 8.2 or newer. Our WordPress PHP version guide covers the compatibility side for WordPress sites, and the PHP hosting list is there if the move means changing host. The security decision comes first, then the tidy-up.

What to do today

Here is a checklist, in order.

1. Confirm your PHP version. On a server, run php -v. In WordPress, go to Tools > Site Health > Info > Server. Note that the command line can differ from the version your site actually uses (Picus warns of a workstation showing a patched build while the PHP-FPM pool serving production runs another binary), so check what the web process runs.
2. Find out whether your host patches PHP for you. Look at their status page, security announcement or customer email. Use the table above as a pointer to where each provider published, not as proof of your own plan's state.
3. Back up first. GoDaddy's guidance says so, and it is right.
4. If you manage the server, update. Install a fixed version (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package), restart PHP-FPM or Apache, and check the version again. TuxCare notes every PHP worker needs a restart after updating. For Plesk's rebuilt end-of-life builds, remember the version number does not change.
5. If you cannot update yet, apply interim steps. Disable session.upload_progress as your host or PHP recommends, and keep WAF rules switched on. These reduce risk. They do not close it.
6. Containers and cloud runtimes: rebuild and redeploy. Updating the host OS does nothing for an image you have already built.

Frequently Asked Questions

Does updating WordPress fix PHP2Shell?

No. The flaws are in the PHP runtime. Cloudflare says updating website code or plugins alone does not fix them. Only a patched PHP, or a host that applies it, does. Everything else is surrounding activity.

Is Cloudflare's WAF enough if I cannot patch today?

It helps, and Cloudflare says protections were on by default for free and paid plans from 21 October 03:02 UTC. But Cloudflare itself tells customers to patch PHP regardless. Treat it as time bought, not risk removed.

My site is on PHP 7.4. Am I safe if my host says it patched?

It depends on what the host published for your plan. Plesk, Hetzner, Hostinger and TuxCare each describe their own end-of-life coverage. Read the specific notice, and plan a move to PHP 8.2 or newer. The exception may keep you running, but it should not become the plan.

Why does the version number look the same after patching?

Plesk says its fixed 7.4.33, 8.0.30 and 8.1.34 builds keep the same version number with a 21 October build date. Check the build information the vendor documents, not only the number. A matching version string can hide the part you actually need to verify.

What this says about choosing a host

The sharpest fact in all this is the split: on a host that maintains PHP, the patch arrives without you; on a server where you hold root, nothing happens until you act, and firewalls only delay the problem. Before you buy any plan, check in writing who updates PHP on it. That answer matters more than the marketing copy.