PHP Vulnerabilities: Why Your Hosting Setup Matters

Two near-maximum-severity vulnerabilities in PHP were actively exploited in the wild before patches existed. Rated 9.2 out of 10 on the Common Vulnerability Scoring System, both flaws allowed attackers to execute malicious code on web servers without any login, credentials, or prior access. The attack surface was PHP itself, the language that runs WordPress on virtually every hosting environment in existence.

For business owners on managed hosting platforms, this incident was largely invisible. Patches were applied automatically, often within hours of release, and no breach was recorded. For everyone else, the situation depended entirely on whether someone actively arranged the update. If your site runs on a VPS, a dedicated server, or a hosting account where your agency or developer manages the stack, the patch did not apply itself.

PHP Version Management Is a Commercial Liability, Not a Developer Housekeeping Task

WordPress powers a large share of the web, and a significant proportion of those sites run on PHP versions that have reached end-of-life status. End-of-life means the PHP development team no longer issues security patches for that version branch. When a vulnerability is discovered and fixed in PHP 8.2, no equivalent fix is issued for PHP 7.4 or PHP 8.0, leaving sites on those versions permanently exposed to every vulnerability disclosed after their branch’s support window closed.

The PHP2Shell class of vulnerabilities makes this concrete. An attacker who finds your server running an unpatched or end-of-life PHP version can execute arbitrary code remotely, which means they can read your database, extract customer records, install backdoors, redirect your traffic, or take the site offline entirely. These vulnerabilities were exploited before patches existed, so the attack methodology was already circulating before defenders even had a fix to apply.

For a WooCommerce store, the exposure is specific. Your database holds customer names, email addresses, order histories, and billing addresses, and depending on your payment configuration, card tokenisation data may also be present. A successful remote code execution attack gives an attacker access to all of it: the WooCommerce order table alone, accessible via a compromised wp-config.php, contains enough data to constitute a reportable breach under UK GDPR.

The business question is whether your hosting arrangement includes automatic PHP security patching, and whether the PHP version your site currently runs is still within its active support window. Those are two separate questions, both of which require a direct answer from your provider.

The Gap Between Managed and Self-Managed Hosting Is Where Breaches Happen

Managed WordPress hosting platforms handled the PHP2Shell vulnerabilities without any action required from site owners, and that outcome is the product of infrastructure design rather than luck. Providers in this category maintain control of the server environment, monitor vulnerability disclosures, and apply patches as part of the service, so the site owner never sees the risk because it is addressed before it becomes one.

Self-managed and agency-managed arrangements work differently. A VPS or dedicated server gives you or your agency root access and full control of the stack, which is valuable, but it comes with responsibility that is easy to overlook. PHP version upgrades on these environments require testing, scheduling, and deliberate execution. Agencies managing multiple client servers often batch this work, introducing delay, and some defer it indefinitely when a PHP version upgrade risks breaking a plugin or theme that has not been updated to support the newer version.

A site running PHP 8.0 is outside its active support window. A site running PHP 7.4 has been outside that window since November 2022. Every vulnerability disclosed since those dates applies to those sites permanently, with no patch ever coming, and that accumulation is where the commercial risk sits.

The managed versus unmanaged distinction is specifically about who holds responsibility for patching the server-level software your site depends on. If the answer is not clearly your hosting provider, acting automatically, then the responsibility sits with you or your agency and requires active management to discharge. One further consideration that rarely gets discussed: cyber insurance policies increasingly include exclusions for breaches arising from unpatched known vulnerabilities. If your site is compromised via a PHP vulnerability that had a patch available and your server was not running that patch, your insurer may decline the claim, meaning the liability does not end with the breach itself.

---

The two questions worth asking this week are direct ones. First, which PHP version does your site currently run? Second, does your hosting provider or agency apply PHP security patches automatically, or does that require a manual request? If you do not have clear answers to both, you are carrying risk that has a named, scored, and actively exploited mechanism behind it.

If you want me to audit your current PHP version, confirm whether your hosting environment applies patches automatically, and identify any configuration gaps that leave your site exposed, contact The WordPress Guy. Given that these vulnerabilities were exploited before patches existed, the relevant question is whether your site is already hardened against the attack class. I can tell you within a single session. Waiting costs nothing until it costs everything.