php2shell (CVE-2026-109618 + CVE-2026-109619): unauthenticated RCE in PHP core, now detected by Escape
php2shell is a pair of critical memory-safety vulnerabilities in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619. Escape detects affected PHP versions across your attack surface and shows you every exposed asset that needs the patch.
php2shell is not a WordPress bug, a Drupal bug, or a bug in your code. It is in PHP itself. Both CVEs trace back to the same weakness: when a fatal error, usually out of memory, interrupts a request, PHP destroys the request heap but leaves some global state pointing at the memory it just freed. A later request on the same worker trusts that state.
Researchers turned this into unauthenticated memory disclosure and remote code execution as the web server user. No login, no plugin, no application flaw. Every PHP release back to 5.4 is affected by at least one of the bugs.
The fixes are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026, a day earlier than planned after news of the vulnerabilities leaked. PHP 8.1 and older get no official fix, and early exploitation attempts are already being reported.
Escape Attack Surface Management fingerprints PHP across your exposed assets and flags every one running a version in the affected range, so you see your full php2shell exposure in one place instead of rebuilding an inventory by hand.
php2shell at a glance
What happened
On 21 October 2026, PHP shipped emergency fixes for two critical vulnerabilities in the PHP engine, the layer that runs underneath WordPress, Drupal, Magento, Joomla and most of the PHP code on the web. The release came a day earlier than planned, after news of the bugs leaked on 20 October.
The flaw is in how PHP cleans up when a request runs out of memory. PHP throws away that request's memory but keeps some pointers to it. The next request handled by the same worker trusts those pointers. So an attacker can send one request to put PHP in that broken state, then follow up with requests that read the server's memory or take control of it.
Essentially you need nothing else. No login, plugin, or bug in your code. Any simple string sent to an affected PHP version is enough to do some damage.
The vulnerabilities were found by Wiz Research and reported to PHP on 24 August 2026.
How php2shell works
The bugs are in how PHP cleans up after a fatal error, most often running out of memory. When that happens partway through a request, PHP throws away the request’s memory but leaves some internal pointers still aimed at it. Since PHP workers serve request after request, the next one on the same worker can pick up those stale painters and treat whatever now sits in that memory as real PHP data.
So by controlling what lands there, an attacker can control what PHP does next.
The most direct way in is through session upload progress, which is switched on in a default PHP install:
- The attacker sends a file-upload style request (multipart/form-data) to any PHP page. PHP reads and processes that request body before any of your code runs.
- The request is built so PHP runs out of memory at a chosen point. PHP aborts the request but leaves stale pointers behind.
- The attacker sends follow-up requests that land on the same worker. Through one stale pointer, PHP sends chunks of server memory back to the attacker inside the PHPSESSID cookie. That leak also reveals where things sit in memory, which removes the guesswork from the next step.
- Through another stale pointer, the attacker overwrites PHP's internal state and gets code execution on the server.
Two more bugs reach the same result by different routes: one in OPcache, PHP's shared cache of compiled code, and one in a new fatal-error backtrace feature that only exists in PHP 8.5. That is why switching off session upload progress narrows the attack but does not close it.
Because all of this happens while PHP is still setting up the request, your application code never gets a say, and neither do security plugins or anything else that runs inside PHP. Researchers also showed the same exploit working against stock WordPress, Drupal and Joomla installs.
Which assets are exposed
Anything that serves web requests through an affected PHP version, whatever is running on top of it:
- Affected versions: PHP 5.4 to 8.1, 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. Every version in that range is affected by at least one of the bugs.
- Affected server setups: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
- End-of-life PHP: 8.1 and older get no official release. PHP published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors will ship their own, but a lot of old PHP will simply stay vulnerable.
- PHP that doesn't look like PHP: hosting control panels like cPanel and Plesk, vendor appliances, Windows software that bundles its own php-cgi.exe, and internal admin tools.
- Anything that drifts: container images pinned to an old base image, marketing microsites, support portals, staging environments left online, and domains that came with an acquisition.
How it could impact you
Attackers can run code on your server. On an affected version, a successful exploit gives an unauthenticated attacker code execution as the web server user. From there they have your database credentials, your application secrets, and a foothold into whatever that server can reach.
Attackers can read secrets without running code. One of the bugs leaks raw server memory back in a cookie. That memory can contain passwords, session tokens and API keys from other people's requests, so an attacker can hijack sessions or log into connected services without ever running code on the box.
Your application doesn't matter, only your PHP version does. Researchers demonstrated working exploits against stock WordPress, Drupal and Joomla, but the bug is in PHP, so any PHP application is in scope.
Some versions will never get an official fix. PHP 8.1 and older are end of life. They are affected and get no official release, only minimal source backports for 7.4, 8.0 and 8.1.
It is already being targeted. Cloudflare reported early exploitation attempts before the patch shipped.
The hard part is finding your PHP
Knowing where to patch is the most crucial, and most difficult, factor here.
PHP rarely shows up on an inventory in an obvious way. It appears as the marketing site, support portal, a vendor appliance, a container image nobody rebuilt in a year, or a domain name that came during an acquisition. And checking the version from the outside also isn’t straightforward. Many servers hide their PHP version or report a version that looks vulnerable when the fix has already been backported.
So the first question to ask is where do we need to fix it, not how do we fix it.
How Escape helps
Escape Attack Surface Management discovers the assets on your external surface, identifies the PHP version each one is running, and flags every asset in the php2shell affected range. You get one list of what is exposed, instead of a week of chasing teams for spreadsheets.
From there:
- Each finding goes to the team that owns the asset, with the detected version and the release to upgrade to, so it doesn't stall in triage.
- Coverage is continuous. A rebuilt container, a restored backup or a newly discovered subdomain running old PHP gets flagged, instead of quietly putting you back in scope next month.
- Treat a version match as a strong lead for something vulnerable. Though to note, for distro-packaged PHP, confirm the package version on the host before closing or escalating the finding.
What to do now
- Patch. Update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then restart every PHP worker, because running workers keep the old code. For distro packages, follow your vendor's advisory. Rebuild container images from patched base images.
- If you can't patch today, reduce exposure. Set session.upload_progress.enabled = 0 in php.ini or the FPM pool config and restart workers. Keep post_max_size low and enforce request-size limits at the web server or proxy. If the application doesn't need file uploads, block multipart/form-data requests to PHP at the WAF. None of this is a fix. PHP says updating is the only complete one.
- Get end-of-life PHP off the internet. PHP 8.1 and older won't get an official release. Upgrade it, rebuild it with PHP's source backports, or take it offline.
- Check for compromise. On any internet-facing asset that ran an affected version, look for PHP processes spawning shells or download tools, new files in the web root, and new accounts or cron jobs. Rotate the secrets that server had access to.
- Find every instance. Inventory every PHP asset across your surface, including the ones nobody thinks of as PHP, and keep checking so old versions don't creep back in.
Finding one PHP server is easy. Finding all of them, on every domain and every version, is what decides whether php2shell is a patch window or a breach.
If you're interested to see Escape do it live, book a demo with one of our product experts.
FAQ
What is php2shell?
php2shell is the name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. They let an unauthenticated attacker read server memory or run code on any server running an affected PHP version, regardless of the application on top.
Is php2shell being actively exploited?
Early exploitation attempts have been reported. Cloudflare said it was seeing attacks emerge before PHP shipped the patch on 21 October 2026. Treat exposed, unpatched PHP as targeted.
What PHP versions are affected by php2shell?
PHP 5.4 to 8.1, 8.2.0 to 8.2.34, 8.3.0 to 8.3.35, 8.4.0 to 8.4.26 and 8.5.0 to 8.5.11 are affected. The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and earlier get no official release.
Is my WordPress site vulnerable to php2shell?
It depends on your PHP version, not your WordPress version. php2shell is in PHP itself, so any WordPress, Drupal, Joomla or other PHP site on an affected PHP version is in scope.
Can Escape detect php2shell?
Yes. Escape Attack Surface Management identifies every exposed asset running an affected PHP version and routes the finding to the owning team with the fixed release attached.
Does disabling session.upload_progress fix php2shell?
No. It blocks some known attack paths but not all of them. PHP's position is that updating is the only complete fix.
What's the CVSS score of php2shell?
Both CVE-2026-109618 and CVE-2026-109619 are rated 9.2 critical under CVSS v4.0 by the PHP security team.