PHP2Shell, a pair of unauthenticated php remote code execution flaws in PHP's core, leaked online a day ahead of its planned disclosure, and PHP's own security team has confirmed that the interim workaround circulating since the leak doesn't actually close both bugs. CVE-2026-109618 and CVE-2026-109619 affect essentially every way PHP serves a web request, and emergency patches shipped October 21, 2026, after watchTowr and Cloudflare both reported active exploitation attempts before the fix was even public.
Jump to what we checked on our own PHP fleet if you run any web-facing PHP installation you haven't patched yet today.
What the PHP2Shell Vulnerability Actually Breaks
CVE-2026-109618 lives in how PHP handles running out of memory. When a request exceeds its memory limit, PHP aborts it mid-operation using a jump out of whatever it was doing, and in several places that abort leaves internal request data only half set up. Subsequent cleanup code trusts that invalid state as valid. PHP's own advisory confirms full remote code execution over HTTP against Apache's mod_php with default settings, triggered before any application code runs at all.
CVE-2026-109619 is a separate use-after-free: internal state owned by one request can survive after its backing memory has been freed, for example following a fatal error or an out-of-memory abort. A later request handled by the same worker process can read that freed memory before normal initialization resets it. According to PHP's own advisory, this path was confirmed through the fatal-error-backtrace feature enabled by default in PHP 8.5, and separately through session lifecycle handling on both mod_php and PHP-FPM.
Why the Leaked Workaround Doesn't Actually Work
The information that leaked a day before disclosure attributed the entire bug to PHP's session upload-progress feature and claimed that disabling it was sufficient. PHP's own advisory, published alongside the patch, corrects that: a second, independent use-after-free sits in the SAPI-level multipart form parser itself, and it triggers on any multipart/form-data POST request, with or without session.upload_progress enabled.
That means administrators who applied the leaked mitigation and considered themselves protected were still exposed. PHP's security team states plainly that configuration changes do not fully close either vulnerability, and that updating to a patched version is the only complete fix.
What We Checked on Our Own PHP Fleet
We checked every PHP-serving workload at Krova Cloud against the fixed version list the same hour the patch shipped, rather than waiting for a scheduled maintenance window. We found one internal admin tool still running PHP 8.2.33, two versions behind the fix, because its auto-update job only runs on a weekly schedule. We patched it manually and moved it to the same hourly check our customer-facing services already use.
What to Check in Your Own PHP Installations
- Confirm you are running PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, the only versions PHP's security team has confirmed as fixed; anything earlier on a supported branch is still exposed.
- Do not treat disabling session.upload_progress as sufficient protection, since PHP's own advisory confirms a second exploitable path exists independent of that setting.
- If you run PHP 7.4 through 8.1, check your Linux distribution's own security tracker rather than php.net, since those branches get only minimal source backports from the PHP project directly.
- If you're on PHP 7.3 or earlier, treat the server as permanently exposed, since those branches are end of life and will receive no fix at all, from PHP or most distributions.
The limitation worth naming honestly is how much confusion the leak itself caused. The leaked details got the severity wrong, inflated to CVSS 10.0 against an official 9.2, and got the cause wrong, pinning it entirely on one feature when a second independent bug existed the whole time.
The verdict here isn't that teams who applied the workaround were careless. They were following the best information available at the time, and it happened to be wrong in a way nobody could see from the outside.
This is the same shape as the BeyondTrust PAM backdoor I covered two posts ago: a standard-looking response step, rebooting the appliance there, disabling a feature flag here, that looks like it closes the gap but doesn't actually touch the real vulnerability underneath it.
The Rule
An interim mitigation built from leaked, incomplete information is not the same as a fix, even when it blocks the specific exploit sample everyone is looking at. CVE-2026-109619 had two independent paths to the same use-after-free, and a workaround that closes one path leaves a server exposed through the other with no visible warning that anything is still wrong. If your patch window for this one is "we disabled the setting, we're fine," you're running on the same bad information the leak started with.
Frequently Asked Questions
What is the PHP2Shell vulnerability?
A pair of critical, unauthenticated remote code execution flaws in PHP core: CVE-2026-109618, an out-of-memory handling bug, and CVE-2026-109619, a use-after-free involving state that persists between requests on the same worker. Both are rated CVSS v4.0 9.2 and affect any PHP installation serving web requests.
Which PHP versions are affected and which are fixed?
Everything before PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 is affected. PHP 7.4 through 8.1 get only minimal source backports from the PHP project, and PHP 7.3 and earlier are end of life with no fix planned at all.
Does disabling session.upload_progress protect my server?
No. PHP's own advisory confirms a second, independent use-after-free exists in the SAPI-level multipart form parser that triggers on any multipart/form-data POST request, regardless of that setting. Updating to a patched version is the only complete fix.
Is PHP2Shell being actively exploited?
Yes. watchTowr and Cloudflare both reported active exploitation attempts before the official patch was released on October 21, 2026, and Patchstack reported exploitation attempts against multiple hosting partners starting hours before the fix shipped.
I'm Rohit, founder of Krova Cloud: disposable VMs patched on the same hour a fix ships, not on a weekly cron job that misses the day it mattered. More debugging stories at debugly.dev.
Top comments (1)
Good write-up. One nuance for readers stuck on EOL versions: the ini switch falls short partly because it's PERDIR (a site's .user.ini can turn it back on), and partly because the advisories describe more routes than upload progress. We (Hosted Power, disclosure) published an open-source extension that goes further. It carries PHP's fixed multipart parser with a memory guard, keeps the upload-progress handler detached, mirrors the rest of the official fix, and steps aside on a patched PHP. It covers PHP 5.4 to 8.5, on Linux x86/ARM and Windows: github.com/HOSTED-POWER/php_upload.... It's not a substitute for the update, but an option between "unprotected" and "offline".