PHP2Shell is the name for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in. If your WordPress site runs on an unpatched PHP build, it is exposed, and no WordPress, theme or plugin update will close it. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, released on October 21, 2026, or a vendor build that carries the same patch.
This is the rare WordPress emergency that does not live in wp-admin. It is also one you can close today. Finding out where you stand takes two minutes, and on most hosting the fix is one message to your host.
- The flaws
- CVE-2026-109618 and CVE-2026-109619
- Severity
- CVSS 9.2, no login needed
- Fixed in
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- Released
- October 21, 2026
- WordPress update
- None needed, none planned
- Seen in the wild
- Attack attempts since October 17
What is PHP2Shell?
PHP2Shell is a pair of memory bugs in the PHP engine that can give an anonymous visitor remote code execution on any server where PHP answers web requests. The PHP project rates both 9.2 on CVSS v4.0, and its security advisory tells every PHP user to update immediately.
The two bugs are two ways to leave PHP holding memory it should not trust. CVE-2026-109618 fires when a request runs out of memory at the wrong moment and leaves half-built data behind. CVE-2026-109619 lets state from one request survive into a later request handled by the same worker. The GitHub advisories for CVE-2026-109618 and CVE-2026-109619 put the impact at remote code execution with the privileges of the web worker account.
On a WordPress site, that worker account is the one that reads wp-config.php, database password included, and in most setups the one that can write to wp-content. Code running as that user can do anything WordPress can do, and a fair amount it never should.
Is PHP2Shell being exploited?
Attack attempts are real, and how widespread they are is still argued. According to the PHP Foundation, the CVE numbers leaked on October 20, so the fix shipped a day early, on October 21 at 14:00 UTC. Amazon Threat Intelligence logged an exploitation attempt against its honeypots on October 17, four days before disclosure, and by October 21 called PHP2Shell broadly exploited, based on sensor traffic rather than confirmed breaches.
Sansec, writing the same day, took the calmer view: the public exploits need specific conditions on the target, so mass exploitation looks less likely than first feared. At the time of writing, neither CVE is in the CISA Known Exploited Vulnerabilities catalog. Both readings lead to the same action, so you do not have to settle the argument before you patch.
Does PHP2Shell affect my WordPress site?
Your WordPress site is affected if the PHP that serves it is older than the fixed release for its branch and carries no vendor backport, whatever WordPress version you run. The bug sits below WordPress, and the WordPress.org notice on PHP2Shell, written by John Blackbourn, says no WordPress update is required or planned for it.
How your server runs PHP changes the odds, not the answer. The php.net advisory puts PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed in scope, and rates the risk highest for mod_php, where a demonstrated exploit fires before any application code runs. PHP-FPM is no reason to relax either: the PHP Foundation says code execution was also confirmed there through application code paths.
What you have to do depends on who runs PHP for you.
| Managed WordPress | Shared hosting | Your own server | |
|---|---|---|---|
| Who patches PHP | Host | Host | You |
| Who picks the branch | Host or you | You, in the panel | You |
| Your job today | Confirm with host | Confirm, maybe switch | Patch and restart |
Some hosts have already said where they stand. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are protected and their owners need to do nothing. For everyone else, the source is your host status page or support desk, not a news roundup.
The harder problem is old PHP. In October 2026, the WordPress.org version statistics showed 35.8% of WordPress sites reporting PHP 8.1 or older, a range of branches with no official PHP2Shell release at all. PHP 7.4 alone accounts for 15.9%.
How to check your PHP version in WordPress
The quickest way to check your PHP version in WordPress is WordPress Site Health: Tools, Site Health, then the Info tab, where the Server section shows the PHP version that actually serves your site. It is the place WordPress.org points to in its PHP2Shell notice, and it needs no plugin.
- In wp-admin, open Tools, then Site Health.
- Switch to the Info tab and expand Server.
- Read PHP version and compare it with the table below.
- Read PHP SAPI on the line under it. apache2handler means Apache with
mod_php, the highest-risk setup. fpm-fcgi means PHP-FPM.
| Your branch | Fixed release | What it means |
|---|---|---|
| PHP 8.5 | 8.5.12 | Patch inside the branch |
| PHP 8.4 | 8.4.27 | Patch inside the branch |
| PHP 8.3 | 8.3.36 | Patch inside the branch |
| PHP 8.2 | 8.2.35 | Patch now, and plan a move: support ends December 31, 2026 |
| PHP 8.1 or older | None from the PHP project | Vendor backport, or a new branch |
In your hosting panel
Most hosting panels show the PHP version per site, usually next to the selector that changes it, such as Select PHP Version in cPanel. The panel tells you the branch. Whether that branch already has the patch is a question for your host.
With WP-CLI
If you manage several sites over SSH, WP-CLI gives a quick sweep:
wp eval 'echo PHP_VERSION . " " . PHP_SAPI . PHP_EOL;'Notice that this prints cli as the SAPI. WP-CLI runs the command-line PHP binary, which on many servers is a different build from the one serving the site, so a patched CLI proves nothing about the web side. Use the command to find the old ones fast, then confirm each site in Site Health.
When the version number does not tell you
Linux distributions and long-term-support vendors received the patch ahead of the release, according to the php.net advisory, and distributions such as Debian backport security fixes into the version they already ship instead of moving to the new upstream release. A patched distribution package can therefore still report a lower number than the fixed release for its branch. On a distribution build, look for CVE-2026-109618 and CVE-2026-109619 in your distribution security notice or package changelog, or ask your host, rather than trusting the number.
How to update PHP in WordPress safely today
For most sites, the PHP2Shell update is a patch release inside the branch you already run, the lowest-risk PHP update there is. Point releases inside a branch exist to fix reported bugs and security issues, as the PHP support schedule describes, so a WordPress site that works on 8.3.x should keep working on 8.3.36.
On managed or shared hosting
Ask your host, and skip the question of whether they know about PHP2Shell. Ask the ones with checkable answers:
- Which PHP build serves my site right now, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619?
- Were all PHP workers restarted after the update?
- If my site is on PHP 8.1 or older, do you ship a backported fix, and until when?
- Did you apply any temporary PHP settings, and do they affect uploads?
If your panel lets you pick the branch and a fixed one is on the list, switch now instead of waiting for the reply.
On your own server
Install the patched packages from your distribution or vendor, then restart every PHP process, because a worker that started before the update keeps running the old code; watchTowr lists the restart as part of the fix. On Debian or Ubuntu with PHP-FPM it looks like this, with the service name matching your branch:
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
# only if Apache runs PHP itself (mod_php)
sudo systemctl restart apache2Then open Site Health again. php -v on the command line reports the CLI build, not the one your visitors hit.
On PHP 8.1 or older
There is no PHP2Shell release for PHP 8.1, 8.0 or 7.4 from the PHP project. The php.net advisory leaves three routes: a backport from your distribution or a long-term-support vendor, the minimal source patches the PHP security team published for 7.4, 8.0 and 8.1, or a move to a supported branch. On shared hosting, only the third is really in your hands.
PHP 8.1 reached its end of life on December 31, 2025, and 7.4 on November 28, 2022, which is why no official fix exists for them. Move to PHP 8.3 if you can: it is the recommended PHP version on the WordPress requirements page, and the compatibility table lists PHP 7.4 to 8.5 as supported by WordPress 7.1. PHP 8.2 stops getting security fixes on December 31, 2026, so landing on 8.2 means doing this again before 2027.
- Take a full backup, files and database, and keep a copy off the server.
- Update WordPress, the theme and every plugin first. Old plugin versions are the usual reason a PHP upgrade breaks a site.
- Copy the site to staging, switch staging to PHP 8.3, and click through what matters: the editor, forms, checkout, anything a plugin renders. Watch the PHP error log while you do.
- Replace plugins that fail and have no update. A plugin abandoned on PHP 7.4 is a liability with or without PHP2Shell.
- Switch production, then confirm the new version in Site Health.
WordPress.org also suggests the PHP Compatibility Checker plugin in its PHP update guide, with the warning that it can miss problems and flag false ones. Staging is the test that counts.
On a site you inherited, we normally say leave PHP until last, because it is the change most likely to take everything down at once. PHP2Shell is the exception. A broken page costs you an afternoon. A remote shell on the server costs you the site.
What if you cannot update PHP today?
If PHP cannot be updated today, the php.net advisory lists settings that block the confirmed attack paths, and it is blunt that they reduce exposure without making an installation safe. Treat them as a stopgap for the hours until PHP is patched.
; php.ini, PHP-FPM pool or server config, then restart every worker
memory_limit = -1
; 32M if the site takes uploads; keep upload_max_filesize below it
post_max_size = 8M
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0Each line has a cost on a WordPress site:
memory_limit = -1removes the PHP memory limit failure the first bug uses, though not every allocation failure, and it also removes the cap a runaway plugin or a request flood would hit. Watch server memory and put the limit back after patching.post_max_sizecaps the request size. WordPress shows the resulting limit under Media, Add New. Anything bigger (a video, a theme zip, a plugin zip) will fail to upload until you raise it again.session.upload_progress.enabled = 0is nearly free: WordPress core does not use PHP sessions. Check that no plugin relies on upload progress bars.fatal_error_backtraces = 0exists only on PHP 8.5 and blocks one confirmed path.
Where you set these PHP settings matters. The php.net advisory wants them applied where code cannot override them, before the request is parsed: php.ini, the PHP-FPM pool or the server config, with php_admin_value for memory_limit. A per-directory .user.ini or ini_set() in a plugin does not count, which on shared hosting means your host has to apply them.
Two heavier options exist. Amazon suggests blocking multipart file uploads on PHP deployments that cannot be patched yet, after checking the impact, and on WordPress the impact is large: media uploads, theme and plugin installs from a zip and every form with a file field use them. For a self-managed server stuck on old PHP, the WordPress.org notice says to consider taking it offline while you prepare the upgrade, as several national cyber security agencies advise.
- The fix
- Update PHP
- Stopgap
- Server settings
- Last resort
- Take it offline
Was my WordPress site hacked already?
Check for signs of compromise back to October 17, not October 21. Amazon saw the first attempt on the 17th and advises starting any investigation from that date. Code execution on a WordPress install leaves traces in a few predictable places, and WP-CLI reaches all of them in a minute:
wp user list --role=administrator --fields=ID,user_login,user_registered
wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name '*.php'- An administrator you do not recognize, or one registered after October 17.
- Core or plugin files that fail the checksum check. Premium plugins are not in the WordPress.org registry and show as unverifiable, so compare those against a fresh download.
- PHP files in the uploads folder, where WordPress keeps media, not code.
- In your server logs: multipart POST requests carrying
PHP_SESSION_UPLOAD_PROGRESS, which Amazon lists as a hunting signal, and PHP processes starting shells or writing files nobody deployed.
Read the administrator list for more than strangers. Every account that can install code is a way in, and some of them should not exist anyway.
If any check comes back wrong, stop investigating and switch to the incident order in our checklist: take the site offline, copy the compromised state, restore a clean backup, rotate every secret, and patch PHP before the site goes back up.
Hardening that limits the next PHP bug
Patching closes PHP2Shell. The hardening worth doing now limits what code running as your web worker can do the next time the engine has a bug, because a bug below WordPress skips every login screen and every security plugin you have. It starts with speed: Amazon argues that 7 or 30 day patch cycles for critical internet-facing bugs assume delays that no longer exist.
- A patch window for critical PHP and WordPress fixes measured in hours, with a named person who applies it.
- A supported PHP branch with its end date in your calendar. For PHP 8.2, that date is December 31, 2026.
- A web worker that cannot rewrite your code: DISALLOW_FILE_MODS in wp-config.php and read-only core, theme and plugin files, where your workflow allows it.
- No PHP execution in wp-content/uploads, set at the server, so a dropped file cannot run.
- PHP features you do not use, switched off. The GitHub advisory for CVE-2026-109619 suggests keeping session upload progress off even after patching if nothing needs it.
- Backups stored where the web worker cannot reach them, because code running as that user can delete anything it can write.
A WordPress update cannot fix the software WordPress runs on. Know who patches your PHP before the next bug, not during it.
Common questions
Is PHP2Shell the same as wp2shell?
No. wp2shell was a bug chain in WordPress core, CVE-2026-63030 and CVE-2026-60137, disclosed in July 2026 and fixed in WordPress 7.0.2, which WordPress.org pushed out through forced automatic updates. PHP2Shell is in PHP, so WordPress updates do nothing for it. Wiz has the wp2shell details.
Will a security plugin like Wordfence stop PHP2Shell?
Do not count on it. A WordPress security plugin runs as PHP application code, and the php.net advisory describes a mod_php exploit that fires before any application code runs. A firewall in front of PHP, at your host or CDN, can help as a stopgap. The fix is still the PHP update.
Do I need to update WordPress for PHP2Shell?
No. WordPress.org says no WordPress update is required or planned for these issues. Keep WordPress current anyway, because the next step, a PHP branch change, goes smoother on current plugins and core.
Is my WordPress.com site affected?
No action is needed. Automattic says WordPress.com, WordPress VIP, WP Cloud and Pressable sites were already protected on October 21, 2026.
How do I know my host has patched PHP?
Ask which PHP build serves your site and whether it includes the fixes for CVE-2026-109618 and CVE-2026-109619. On distribution builds a version number alone is not proof, because distributions backport security fixes into older version numbers.
What to do in the next hour
- Open Site Health and write down the PHP version and the PHP SAPI.
- If the version is below the fixed release, ask your host which PHP build serves the site and whether it includes the fixes for CVE-2026-109618 and CVE-2026-109619, or patch and restart PHP on your own server.
- If you are on PHP 8.1 or older, book the move to PHP 8.3 for this week, with a backup and a staging copy.
- Check administrators, checksums and the uploads folder back to October 17.
Then put PHP on the same list as plugins: something checked every month, with a named person who updates it.
