There’s a PHP problem your WordPress dashboard can’t fix. It’s called PHP2Shell, and the flaws are in PHP itself - the language that runs WordPress - not in a theme or plugin. If you run a small business site, your job today isn’t to hunt for a magic security setting. It’s to find out whether your host has patched PHP and restarted it.
Update, 22 Oct: Wordfence and Patchstack have shared new details on real-world risk. Our follow-up covers them, plus what we found on our maintenance clients’ sites.
Here’s what we know, what we don’t, and the questions I’d send to a hosting provider.
What happened with PHP2Shell?
PHP2Shell is the name given to two critical flaws: CVE-2026-109618 and CVE-2026-109619. The first involves memory corruption when PHP runs out of memory. The second involves stale state left between requests. Both have a CVSS score of 9.2, and both can let someone run code on a server without logging in. That code runs as the web server’s PHP user.
Researchers from Calif, Wiz and OpenAI found the flaws. The PHP project warned on 20 October that fixes were coming, then released them on 21 October 2026 at 13:30 UTC - 16:30 in Estonia. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Earlier releases in those branches are affected.
PHP 8.1 and older are end of life and won’t get an update from the PHP project. Some Linux distributions and long-term-support vendors may backport the fixes, though, and the PHP team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. For a normal site owner, the answer is simpler: move off 8.1 or older, or get your host to confirm its backported fix.
Proofs of concept have started circulating, according to CERT-EU. Cloudflare’s CTO has said they’re seeing early attacks and have firewall rules in place, but described those rules as temporary. Nobody knows yet how many sites have been hit. Don’t let anyone give you a confident victim count.
Why updating WordPress won’t fix it
Wiz demonstrated an attack before login on current WordPress, Drupal and Joomla sites. Those sites were test targets, not the cause. The problem sits underneath them, in PHP, and affects web-serving setups including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
The PHP team considers mod_php the highest risk. In a demonstrated exploit, a single unauthenticated request triggers the attack before application code runs. Your WordPress security plugin doesn’t even get a look at that request. A plugin update, a WordPress core update or a tweak in wp-config.php won’t patch PHP. The host, or whoever runs your server, must update it and restart PHP afterward.
Check your site today
You don’t need a command line to start. Open your WordPress dashboard and work through this:
- Go to
Tools > Site Health > Info > Serverin wp-admin and findPHP version. Write down what it says. - If it says 8.1, 8.0, 7.4 or older, ask for an upgrade now. Test your forms, checkout and booking flow afterward; use a staging site first if you have one.
- If it shows an earlier release in the 8.2, 8.3, 8.4 or 8.5 branch, ask your host about the patch. Don’t assume the dashboard tells the whole story.
That last point matters. With distribution-packaged PHP, a host can install a backported security fix without changing the version number you see in WordPress. The number is a clue, not proof that you’re exposed or protected. And clicking around wp-admin won’t tell you whether PHP was restarted.
PHP2Shell checker: how to check your host is patched
A PHP2Shell checker is a useful first pass for your WordPress site. Free online checkers make one normal request to your homepage, read what the server announces, such as the X-Powered-By header, and compare any PHP version they find with the first fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They don’t send an exploit. If your server hides its version, they can’t tell whether it’s patched, and even a clean result isn’t proof.
- Check a site you own. In WordPress, open
Tools > Site Health > Info > Serverand note the version serving your web requests. - Don’t rely on
php -v. Your terminal may use a different PHP version from Apache or PHP-FPM. - Ask your host which PHP package serves your site. If several versions are installed side by side, every version a site can use needs the fix, and your site must use a patched one.
- Ask for the package changelog showing both
CVE-2026-109618andCVE-2026-109619. Someone with server access can runrpm -q php-cli --changelogon RPM-based systems; a distribution may backport the fix while keeping an old version number, and a higher number alone isn’t proof. - Ask when PHP-FPM and Apache workers were restarted. Updating a package doesn’t replace code already running in memory.
A good host reply names the fixed version or package, shows both CVE changelog entries, gives the restart time, and confirms your site’s PHP is patched. For a PHP2Shell WordPress check, I wouldn’t run an exploit test against a live shop. Its large payload can crash a worker and interrupt live requests.
What to ask your host
Send a ticket today. If you’re on shared hosting, this is their server to fix, not yours. Copy this and change the site name:
“Can you confirm whether PHP serving my WordPress site is patched against CVE-2026-109618 and CVE-2026-109619? Which fixed PHP version or backported package is installed? When was it applied, and was PHP restarted afterward? If it isn’t patched yet, when will it be?”
A useful reply names the version or package and confirms the restart. “We monitor security” doesn’t answer the question. Linux distributions received patches in advance, so many hosts can act quickly. If yours can’t give you a clear answer or a patch date, I’d consider moving. On our managed web hosting, patching PHP for clients is our job; you shouldn’t have to guess whether someone owns it.
If the patch isn’t available yet
CERT-EU and the UK NCSC say to patch immediately. If that can’t happen, they advise considering taking the system offline until it’s patched. That’s a painful call if your site takes orders, I know. But an unexplained delay isn’t a protection plan. Ask your host what they can do right now and when the real fix will land.
The PHP team lists temporary server-level measures: set memory_limit=-1 so applications can’t override it, keep post_max_size low (8M without uploads or 32M with uploads), set session.upload_progress.enabled=0, restart every worker, and on PHP 8.5 set fatal_error_backtraces=0. These reduce exposure; they do not make an unpatched server safe. They also can’t be set reliably through .user.ini or ini_set(), so don’t spend the afternoon trying to fix this with a plugin.
Watch for trouble after patching
A patch closes the flaw. It doesn’t remove a backdoor that was already planted. If your site stayed unpatched, the NCSC advises checking for signs of compromise. Over the next weeks, look for:
- Admin users you don’t recognise, or strange PHP files in
wp-content/uploads. - Changes to
.htaccess, unexpected redirects or spam pages showing up in Google. - “Malware detected” emails from your host. Don’t dismiss them as noise; verify them through your hosting account.
Keep backups from before 21 October rather than overwriting everything with fresh copies. Run a malware scan, too, but know what a malware scan can miss. A clean result isn’t a guarantee. If you spot something odd, preserve a backup before changing files. Our hacked WordPress site guide walks through the response; if you’d rather hand it over, we offer hacked site cleanup.
Who makes the change?
On shared hosting, you can check, ask and monitor, but you can’t apply the server-side patch yourself. On a VPS you manage, update the PHP packages and restart PHP; if somebody else administers it, send them the host questions above. Don’t wait untill a dashboard notice appears. Open a hosting ticket today and ask for the package name and restart time.