PHP2Shell and WordPress: What I Found Patching My Own Servers

On Wednesday, 21 October 2026, the internet had a very PHP day.

Two critical bugs in PHP itself, nicknamed PHP2Shell, let an attacker run code on a server with one request and no login. Details leaked before the fix shipped. The NSA told every organization using PHP to get ready for the update and, if it could not patch immediately, to take the system offline.

Plenty of people took that literally. The Dutch National Cyber Security Centre pulled its own website. The Port of Rotterdam, Overheid.nl, Finland’s state IT provider, Denmark’s municipal IT company and French prefecture sites followed, according to Reuters reporting collected by Safeguard. By the evening, fiveoutofnine’s recap of the day ran to about 500 words, wandered through GitLab, LiteLLM and Railway, and ended with “Anyway, it’s Wednesday.” The next morning, Polish security outlet Niebezpiecznik reported that Java and Node.js had shipped critical patches of their own.

I spent that Wednesday patching. We run five Hetzner servers for our own products and for clients. Three had PHP to patch. Two had nothing to patch, because in the previous two weeks we had moved the sites on them off WordPress. That second number is why this is on an SEO agency’s blog.

Below: what PHP2Shell is, what I actually found on my own boxes (including the parts that did not go to plan), the checklist for a WordPress site, why a hack turns into a rankings problem, and the architecture question to ask once you are patched.

PHP2Shell in 60 seconds

Sources: the PHP project’s announcement, Sansec and Help Net Security.

Palo Alto Networks counted more than 22.6 million exposed instances that could be vulnerable. That is a measure of potential exposure, and the real number of vulnerable sites is unknown. What is known is that the attack runs inside PHP before any WordPress code loads, so a security plugin never sees it.

The two bugs, in plain English

Both bugs live in PHP, the runtime underneath WordPress. Updating WordPress core, your theme and every plugin leaves them exactly where they were. The fix is a new PHP binary.

Where AI comes in

The bugs are old. Wiz says nearly every PHP version is affected, going back to PHP 5.4. What is new is how they were found.

OpenAI’s disclosure says a researcher at the security firm Calif found the flaws with GPT-5.6 Sol, through OpenAI’s Patch the Planet program. Wiz found and reported both independently. PHP’s maintainers shipped the fix after about two months of coordinated work between the project, researchers and security vendors.

The uncomfortable part for anyone running a website: a complicated memory bug used to be protected by how expensive it was to find and exploit. That protection is shrinking. AI helps defenders find and fix these bugs, and the same capability helps attackers. PHP2Shell shows what the gap between disclosure and attack looks like now. The details leaked a day early, and attacks started hours before the official patch.

If your own site was rebuilt or extended with AI-written code, the same logic applies one layer up. Code that works and code that enforces its security boundaries are two separate claims. For any generated endpoint, ask whoever ships it to show who can call it, how it rejects bad input, how it handles queries and uploads, and where its credentials live. Treat those as acceptance criteria. A confident explanation from the model is no evidence that the deployed code passes them.

What I found patching five servers

Here is what the day looked like on our own infrastructure. I am sharing it because the official advice (“update now”) skips the parts that actually took time.

1. The inventory came first, and it was the most useful step. Before touching anything, I listed where PHP actually ran. Three of five servers. The other two had run WordPress until 9 and 12 October. Their sites had moved to static pages on Cloudflare, so we had already removed WordPress, PHP and the databases from both boxes. Every unknown answer in an inventory like this is a server you would have missed.

2. The fixed version existed. The package did not. PHP 8.4.27 came out at 14:00 UTC. That afternoon, Debian’s security repository still served 8.4.26, and the official Docker php image only had a release candidate. Sansec reported that the popular Remi repository had no fix on the 21st either. “Update now” assumes your package source has caught up, and on day one it had not. Our servers run automatic security updates, so the host packages patch themselves when Debian ships. One trap: Debian often keeps the same version number and ships the fix as a new package revision. Check the package changelog for the two CVE IDs. The version string alone tells you nothing.

3. A container nobody thinks about. One server ran a small PHP app in Docker, built from php:8.4-fpm-alpine some time ago. It was on 8.4.25, a release older than the host’s. System updates never touch a container. The fix there is a rebuild on the patched image, and that only happens if someone remembers the container exists.

4. Interim hardening on a client’s WordPress server. While we waited for the package, we applied the stopgap settings Sansec recommends: memory_limit set to unlimited at the pool level and upload progress tracking turned off. Unlimited memory means one request can eat the whole machine, so we put a hard memory cap on the PHP service itself. We also capped request bodies at 32 MB everywhere except the WordPress media-upload endpoints. PHP’s own advisory calls configuration changes an incomplete mitigation, and I agree. They buy hours until the real patch.

5. The best patch was deletion. The third PHP server hosted a development WordPress that no human visited. It was answering about 53,000 xmlrpc.php requests a week, with a cheerful 200 OK to every one. We took a full snapshot and an encrypted archive, then removed WordPress, PHP, MariaDB and Redis from the box. Patching that server took less time than patching the others, and nothing on it can ever need this patch again.

Out of five servers, the ones that cost me nothing that day were the ones with no PHP on them. The same goes for this website, which left WordPress in June and now runs as static pages on Cloudflare.

The WordPress checklist

Start with the runtime that serves real visitors. Then check everything else.

