PHP2Shell Self-Check: Is Your Site Vulnerable? A Real 10-Minute Audit

If you run a website on shared hosting — especially WordPress — you have probably seen this week's headlines: AI researchers found a family of critical vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Severity 9.2, no login required, remote code execution. Cloudflare reported probe traffic jumping from thousands to millions within days of disclosure, and Amazon later found exploitation attempts in their logs dating back to October 17 — before patches were even published.

We run several production sites, so yesterday we did a full audit of our own stack. This post is that walkthrough: what the vulnerability actually is, how to check whether your site is exposed in about ten minutes, and what to do if you are. No fear-mongering, no vague "update your plugins" advice — the exact commands and decision points.

What PHP2Shell actually is (30-second version)

The bugs are memory-safety flaws in PHP's core engine, not in any plugin or theme. One involves corrupted memory handling when allocations fail; the other lets stale global state survive between requests. Because the flaw is in PHP itself:

• Your application code can be perfectly written and still be exposed — a "Hello World" page on an affected version is enough.
• An attacker doesn't need credentials. Successful exploitation means arbitrary code execution on the server, or quiet memory disclosure — reading passwords, API keys, and session tokens belonging to other requests.
• WordPress, Drupal, and Joomla were the demo targets, but they are not required. Any PHP app on an unpatched version is in range.

The one piece of good news: exploitation is genuinely tricky. Public proof-of-concept scripts flooded GitHub after disclosure, and by most credible accounts (including people who tried in lab conditions) the majority of them don't work. "Hard to exploit" is not "safe" — it just means you have days, not hours, to fix it. Use them.

Step 1: Find out what PHP version your site actually runs

Everything hinges on this number. Here are four ways, fastest first. Try them in order until one works.

Option A: Ask a version-reporting page (2 minutes)

If you have phpMyAdmin, a WordPress health check (Tools → Site Health → Server), or any admin dashboard that shows the PHP version — read it there. Write it down.

Option B: Upload a probe file (5 minutes)

Connect to your hosting over FTP (or cPanel File Manager), and create a one-line file in your web root, named something random like check9x2k.php:

<?php echo "PHP_VERSION=" . PHP_VERSION . " | SAPI=" . php_sapi_name();

Visit https://yourdomain.com/check9x2k.php. You'll see something like:

PHP_VERSION=8.1.34 | SAPI=litespeed

Delete the file immediately after reading it. It leaks your exact version to anyone who guesses the name, and a stale probe file is itself a (small) security smell. Use a random name and delete within a minute.

Option C: cPanel (1 minute, if your host uses it)

Log into cPanel and look at the "MultiPHP Manager" tile. It shows the PHP version per domain — and it's the same place you'll go to fix it in Step 3.

Option D: SSH (if you have it)

php -v          # CLI version (can differ from web!)
# web version check:
curl -sI https://yourdomain.com | grep -i x-powered-by

Note that the CLI version and the web-server PHP version can be different. The one that matters for PHP2Shell is the one serving your web pages.

Step 2: Compare against the patched versions

The PHP team shipped fixed releases on October 21, 2026 for every supported branch:

The 8.1 branch reached end-of-life in December 2025, so there is no "8.1.35" with the fix. Your host may have backported the patch into their package (some distributions do, without bumping the version string) — but as we found with our own hosting provider, most publish no announcement either way. You should assume unpatched until your host confirms otherwise, in writing.

Step 3: Fix it — the realistic options

If you're on 8.2 / 8.3 / 8.4 / 8.5 and below the patched release

On cPanel: MultiPHP Manager → select your domain → switch to the latest patched version → save. Then re-run your version probe (Step 1) and hard-refresh to confirm. Total time: about two minutes. On a VPS: apt update && apt upgrade (Debian/Ubuntu) or your distro's equivalent, then restart PHP-FPM.

If you're on 8.1 or older (the uncomfortable bucket)

1. Best: upgrade the branch. On cPanel hosts, MultiPHP Manager usually offers 8.2/8.3/8.4. PHP 8.3 is the sweet spot right now (patched, supported until Dec 2027). Before switching, check that your app supports it — WordPress 6.5+ and all mainstream plugins handle 8.3 fine. Our own order-API code (about 200 lines of plain PHP) passed a compatibility scan with zero deprecated-function hits; that's typical for well-maintained code.
2. If you can't upgrade yet: ask your host, via support ticket, whether their PHP 8.1 package includes the CVE-2026-109618/109619 backport. Get the answer in writing. Meanwhile, harden the surface: most managed WordPress hosts and LiteSpeed servers have WAF rules being pushed this week — make sure they're enabled.
3. Reduce blast radius regardless: the memory-disclosure variant is the sneaky one — it can read secrets from other requests' memory. Rotate anything your app holds in memory carelessly: database passwords, API keys, payment-processor credentials. If you can't confirm you're patched, rotating credentials after the upgrade is cheap insurance.

What about shared hosting specifically?

Two things worth knowing. First, on shared hosting you don't control the PHP build — your host does — which is why the support-ticket route matters more than anything you can do from cPanel. Second, your neighbors matter: even if your own site is patched, an exploited site on the same shared server is a lateral-movement risk (that's how one compromised WordPress site becomes an entire-server problem). This is the strongest argument for moving anything commercially important off the cheapest shared tier once revenue justifies it.

For what it's worth, our exposure was an order-processing API on a shared host: plain JSON endpoints, no file uploads, no sessions, with a per-request process-recycling PHP-FPM pool — an unusually narrow attack surface. Even so, the audit landed on "upgrade to 8.3 this week," because an EOL branch means the next PHP flaw ships with no patch for us at all. The fix is one settings change; there's no good argument to keep riding a dead branch.

The 60-second checklist

1. Probe your PHP version (admin dashboard, cPanel, or the delete-after-reading file trick).
2. Compare with the table above. Patched releases shipped October 21, 2026.
3. Patched? Done. Unpatched 8.2+? Two-minute cPanel switch, re-verify.
4. On 8.1 or older? Open a ticket with your host about the backport, and plan the 8.3 move this week.
5. After fixing: rotate DB passwords and API keys if you were exposed for a while, and delete any probe files.

Sleep-at-night math: ten minutes of checking plus a two-minute settings change versus an unauthenticated RCE on your store, your customer list, and your payment keys. Easy trade.

Technical references: php2shell.com (official disclosure hub), Wiz Research blog, PHP Foundation release notes. This post reflects a real audit performed October 23, 2026 on cPanel/LiteSpeed shared hosting.