PHP2Shell is the name researchers gave to two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, and they hit WordPress sites at the server level rather than through a theme or plugin. Both carry a CVSS v4.0 score of 9.2, and both let an unauthenticated attacker run code on the server as the web worker account. Attack attempts started before the patches shipped on October 21, 2026, so every WordPress owner should confirm their PHP version today.
What Is PHP2Shell and Why Does It Affect WordPress?
The bugs live inside the PHP runtime that executes WordPress, so no WordPress core release, plugin, or security plugin can patch them for you.
An attacker sends a crafted HTTP POST request, and PHP mishandles memory while it parses that request. With CVE-2026-109618, an out-of-memory error leaves request data half built, and PHP's cleanup routine then treats that broken data as valid. With CVE-2026-109619, a worker keeps pointers to memory it already freed, and the next request on the same worker can use them. Either path can end in remote code execution, and the second one can also leak worker memory that may hold database passwords, auth tokens, and API keys.
The attack fires before WordPress loads a single file. A login page, a firewall plugin, or a locked-down admin area does nothing to stop it, because PHP processes the malicious request before any application code runs.
PHP2Shell Affected and Fixed PHP Versions
Your PHP version decides your exposure, not your WordPress version.
| PHP branch | Vulnerable | Patched release |
|---|---|---|
| PHP 8.5 | Below 8.5.12 | 8.5.12 |
| PHP 8.4 | Below 8.4.27 | 8.4.27 |
| PHP 8.3 | Below 8.3.36 | 8.3.36 |
| PHP 8.2 | Below 8.2.35 | 8.2.35 |
| PHP 8.1 and older | Every release back to 5.4 | No regular release |
The PHP project ended support for 8.1 and older branches, so those versions get no standard update. The PHP security team did publish minimal source backports for 7.4, 8.0, and 8.1, but those suit people who compile PHP themselves. If your site runs on one of these branches, plan a move to a supported version.
Method 1: Check Your WordPress PHP Version in Site Health
WordPress shows the exact PHP version your site uses inside the dashboard, and this is the fastest check.
- Log in to your WordPress dashboard.
- Go to Tools and click Site Health.
- Open the Info tab.
- Expand the Server section.
- Read the PHP version line.
Compare that number with the table above. A site on PHP 8.3.30, for example, is vulnerable, while a site on 8.3.36 carries the fix.
One catch applies here. Linux distributions and some hosts backport security fixes without changing the upstream version number, so a server can report 8.3.x below 8.3.36 and still have the patch. If your version looks old, confirm with your host or your distribution's security advisory before you assume the worst.
Method 2: Check if Your Server Uses mod_php or PHP-FPM
The way your server runs PHP changes how urgent the risk is, and Apache with mod_php sits at the top of the list.
Researchers confirmed a working mod_php exploit that completes with a single unauthenticated request under default memory and input limits. PHP-FPM blocks one of the out-of-memory paths on startup, but the PHP team still validated code execution against FPM through the session upload path. php-cgi, FrankenPHP, and LiteSpeed also sit in scope.
To see your setup, look at the same Server section in Site Health. The Server architecture and Web server lines tell you whether you run Apache, Nginx, or LiteSpeed. For the exact handler, create a temporary file named info.php in your site root with this line:
<?php phpinfo();Open yoursite.com/info.php in a browser and find the Server API row:
- Apache 2.0 Handler means mod_php, the highest risk setup.
- FPM/FastCGI means PHP-FPM.
- CGI/FastCGI means php-cgi.
- LiteSpeed V8 means LiteSpeed's PHP handler.
Delete info.php right after you read it. That page exposes server details attackers love.
Method 3: Check PHP Version in cPanel, Plesk, hPanel, or SSH
Your hosting control panel and SSH access give you a second confirmation and reveal any extra PHP installs on the account.
In cPanel, open Select PHP Version or MultiPHP Manager to see the version assigned to each domain. In Plesk, open the domain and check PHP Settings. Hostinger's hPanel lists it under Advanced and PHP Configuration.
If you have SSH access, run:
php -vTreat this result with care. The command line PHP binary can differ from the one that serves web requests, so a patched php -v does not prove your website is safe. Site Health or the Server API check above shows the runtime that actually handles visitors.
Servers that host several sites often run more than one PHP branch side by side. Check every domain and every PHP version installed in the panel, not just your main site.
Method 4: Confirm the PHP2Shell Patch With Your Web Host
Shared and managed WordPress hosts control the PHP binary, so you cannot patch it yourself and you need them to confirm the update.
Send your host a short support ticket that asks three things: whether your server runs a PHP build patched for CVE-2026-109618 and CVE-2026-109619, which PHP version or package build it uses, and whether they restarted the PHP workers after patching. That last point matters because a patched binary does nothing while old worker processes keep serving traffic.
If your host gives a vague answer or no timeline, switch your site to a newer PHP branch from the hosting panel, provided that branch shows a patched release.
How to Fix CVE-2026-109618 and CVE-2026-109619 on WordPress
Updating PHP to a fixed release is the only complete fix, and every other step only buys time.
- Back up your files and database before changing PHP.
- Update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. On a VPS, pull the updated package from your distribution, since vendors received the patches before public release.
- Restart PHP-FPM, Apache, or LiteSpeed so every worker loads the new runtime.
- Run the Site Health check again and confirm the new version.
- Test your site, checkout pages, and forms after the restart.
Server admins who use the volunteer-run rpms.remirepo.net repository should switch to distribution packages or build from source, because that repository did not ship updates on release day. Docker users need to rebuild and redeploy their images, since an old image keeps the old runtime.
If you run PHP 8.1 or older, move WordPress to PHP 8.2 or newer. Test plugins and themes on a staging copy first, because older plugins may break on newer PHP.
How to Protect WordPress if You Can't Update PHP Yet
A few measures shrink your exposure while you wait for a patch, but none of them makes an unpatched server safe.
Cloudflare pushed managed WAF rules for PHP2Shell to every plan, including the free plan, and turned them on by default. If your WordPress site sits behind Cloudflare's proxy with the WAF active, those rules filter the known exploit shapes. Keep the orange cloud on for your main records.
On servers where you control php.ini, add this line and restart PHP:
session.upload_progress.enabled = OffThis blocks the confirmed session upload path for CVE-2026-109619. Set it in php.ini or the FPM pool config, not through ini_set() or a .user.ini file, because those load too late. On PHP 8.5, also set fatal_error_backtraces = 0.
You can also cap request sizes. Set post_max_size = 8M for sites that never take uploads, or 32M for sites that do, and keep upload_max_filesize below it. If a server cannot be patched at all, take it offline or put it behind a VPN until you upgrade.
How to Tell if Your WordPress Site Was Hacked Through PHP2Shell
Patching stops new attacks, but it does not remove anything an attacker planted before you updated, so look back to at least October 17, 2026.
- Strange PHP fatal errors: Search your server error log for
Allowed memory sizeerrors that end within Unknown on line 0. That location means PHP crashed before any script ran, which matches the exploit pattern. - Large POST bursts: Look in your access log for repeated large POST requests from one IP address, especially ones that returned HTTP 200.
- Unknown PHP files: Check
wp-content/uploads, the site root,/tmp, and/dev/shmfor PHP files you did not add. Security plugins like Wordfence can scan core files for changes. - New admin users: Open Users in the dashboard and remove any administrator you do not recognize.
- Cron and SSH changes: Look for new cron jobs under the web server user and new keys in any
authorized_keysfile.
If you find any of these, take the site offline, keep the logs, clean the files, and change your database password, WordPress salts, and every API key stored in wp-config.php. The memory leak bug can expose those secrets even when no files changed.
Frequently Asked Questions
Does updating WordPress or my plugins fix PHP2Shell?
No. The flaws sit in the PHP runtime, so only a patched PHP release or a patched vendor package fixes them. WordPress core and plugin updates do not touch PHP itself.
Is my site safe if it uses PHP-FPM instead of mod_php?
No. PHP-FPM is harder to attack through one path, but the PHP team confirmed code execution against FPM through the session upload route. Every PHP setup that serves web requests needs the update.
Can a WordPress security plugin block this attack?
No. The exploit runs while PHP parses the incoming request, before WordPress or any plugin loads. A network-level WAF in front of the server, such as Cloudflare, can filter it, but a plugin cannot.
My host shows PHP 8.3.30. Am I vulnerable?
Probably, unless your host or Linux distribution backported the fix into that build. Ask your host to confirm, or switch to PHP 8.3.36 or a newer branch from your hosting panel.
What should I do if my site runs PHP 7.4?
Upgrade to PHP 8.2 or newer as soon as you can. PHP 7.4 gets no official release, and the source backport only helps people who compile PHP themselves. Until you upgrade, keep the site behind a WAF and turn off session upload progress.
Related Guides
WordPress Guides
