PHP2Shell WordPress Checklist: Patch in 10 Minutes (2026)

Two critical flaws in PHP — the language your WordPress site actually runs on — are being actively probed across the internet right now. They’re called PHP2Shell (CVE-2026-109618 and CVE-2026-109619), both rated CVSS 9.2 out of 10, and patches landed on October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Here’s the part that catches most site owners off guard: updating WordPress, your theme, and your plugins does absolutely nothing against this. The bug is in PHP itself, underneath everything. Only a PHP server update closes it — and attackers started trying it on October 17, four days before the disclosure.

This checklist gets you from “I have no idea what PHP my site runs” to “confirmed patched” in about ten minutes. I’ve also included the gotchas that are tripping people up this week — including the version-number trick where your panel says one thing and the truth is another.

Why PHP2Shell hits differently than a normal plugin vulnerability

Most WordPress security scares live at the application layer: a plugin you installed, a theme file, something you clicked “Update” on. PHP2Shell sits below all of that. Cloud security firm Wiz, which discovered the flaws, demonstrated remote code execution against the latest WordPress, Drupal, and Joomla container images in its lab — and noted that even a dead-simple “Hello World” page on an affected PHP version could be vulnerable. The flaws live in PHP’s request handling, which runs before any application code, including your security plugin’s firewall. That’s why Wordfence, Shield, or any other WordPress plugin can’t stop this one: the attack arrives before the plugin ever loads.

The scale is the other problem. Wiz puts PHP’s share of the web at roughly 70%, and the vulnerable code traces back to PHP 5.4, released in 2012. Google’s advisory confirms every PHP version from 5.4 through 8.5.11 is affected. And here’s the unsettling footnote: Wiz says AI models assisted in both the discovery of the bugs and the development of exploit code. Attackers are getting the same leverage. Expect this pattern — AI-found engine bugs with working exploits days before patches — to repeat.

On October 21, WordPress.org published its own notice confirming the flaws “are not specific to WordPress and affect any server that hosts a PHP application,” and that “no WordPress update is required or planned for these issues.” Translation: clicking the red update badge in your dashboard this week did not protect you from this.

The 10-minute PHP2Shell checklist

Work through these in order. Steps 1–4 are pure checking; step 5 is the fix confirmation; steps 6–8 are the cleanup most guides skip.

Step 1: Find the exact PHP version that serves your site

In your WordPress dashboard, go to Tools → Site Health → Info, expand Server, and read the PHP version line. Note the full number — 8.3.36, not just “8.3.” (On WooCommerce stores, the same number appears under WooCommerce → Status.)

One important caveat the independent tracker php2shell.fyi flags: Site Health sometimes only checks the branch, so a reassuring green status on the branch level doesn’t prove you’re patched. You want the full release number.

Then cross-check it with your hosting panel, because the panel often shows what the server actually uses:

• cPanel: look for Select PHP Version or MultiPHP Manager — it shows the version assigned to each domain.
• Hostinger hPanel: under Advanced → PHP Configuration.
• Plesk: open the domain and check PHP Settings.
• Managed hosts (WordPress.com, Pressable, GridPane, RunCloud): check the site dashboard; many patched automatically.

If you have SSH access, php -v is tempting, but don’t trust it alone — the command-line PHP binary can be a different version than the one serving web requests. Site Health or a quick phpinfo() page shows the runtime your visitors actually hit. (If you create an info.php file to check phpinfo(), delete it the moment you’re done — it broadcasts your server details to anyone who finds it.)

Got several domains on one account? Check every domain. Servers often run more than one PHP branch side by side, and the main site can be patched while a staging subdomain still runs the vulnerable build.

Step 2: Compare against the fixed releases

The PHP project released fixes on October 21, 2026, at 14:00 UTC. Here’s the table that matters:

Anything newer in the same line than the listed version is fine. If your number matches or beats it, you’re patched for these two CVEs.

Step 3: Don’t get fooled by the version number

This is the gotcha that’s confusing people this week. Some hosts slipped the fix into the PHP version you already run instead of bumping the number. Hostinger’s own status page says some sites still show PHP 8.5.11 after the update — and that’s expected. The tell is the Build Date in phpinfo(): if it’s October 21, 2026, or later, the fix is in, even if the version string looks old.

This is exactly why step 4 matters: a version string alone doesn’t always prove the patch. Ask your host to confirm the fix by name.

