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
Two critical vulnerabilities in PHP were disclosed in mid-2025, and if your WordPress site is running an unpatched version, an attacker can execute
Two critical vulnerabilities in PHP were disclosed in mid-2025, and if your WordPress site is running an unpatched version, an attacker can execute arbitrary code on your server without providing a username, a password, or any credentials at all. This is not a theoretical edge case. Remote code execution at the server level means an attacker can read your database, exfiltrate customer data, install malware, redirect your traffic, or wipe your files entirely, with consequences ranging from regulatory exposure under UK GDPR to reputational damage that no press release can undo quickly.
The two vulnerabilities affect PHP versions before 8.1.32, 8.2.28, and 8.3.19. PHP is the programming language that runs WordPress, and every WordPress site depends on it. When a vulnerability of this severity is disclosed publicly, automated scanning begins within hours — attackers run scripts across millions of IP addresses looking for unpatched servers, and they find them faster than most businesses realise a patch exists.
A significant number of site owners make a dangerous assumption here. Updating WordPress core, your theme, and your plugins does not change the PHP version running on your server, because WordPress and PHP are separate layers of your hosting environment: WordPress runs on top of PHP. Keeping WordPress current is correct practice, but it has no bearing on whether your server is running a patched version of PHP.
The majority of live WordPress sites are running PHP versions that are either end-of-life or behind on security patches. PHP version adoption data consistently shows a long tail of sites on older releases, and hosting environments are not always configured to update PHP automatically. Some managed hosts apply patches quickly, others do not, and some shared hosting environments require the site owner to manually select a PHP version through a control panel. Many site owners have never touched that setting since the site went live.
The first thing to do is find out which PHP version your site is running and whether the patch has been applied. You can ask your hosting provider directly. If you have access to a control panel such as cPanel or Plesk, the PHP version is usually visible under a section labelled “PHP Version” or “MultiPHP Manager”. If you use a managed WordPress host, contact their support team and ask specifically: “Is the PHP version on my account patched against the vulnerabilities disclosed in May 2025?” A vague reassurance that your server is “up to date” is not sufficient — ask for the exact version number.
If your host confirms you are running PHP 8.1 and the version is below 8.1.32, you are exposed. The same applies to 8.2 below 8.2.28 and 8.3 below 8.3.19. PHP 8.0 and all earlier versions are end-of-life and receive no security patches at all, which means no fix is coming regardless of when you ask.
Security researchers have documented repeatedly that the gap between a public vulnerability disclosure and mass automated exploitation is short. For high-severity vulnerabilities with available proof-of-concept code, that window can close within 24 to 72 hours. The PHP vulnerabilities disclosed in May 2025 carry CVSS scores in the critical range, placing them in the category that attracts the fastest automated scanning activity.
If you are reading this post days or weeks after the original disclosure, the scanning is already happening. Sites that were unpatched on day one have been probed repeatedly. Whether an attacker has found yours depends on factors outside your control, which is exactly why confirming your patch status now matters more than it did last week.
Business owners frequently underestimate the downstream effect on customer trust, and the compromise itself may not announce itself visibly. Attackers who gain server access often operate silently, harvesting data or installing backdoors that persist through future updates. You may not know your site was compromised until a customer flags suspicious activity, until Google flags your domain as dangerous, or until a data breach notification obligation arises under UK GDPR. At that point the cost extends well beyond technical remediation: it includes legal notification requirements, potential ICO investigation, and the harder-to-quantify loss of customers who simply stop trusting you.
The practical steps are direct. Contact your hosting provider today and ask for the exact PHP version running on your account. If the answer is anything below 8.1.32, 8.2.28, or 8.3.19, request an immediate update. If your host cannot tell you the version or cannot apply the patch within a defined timeframe, that is useful information about the level of security management you are receiving.
For WooCommerce stores, the exposure is sharper. Your store holds customer names, addresses, email addresses, and order history, and depending on your payment configuration it may also hold data connected to payment processors. Server-level access bypasses application-layer controls entirely, so a compromised server does not require a vulnerability in WooCommerce itself to expose that data.
There is also a blind spot that most site owners have not considered. A successful exploitation of this vulnerability leaves no obvious trace in your WordPress admin panel, because the compromise happens below the WordPress layer, at the server level, where standard WordPress security plugins have no visibility. A plugin scanning your WordPress files for malware will not detect a backdoor installed directly on the server through a PHP exploit. That is precisely what makes this category of vulnerability more serious than a typical WordPress plugin flaw.
If you are not certain your PHP version has been patched, I can carry out a technical assessment of your hosting environment and confirm your exposure status. Mass exploitation scanning is already active following the May 2025 disclosures, and waiting for your next scheduled review is not a reasonable position. Contact The WordPress Guy to arrange an immediate PHP security check for your site.
Related articles
Your server can be taken over without anyone touching your WordPress site. No malicious plugin, no compromised admin account, no brute-force login attempt
Two critical vulnerabilities in PHP — the programming language that runs every WordPress site — were disclosed in July 2025, and the fix cannot come from
The plugin that got you was the one you trusted to keep you safe. That is the specific irony of the Backuply vulnerability disclosed earlier this year: a
Security issues need permanent fixes, not surface-level patches. This is exactly the work I specialise in.
View security services →
Jason Boyd
Specialist WordPress Engineer · Former W3C Invited Expert · 20+ years
I fix the WordPress problems other developers walk away from. Backed by a 1st Class degree in Computer Science, an MSc in Cybersecurity, and over 20 years of specialist WordPress work, I diagnose issues at their root cause and resolve them permanently, for businesses that cannot afford guesswork or repeat failures.
If this article describes your situation, I can diagnose the specifics and fix it properly. Send your brief and I'll respond the same working day.