PHP2Shell: Why Your Host Decides If You're Protected

Your server can be taken over without anyone touching your WordPress site. No malicious plugin, no compromised admin account, no brute-force login attempt — just a flaw in the PHP layer underneath and an attacker with the knowledge to use it. That is what the PHP2Shell vulnerability class exposed in October 2024, and it reframed a question that most business owners have never thought to ask: when a server-level flaw is disclosed, who is actually responsible for fixing it?

In most cases, the answer is not you. But whether it gets fixed at all, and how quickly, depends entirely on who hosts your site.

What PHP2Shell Actually Is, and Why WordPress Cannot Protect You

PHP is the programming language that runs WordPress. Every page your site generates, every database query it fires, every function a plugin calls — all of it runs through PHP on your server. PHP2Shell refers to a class of critical vulnerability in PHP itself that allows an attacker to execute arbitrary commands at the operating system level: read your database, deface your homepage, or execute commands on the server as if they were sitting at the terminal.

WordPress is simply not involved, and that is precisely why this matters so much to site owners. No WordPress security plugin, no firewall rule applied at the application layer, no plugin update will patch a flaw in the PHP binary running beneath it. The vulnerability exists in the infrastructure your site sits on, and fixing it requires the hosting provider to update PHP at the server level — a decision and an action entirely outside your control.

Unauthenticated exploitation is the specific risk that makes this category of vulnerability so serious. A specially crafted HTTP request can be enough; an attacker needs no login, no weak password to guess, no contact form to abuse. For a business running a WordPress site with any public-facing traffic — a WooCommerce store, a lead generation site, a client portal — the exposure is identical regardless of how carefully the WordPress installation itself has been maintained.

A large share of production WordPress sites run PHP versions that are either end-of-life or approaching it, which compounds the problem considerably. When a critical flaw is disclosed in a supported PHP version and a patch is released, sites on unsupported versions receive nothing. Upgrading PHP is the only path forward, and that upgrade carries its own risks: compatibility breaks with themes and plugins, functionality regressions, and the cost of testing and remediation. For many site owners on cheaper shared hosting, that work falls to them.

The Hosting Decision You Made Is Either Protecting You Right Now or It Is Not

This is where the incident becomes a practical lesson in the cost of hosting choices, rather than a theoretical security discussion.

On a managed WordPress host such as Kinsta, server-level vulnerabilities of this severity are patched at the infrastructure level, automatically, within hours of a fix being available. Customers are not notified in advance because there is nothing for them to do. The patch is applied, the risk is closed, and the site continues to run — that is the service model. The hosting provider takes responsibility for the server, and the site owner’s job is to run their business.

On self-managed hosting, a virtual private server, or lower-tier shared hosting, the site owner or their technical team must monitor PHP security disclosures, assess the risk, arrange a maintenance window, apply the patch, and verify the site still functions correctly afterwards. For a business without a dedicated technical resource, that chain of events either does not happen quickly enough or does not happen at all, leaving the site exposed in the window between disclosure and patching.

Some hosts apply web application firewall rules as a temporary measure when a vulnerability is disclosed before a patch is available. It is a reasonable interim step, but a firewall rule filters traffic based on known attack patterns; a sufficiently crafted request that falls outside those patterns passes straight through. The only reliable resolution is the PHP update itself, applied at the server level.

The practical question for any business executive reading this is whether they can get a clear, specific answer from their hosting provider: has the PHP binary on my server been updated to a patched version, and what version is it running now? A vague reassurance that security measures are in place is a different answer entirely. If your hosting provider cannot be specific, that tells you something about the level of infrastructure management you are paying for. Managed hosting costs more than unmanaged hosting for a reason, and that reason shows up most clearly in the hours after a critical server-level disclosure.

One consequence that often goes unexamined is business liability. If your site is compromised through a server-level vulnerability and customer data is exposed, the fact that the flaw was in PHP rather than in your WordPress configuration does not reduce your obligations under UK GDPR. The data was held on your infrastructure. The breach is yours to report, yours to manage, and yours to answer for. The hosting provider’s responsibility to patch does not transfer their liability to you, but it does not remove yours either.

If you are not certain which version of PHP your site is running, or whether your host has applied the patch, I can check that for you and give you a plain answer.

Contact me at The WordPress Guy to request a PHP version and patch status check for your site. Given that unauthenticated exploitation requires no login and no prior access, every day without a confirmed patch is a day of unmitigated exposure. I will tell you exactly where you stand.