Step 4: Send your host this exact ticket

If you’re on shared or managed hosting, you don’t control the PHP binary — your host does. You can’t patch it yourself, and you need them to confirm. Copy-paste this into a support ticket:

Hi, has the PHP serving my account been patched for the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619)? Please confirm: (1) which PHP version/build my domain runs, (2) whether it’s patched for both CVEs, and (3) that PHP workers were restarted after patching.

That third question matters more than it looks. A patched binary does nothing while old worker processes keep serving traffic — and the Reddit and social posts claiming “the patch doesn’t work” almost always turn out to be servers that installed the update but never restarted PHP, servers that only changed settings instead of updating, or version numbers that looked old but were already patched. As of this week, neither PHP nor any major security firm has reported a real bypass of the fix.

A reply that says “your WordPress is up to date” does not answer your question. WordPress being current is irrelevant to this flaw — you’re asking about the server underneath it.

Step 5: What the big hosts are actually doing

As of October 22–23, 2026, here’s where the major providers stand (check your own provider’s status page, because this moves fast):

• Hostinger: PHP upgrades complete on all managed Web, Agency, and cPanel hosting servers — no client action needed. VPS customers manage PHP themselves.
• GoDaddy: patched all PHP versions on Web Hosting, Managed WordPress, and Windows Hosting. VPS owners must update PHP themselves.
• Bluehost: said October 22 that most platforms were updated with the rollout continuing.
• WordPress.com / WordPress VIP / WP Cloud / Pressable: Automattic confirmed these were already protected.
• xCloud, GridPane, RunCloud, SiteGround: all published patched builds or backports for supported versions on their stacks.

If your host gives a vague answer or no timeline, check your panel for a newer PHP branch that shows a patched release and switch the domain to it yourself — that’s often the fastest path on shared hosts.

Step 6: If you’re on PHP 8.1 or older, this is your upgrade push

The PHP project released no official fix for 8.1, 8.0, 7.4, or anything older — only minimal source backports for people who compile PHP themselves. Some hosts and Linux vendors backported the fix into their own packages (Ondřej Surý’s Ubuntu packages cover 5.6 through 8.1, for example), so ask your host before assuming. But even if a backport covers you today, you’re living on borrowed time: PHP 8.2 itself goes end-of-life on December 31, 2026. The reliable move is testing your site on a staging copy and moving to PHP 8.3 or newer. If your site breaks on the newer version, fix the theme/plugin incompatibility now — while attackers are focused on this bug, not yours.

CISA’s stance for systems that truly can’t be updated: take them offline until they can be. Harsh, but with public exploit code circulating, “we’ll upgrade next quarter” is a decision to stay exposed during the highest-risk window.

Step 7: After patching — rotate your secrets

One of the two flaws also allows memory disclosure: attackers could potentially read data left in server memory by other requests — passwords, tokens, API keys. Wiz’s own guidance says that if your site ran unpatched PHP in the window between October 17 (first observed exploit attempt) and whenever you patched, you should consider rotating passwords, API keys, and tokens for important admin accounts. Check your session/token storage, your SMTP credentials, and any payment or API keys your site uses. This step is cheap and eliminates the worst-case scenario quietly.

Step 8: Look for signs of a break-in

An exploitation attempt isn’t the same as a successful breach, but the window for compromise was real. Wiz suggests watching for: unusual multipart upload requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker restarts. Security researchers also recommend the classic checks: scan your site’s folders for files you don’t recognize, look for new scheduled tasks (cron jobs) you didn’t create, and check for new WordPress admin accounts. If anything looks off, get your host or a developer to review the server and preserve the access logs — don’t just delete the weird file and move on. If the site comes back clean, our guide to securing WordPress from hackers walks through the hardening steps worth doing next.

What your next move is depends on your hosting type

Not everyone can follow the same checklist. The only part that’s identical for everyone is steps 1–3 (find your version, compare, don’t trust the number alone). After that, your job splits by hosting type:

If you’re on a VPS or your own server and running something unusual — FrankenPHP, LiteSpeed’s PHP, php-cgi behind nginx — the same fixed releases apply, but the “restart” step is whatever restarts your PHP workers (php-fpm, the Apache module, or the container). Distributions got the patches in advance: Debian, Red Hat, and Ubuntu all published fixed packages, so on most managed Linux servers apt upgrade or dnf upgrade was enough, followed by the restart. On a container setup, pull the rebuilt image and redeploy — restarting a container that’s still running the old image just restarts the vulnerability.