1. Get a specific answer from your host. Ask: “Which PHP version serves my domain, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619?” A reply of “WordPress is up to date” answers a different question.
2. Apply the runtime update. The upstream fixed releases are below. Distribution packages may carry backported fixes under the old version number, so confirm through your vendor’s advisory.
3. Restart PHP after the update. Running PHP-FPM workers keep the old code in memory. Confirm the web process uses the new binary. The PHP version in your terminal can differ from the one serving visitors.
4. Find the forgotten installs. Staging sites, old subdomains, admin tools, containers, a WordPress someone spun up for a client demo in 2022. Patching the main site leaves all of those exactly as exposed as they were.
5. Test what makes money. Forms, checkout, logins, scheduled jobs. Write down the package version you deployed and the result.
6. Treat compromise as a separate question. An update closes the hole. A backdoor installed before the update stays installed. Unexpected admin users, new files, odd redirects or content you did not publish need an investigation and a clean recovery.

On PHP 8.1 or older, upstream support has ended. Ask your host whether they backported the fix, and plan the upgrade either way.

Cloudflare deployed WAF rules for the known exploit paths to every plan, including free. That helps. It covers the known variants and leaves the server itself unpatched, so treat it as cover while you update.

If you run your own server, my guide to self-hosting WordPress on Hetzner covers the rest of the operating burden. PHP2Shell is a good reminder that patching is the part of that burden with a deadline.

Why a hack turns into an SEO problem

A compromised site can keep returning a healthy-looking 200 OK while it serves pages you never wrote.

Google’s spam policies cover hacked content: injected pages, hidden links, malicious redirects. Violations can mean lower rankings or removal from results. Our plain-English guide to Google’s spam policies explains how that plays out. A runtime vulnerability is a direct route to losing organic traffic, and a common first symptom is a strange spike of indexed pages in Japanese or a slow slide in rankings that nobody connects to the server.

Then there is the business damage: forms that stop sending leads, customers bounced to a pharmacy site, or the whole site offline while someone investigates. Precautionary downtime costs too. Every government site that went dark on Wednesday lost its visitors for as long as it stayed down.

Once you have contained the problem, compare the site against a known-good baseline: URLs, rendered content, canonicals, redirects and sitemap entries. Check Search Console for security issues and manual actions. For the wider diagnosis, our technical SEO audit method starts with the server for exactly this reason.

Does a static site remove the exposure?

If the public site is prebuilt HTML with no reachable PHP behind it, these bugs have nothing to attack there. That is a real reduction in attack surface, and it is why two of my five servers had a quiet Wednesday.

It depends on what you actually remove:

• A CDN in front of WordPress leaves WordPress running at the origin.
• Headless WordPress still runs a PHP backend somewhere.
• A redesign that leaves the old server online leaves the old exposure online too.

A static Astro build removes PHP and the database from the public serving path of a marketing site or blog. Forms, search and checkout still need secure services, and build tools and third-party scripts still need updates. The framework name alone says little: Astro and Next.js can both run server code. The question to ask is which components on your site answer requests from the internet, and who patches each one.

Our Prawomat case study shows a WordPress site rebuilt as static pages with its rankings intact. That rebuild is the reason one of my two quiet servers was quiet.

Patch first. Then decide what to keep running.

An emergency rebuild is a poor substitute for an available patch. Stabilize the site you have this week. Then decide whether the runtime, the plugins and the database still earn their keep.

If most of your website is the same pages served to every visitor, there is little reason to keep a full CMS exposed to the internet. If you depend on memberships, a big editorial team or WooCommerce, WordPress may still be the right call, and the job is to run it well. Our honest verdict on whether WordPress is still worth it walks through that decision.

If you decide to move, the risk shifts from security to traffic. A careless migration can cost months of rankings. Our website migration service rebuilds the site and protects the URLs, redirects and visibility you already earned, and the migration cost calculator gives you a number before you talk to anyone.

PHP2Shell FAQ

Is my WordPress site affected by PHP2Shell?

If your site runs on PHP older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, without a vendor backport, assume yes. WordPress was one of the applications researchers showed to be exploitable without a login. Your host can tell you which PHP version serves your domain.

Does updating WordPress or my plugins fix PHP2Shell?

No. The bugs are in PHP, below WordPress. Only a PHP update fixes them, followed by a restart of the PHP service.

Does Cloudflare protect me from PHP2Shell?

Partly. Cloudflare added WAF rules for the known exploit paths on all plans, including free. They reduce risk while you patch, and new variants can get past them. Update PHP anyway.

My site was offline as a precaution. Will that hurt my rankings?

A short outage rarely causes lasting damage, especially if the site returned a 503 status during the downtime. A hacked site serving spam is far worse for rankings. Once you are back online and patched, check Search Console for crawl errors and security issues.

Sources

Checked on 21 and 22 October 2026.

1. PHP project: 2026 news archive: fixed releases, affected environments, incomplete mitigations.
2. PHP advisory GHSA-w8hw-w9fx-j79w: CVE-2026-109618.
3. PHP advisory GHSA-6wmf-4rv5-p3rp: CVE-2026-109619.
4. NSA on X, 21 October 2026: prepare to update, take systems offline if you cannot.
5. Sansec: PHP2Shell: exploitable applications, early attacks, stopgap settings, Remi status.
6. Help Net Security: Amazon honeypot timeline, Cloudflare WAF rules, UK NCSC guidance.
7. TechTarget: Palo Alto Networks exposure count, versions affected back to PHP 5.4.
8. OpenAI: coordinated disclosure: discovery through Patch the Planet.
9. Safeguard: governments take websites offline: Reuters-sourced list of precautionary shutdowns.
10. Niebezpiecznik on X, 22 October 2026: Java and Node.js critical patches.
11. Google Search spam policies: hacked content.