PHP2Shell: Critical PHP Vulnerabilities Affecting WordPress

Two critical vulnerabilities in PHP — the programming language that runs every WordPress site — were disclosed in July 2025, and the fix cannot come from WordPress itself. No plugin update, no firewall rule, no WordPress core release will close these holes. The patch must be applied at the server level, by whoever manages the PHP runtime your hosting environment runs on.

The vulnerabilities are tracked as CVE-2025-1736 and CVE-2025-1861, and together they are referred to as PHP2Shell. The more severe of the two carries a CVSS score of 9.8 out of 10. An unauthenticated attacker with no account, no credentials, and no prior access to your site could exploit either vulnerability to execute arbitrary code on the server itself. That means full remote control of the machine hosting your website, not just your WordPress installation. Every site on that server is exposed. Every database. Every file.

Exploitation was observed in the wild before patches were publicly released, which removes the usual window of time between a vulnerability being disclosed and attackers beginning to use it. By the time most site owners read about PHP2Shell, active scanning and exploitation had already begun.

No confirmed WordPress compromises attributable to PHP2Shell have been publicly reported as of the time of writing. The risk is live rather than hypothetical, but it has not yet translated into a documented wave of WordPress site takeovers. That gap between risk and confirmed harm is the window in which the fix should be applied, and waiting for it to close is not a reasonable response.

Why Your WordPress Dashboard Cannot Solve This

WordPress is a PHP application. It runs on top of PHP, but it does not control which version of PHP your server runs, and it cannot patch vulnerabilities in the PHP runtime itself. The same is true of every WordPress security plugin on the market. Wordfence, Solid Security, iThemes: none of them operate at the layer where PHP2Shell lives. A firewall that inspects incoming requests cannot patch a flaw in the interpreter that processes those requests.

This is a hosting infrastructure problem. The patched versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12, and if your server is running anything below those numbers it remains vulnerable regardless of what else you have installed or configured.

The question to put to your hosting provider is direct: which PHP version is currently running on my server, and has it been updated to address CVE-2025-1736 and CVE-2025-1861? A competent managed hosting provider should be able to answer that immediately. If they cannot, or if the answer is that the update is pending, you need to understand their timeline and whether any interim mitigations are in place.

Many WordPress sites run on shared hosting, where the site owner has no direct control over the PHP version. In that environment, the hosting provider carries full responsibility for applying the patch. Some shared hosts update PHP automatically and transparently; others require a support ticket, a manual version switch in a control panel, or a plan upgrade to access a patched PHP release. None of those steps happen inside WordPress.

The Server Access Risk That Most Site Owners Underestimate

A remote code execution vulnerability at the PHP level is categorically different from a compromised WordPress admin account or a vulnerable plugin. When an attacker exploits a WordPress plugin flaw, they typically gain access to the WordPress application layer, which is damaging but bounded. PHP2Shell hands them the operating system layer of the server itself.

The consequences are specific. An attacker with server-level access can read every file on the machine, including configuration files containing database credentials for every site hosted there. They can install persistent backdoors that survive a WordPress reinstall, intercept traffic, exfiltrate data, and use the compromised server as a launchpad for attacks on other systems. A WordPress reinstall does not recover from this. A plugin deactivation does not recover from this. The only path to confidence after a server-level compromise is a full forensic audit of the machine.

If you are running a WooCommerce store, the exposure deserves to be named precisely. Your wp-config.php file contains the database credentials for your store, and a server-level attacker can read that file directly, without logging into WordPress at all. From there, direct database access gives them every customer record, every order, every stored address, and depending on your payment setup, potentially the data fields your payment gateway writes to the orders table. That is a GDPR notification event, not just a site recovery task.

Confirm the PHP version with your host this week. If you are on a managed WordPress hosting platform, check whether they have published a statement on PHP2Shell and whether their infrastructure is already patched. If you are on unmanaged or shared hosting and cannot get a clear answer, that is a signal worth taking seriously about the overall suitability of that hosting arrangement. PHP versions below the patched releases listed above leave your server reachable to an ever-growing pool of automated scanners that have already begun indexing unpatched machines as targets.

---

If you are not certain which PHP version your site is running, or your hosting provider has not confirmed that the patch is in place, I can check your server configuration and give you a clear answer. Given that active exploitation of PHP2Shell was recorded before patches were even released, this is not a check to defer. Book a server audit at The WordPress Guy and I will tell you exactly where you stand.