One more trap for VPS owners: control panels sometimes install a separate PHP for the panel itself (like cPanel’s internal PHP) alongside the PHP that serves your sites. The panel’s internal PHP doesn’t serve web requests, so it’s not the priority — but while you’re in there, check every PHP build the panel lists, because old versions sometimes linger as selectable options for add-on domains.

What will NOT save you (this week’s myths)

A WAF or Cloudflare. Cloudflare deployed PHP2Shell WAF rules on October 21 at 03:02 UTC — automatically, even on free plans. But Cloudflare itself says this is an extra layer, not a fix, and attackers mutate payloads to evade WAF rules. It buys you time; it does not replace the update.

Disabling session.upload_progress. Before the patch, turning this off spread online as an emergency workaround. It only blocks some attack paths for CVE-2026-109619 and does nothing for CVE-2026-109618. The PHP team says updating is the only complete fix.

Your security plugin. Wordfence’s firewall, Shield, Sucuri — all run after PHP has parsed the request. This bug is in the parsing itself. They’re still worth having for everything else, but they cannot see this attack.

“I’ll patch it this weekend.” The details leaked on October 20, the patch shipped October 21, and Amazon’s threat intel logged exploit attempts on October 17 — before anyone knew the bugs existed publicly. Governments in several countries took websites offline while auditing (Nepal’s .gov.np sites, including the president’s and prime minister’s offices, went dark on October 22). The scanning is happening now, not later.

The bigger lesson nobody should miss

PHP2Shell is the first major vulnerability where AI assistance showed up on both sides of the timeline: helping discover the bugs and helping build the exploit. That cuts the quiet period between “bug exists” and “working exploit circulates” to almost nothing — here, attackers were trying it before disclosure even happened.

For a small business owner, the practical takeaway isn’t to fear AI. It’s to shrink your own reaction time: keep your site on a supported PHP branch so updates arrive automatically, keep credentials in environment variables or a secrets manager instead of hard-coded in files, keep verified offsite backups, and have a rollback plan. The next engine-level bug won’t give you more warning than this one did.

Frequently Asked Questions

Is PHP2Shell fixed?

Yes — the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. Your site is only protected once the PHP on its server has actually moved to one of these versions (or a host-patched build dated October 21, 2026, or later). Updating WordPress does not fix it.

Is PHP2Shell being exploited right now?

Attempts, yes; confirmed mass breaches, not yet publicly established. Amazon’s threat intelligence logged an exploitation attempt against its honeypots on October 17 — four days before disclosure — and Cloudflare and watchTowr reported attempts too. CISA said it hadn’t observed exploitation when it published its alert, and the CVEs weren’t in its Known Exploited Vulnerabilities catalog as of October 22. With public proof-of-concept code circulating, the safe assumption is that internet-facing PHP servers are being scanned.

Will updating WordPress protect me?

No. This is a flaw in the PHP engine that runs underneath WordPress (or Drupal, Joomla, Laravel, or anything else). No CMS, theme, or plugin update can fix it — WordPress.org confirmed no WordPress update is needed or planned. You or your host must update PHP itself.

I’m on PHP 7.4 or 8.1. What should I do?

Move to PHP 8.2 or newer, ideally 8.3+. The PHP project no longer issues fixes for 8.1 and older, though some hosts and Linux vendors ship their own backports — ask your host. And note PHP 8.2 itself reaches end of life December 31, 2026, so this upgrade is coming either way.

My host says everything is handled. Should I just believe them?

Mostly, but verify. Ask the three questions from the ticket in step 4: the exact version/build, patch confirmation by CVE name, and whether PHP workers were restarted. If they can’t give you a straight answer, switch your domain to a patched PHP branch in the hosting panel yourself.

How do I know if my site was already hacked?

You can’t always tell from the outside. Check for files you don’t recognize in your site folders, new scheduled tasks (cron jobs), and unfamiliar admin accounts. Watch for repeated server errors, strange PHPSESSID cookies, or PHP workers restarting for no reason. If you see any of these, ask your host or a technician to investigate and preserve the logs — and rotate your passwords and API keys.

For the full technical write-up, the managingwp.io PHP2Shell guide tracks patch status across hosting providers, and the CVE.tools PHP2Shell FAQ is the clearest plain-English FAQ on the two CVEs I found this week.