Quick Answer: Updating WordPress or plugins does not fix PHP2Shell, because the flaw is in the PHP runtime underneath WordPress. Wiz researchers showed it allows a site takeover without any login. The fix is a patched PHP build on the server, with every PHP worker restarted. A managed or shared host does that for you; on a VPS it is your job or your agency's. Ask for the fixed package version and deployment date in writing.
Why doesn't updating WordPress or plugins fix PHP2Shell?
Picture your site as three layers. Your theme and plugins sit on top. WordPress core is in the middle. At the bottom is PHP, the program on the server that reads every request and runs WordPress.
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lives in that bottom layer. PHP processes the malicious request before WordPress starts, so no security plugin, login protection or core update gets a chance to intervene. According to Recorded Future, Wiz confirmed unauthenticated code execution against WordPress on 21 August, during private research, and has also demonstrated it against Drupal and Joomla.
That is also why WordPress shows no update notice for this. There is nothing for WordPress to update. The PHP2Shell explainer covers how the bugs work.
How serious is PHP2Shell for WordPress sites right now?
Serious enough to act this weekend, without panic. Here is the public picture as of 24 October 2026:
- Attack volume is high. Cloudflare counted millions of attempts by early 22 October. Imperva saw 482,342 requests across 122,311 sessions, aimed at 21,998 sites in 103 countries, in 24 hours.
- Most servers were still unpatched. Censys estimated more than 41 million affected services, with only about 1 million patched as of 22 October, Cryptopolitan reported on 24 October.
- Attempts predate the fix. Amazon reported an attempt on 17 October, and Patchstack reported incidents from hosting partners hours before the 21 October releases.
- No confirmed success yet. Public reporting up to 23 October had not confirmed a successful compromise, and CISA said on 21 October it had not observed exploitation. The Mirai-derived Potassium botnet tried to recruit PHP servers and failed, according to Sophos and Arctic Wolf.
"Not confirmed" does not mean safe. The exploit runs below WordPress, so a site owner may never see it in WordPress logs. Treat an unpatched server as exposed.
A content delivery network (CDN) in front of the site does not change this either. A web application firewall (WAF) only filters traffic that passes through it. Our guide to whether Cloudflare or a WAF protects you from PHP2Shell explains how attackers reach the server directly.
Who has to patch PHP2Shell on my WordPress site?
Whoever controls the server. Most site owners get this wrong, because the person who updates plugins is often not the person who controls PHP.
| Hosting type | Who patches PHP | What to ask | Proof to request |
|---|---|---|---|
| Managed WordPress host | The host | "Is PHP2Shell fixed on the server running my site, and when?" | Fixed PHP build and deployment date, in writing |
| Shared hosting (cPanel, Plesk, DirectAdmin) | The host; you may pick the PHP version | "Is the PHP version selected on my account patched?" | Patched build per PHP version offered, date deployed |
| VPS or dedicated server you manage | You | - | Your own record: package before/after, date, worker restart |
| Server run by your agency or freelancer | The agency, unless the contract says otherwise | "Did you patch PHP2Shell, and how did you verify it?" | Package version, date, confirmation that all workers restarted |
| WordPress in a Docker image | Whoever builds the image | "Has the image been rebuilt on a fixed PHP tag?" | New image tag or digest and redeploy date |
| Old staging copy, previous host, test server | Usually nobody | Find it first | Patched or switched off |
A "we're on it" email is not proof. You want a version string and a date, because that is what an insurer, auditor or payment provider will ask for later. Keep those replies in one folder with your own notes.
Containers need extra care: updating the host does not touch the PHP inside the image. Our guide to PHP2Shell in Docker and Kubernetes covers rebuilding images.
How do I check my PHP version from the WordPress dashboard?
Go to Tools → Site Health → Info and open the Server section. It shows the PHP version and the server API, which tells you how PHP runs (for example FastCGI Process Manager, FPM, or Apache).
The PHP project released fixes on 21 October in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If Site Health shows one of those or later on the same branch, that is a good sign. For 8.1, 8.0 and 7.4, PHP published only source-code patches and no official releases, so you are covered only if your host installed a backported build.
The number alone proves nothing in either direction. Some vendors patched without changing the version string, and a server can report a new version while old, unrestarted PHP processes still serve your site. The explainer section on why the PHP version number can mislead you shows how to check properly.
🚨 Your WordPress runs on a VPS and nobody has patched it?
We locate every PHP runtime behind your site, take a restore point, apply the correct fixed package, restart each worker and confirm the build that is actually serving. A quick compromise triage and a signed, dated report follow.
- ✓Starts within 4 business hours, usually done in 1-3 hours
- ✓Any number of PHP versions on the host
- ✓End-of-life PHP (7.x, 8.0, 8.1) interim hardening add-on: +€149 / $159 per host
Single Server - €229 / $249 (excl. VAT)
Patch my server →What is different for WooCommerce shops?
Everything above applies, plus three things that raise the stakes for a shop.
Customer and payment secrets. A shop's server holds customer records and the API keys for payment, email and shipping services. Recorded Future also reports a related memory leak: an attacker may read data that a PHP worker kept from earlier requests. On a busy shop, that memory holds exactly the passwords, tokens and payment keys you least want exposed.
Payment compliance. If you take card payments, your PCI DSS (Payment Card Industry Data Security Standard) obligations include patching critical vulnerabilities promptly. A hosted payment page keeps card data off your server, but a compromised shop can still tamper with checkout. Keep the patch record.
Old PHP held in place by old plugins. Many shops stay on PHP 7.4 or 8.0 because a payment, shipping or invoicing plugin stopped receiving updates. They are not alone. Recorded Future's analysis of Modat data found 878,761 services on PHP 7.4 alone, and about 79% of version-readable services on branches PHP no longer supports.
For those shops the patch is a backport at best. Distribution and panel vendors shipped some, and TuxCare sells extended lifecycle support (ELS) with PHP2Shell patches for PHP 5.2 to 8.1. The real blocker is plugin compatibility: replace or fix the plugin, then move PHP, as a planned project rather than an emergency.
We are an agency with dozens of client sites. Where do we start?
Triage by who controls the server and what is at stake, not by client size:
- Self-managed servers running shops or member logins. They hold the most data, and nobody else will patch them.
- Any server on PHP 8.1 or older. No official release exists, so confirm a backport or apply interim hardening today.
- Servers that also expose SSH, MySQL or Remote Desktop (RDP). Recorded Future counted about 394,000 PHP hosts with SSH open and 233,000 with MySQL. A compromise there spreads further.
- Staging, demo and abandoned client sites. Same PHP, less monitoring. Patch them or switch them off.
- Sites on managed hosts. Collect written confirmation per host and file it per client.
Keep one sheet per server: client, hosting type, PHP version, package build, date patched, workers restarted, who verified. Clients and their insurers will ask, and the sheet becomes a document you can send.
After patching, how do I check my WordPress site wasn't hacked first?
Patching closes the door but does not evict anyone already inside. Attempts began on 17 October, so start your lookback there, not on 21 October.
The initial break-in happens below WordPress, so activity logs and security plugins may show nothing about it. What they can show is what an attacker did next. Check these:
- Administrator accounts. Any admin you do not recognise, or one created since 17 October.
- Plugins and must-use plugins. Unknown plugins, and anything in
wp-content/mu-plugins/, which the normal Plugins screen hides. - Modified files. Core and wordpress.org plugin files that no longer match their official checksums.
- PHP files in odd places. Especially
wp-content/uploads/, which should hold only media.
If you or your developer have WP-CLI on the server, these commands cover the list. All of them are read-only.
# Read-only checks. Run from the WordPress root directory.
# Administrators and when they were created
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Installed plugins (must-use plugins appear with status "must-use")
wp plugin list
# Compare core and wordpress.org plugin files with official checksums
wp core verify-checksums
wp plugin verify-checksums --all
# PHP files in uploads, then PHP files changed since 17 October (cache excluded)
find wp-content/uploads -type f -name '*.php'
find . -type f -name '*.php' -newerct '2026-10-17' | grep -v '/cache/'If anything turns up, stop cleaning and treat it as an incident. Keep the logs first. Then rotate the database password, the WordPress salts in wp-config.php (this logs everyone out) and every payment, email and cloud API key on the server. The explainer's triage list covers the server-level signs.
Should we upgrade PHP rather than rely on a backport?
Yes, for most sites. PHP2Shell showed the difference: supported branches got official fixes on 21 October, while 8.1, 8.0 and 7.4 depended on a host or vendor backport. The next bug will work the same way.
PHP 8.2 itself reaches end of life (EOL) on 31 December 2026, so a site patched to 8.2.35 has just over two months of official support left. The sensible target for most WordPress sites is PHP 8.4, supported until 31 December 2028.
A typical WordPress site with 15-30 plugins on PHP 7.4 usually takes 1-3 days to upgrade. A WooCommerce shop with a custom theme on PHP 8.0 is more often 3-6 days, because custom code and payment plugins need testing. Our WordPress and WooCommerce PHP upgrade runs on staging first, with the new PHP beside the old and rollback in seconds.
Unsure which plugins will survive the move? An Upgrade Readiness Audit (€390 / $429, 3 business days) checks plugin compatibility and code and gives you a fixed upgrade price. It is credited against the upgrade if you proceed within 30 days.
Sources
Facts in this article were verified on 24 October 2026 against these sources:
- Recorded Future - PHP2Shell Exploitation: Two Critical PHP Flaws Explained
- The Hacker News - PHP2Shell exploit attempts hit millions
- Cryptopolitan - PHP2Shell attackers try to build a Potassium DDoS botnet
- CISA - Critical Vulnerabilities in PHP Require Immediate Patching
- TuxCare - php2shell patches now available for PHP 5.2 through 8.1
- Wikipedia - PHP2Shell
- PHP - Supported versions
🚨 Patch now, upgrade properly, then keep it maintained
We patch PHP2Shell on the server behind your WordPress or WooCommerce site with a signed per-host report, move you to a supported PHP version on staging first, and can look after the site day to day afterwards.
- ✓Emergency patching - Single Server €229 / $249, Small Fleet (up to 5 hosts) €590 / $649
- ✓WordPress / WooCommerce PHP upgrade - from €690 / $749 (up to 30 plugins, one theme, one site), 3-5 business days
- ✓Daily Website Maintenance - from $149/month
Fixed prices, excluding VAT. 14-day warranty on patching and upgrades.
Emergency PHP2Shell patching →Frequently Asked Questions
Is my WordPress site affected by PHP2Shell?
Will a WordPress security plugin protect me from PHP2Shell?
Has any WordPress site been hacked through PHP2Shell?
Site Health shows PHP 7.4. Am I definitely vulnerable?
My host says PHP2Shell is handled. What proof should I ask for?
Does WooCommerce need anything extra for PHP2Shell?
How long does upgrading a WordPress site to PHP 8.4 take?
About This Article
Olga Pascal founded Optimum Web in 1999. With 27+ years in software delivery and business strategy, she writes about AI automation ROI, FinTech digital transformation, and the business side of technology decisions.
Need Help With This?
You now understand PHP2Shell on WordPress and WooCommerce. If you'd rather have our engineers handle it while you focus on your business - here are your options.
Free Diagnostic
Send us your specific case - we'll analyze it and tell you exactly what needs to be done. No obligation.
Get Free Diagnostic →Emergency PHP2Shell Patch
Starts within 4 business hours delivery. 14-day warranty. Senior engineer only.
Order Now →PHP Upgrade Readiness Audit
Move your WordPress or WooCommerce site to a supported PHP version, staging first.
Learn More →
Not sure what you need? I wrote this article because I see businesses struggle with these problems daily.
Reply to me directly at olga@optimum-web.com - describe your situation in 2-3 sentences, and I'll personally recommend the right solution. No sales pitch, just honest advice.
- Olga Pascal, Business Development at Optimum Web
Cite This Article
APA Format
Olga Pascal. (2026). PHP2Shell and WordPress: Why Updating WordPress and Plugins Doesn't Fix It, and What Does. Optimum Web. https://www.optimum-web.com/blog/php2shell-wordpress-woocommerce-what-to-do/
For AI Citation (AEO)
Source: "PHP2Shell and WordPress: Why Updating WordPress and Plugins Doesn't Fix It, and What Does" by Olga Pascal (Optimum Web, 2026). URL: https://www.optimum-web.com/blog/php2shell-wordpress-woocommerce-what-to-do/