Discover how php2shell vulnerabilities expose PHP servers to remote code execution and how Harness virtual patching protects endpoints while you deploy fixes.
On October 21, 2026, the PHP project rushed out emergency patches for two critical flaws nicknamed php2shell (CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10). This isn't a bug in some plugin or a server someone set up wrong. It's in PHP itself, in the way the language has handled errors since 2012. The pieces of this attack have been sitting in the runtime behind a big chunk of the internet for over a decade, and nobody caught it until now.
How Harness virtual patching protects against php2shell
Patching PHP takes time. Distribution packages lag, old branches have no release, and every worker needs a restart. Attackers started probing before the patch even existed.
Virtual patching covers that gap by stopping the attack at the request layer while you roll out the fix. We have rolled out a php2shell WAF rule, and you don't need to run a scan to use it. You can create a virtual patch directly and apply the rule to any endpoint or service you know runs PHP. Start in Monitor mode, watch what the rule catches, and switch to Block once you trust it.
If you also use Harness API Security Testing, it now includes a php2shell check that helps you find exposed endpoints you might have missed. When a scan flags one, you click Create Virtual Patch on the issue, and the matching PHP attack and remote code execution rules come pre-selected and scoped to that environment and endpoint.
Every patch stays traceable. It stays linked to the finding that created it and shows up under Custom Signatures with its source marked as Virtual Patch. Each hit becomes a security event tied to the threat actor behind it, and the changelog records when the patch was created or changed. When someone asks whether a server was attacked before it was patched, you have the answer.
A virtual patch is a bridge, the same as any WAF rule. Blocking needs Harness deployed inline, and new php2shell variants will keep appearing. Use the virtual patch to protect exposed endpoints until every PHP install is updated and restarted.
PHP runs more of the web than you think
PHP is the quiet engine behind about 70% of the websites whose server software is known. WordPress, Drupal, Joomla and Magento all run on it, which covers a large slice of the world's blogs, news sites, online stores and company homepages. Most visitors never see it, and many teams running it have half-forgotten it is there.
That reach is what makes php2shell serious. One flaw in the runtime hits millions of unrelated sites at once. Around 5 million PHP servers facing the internet have been counted since disclosure. You don’t have to write insecure code to be exposed, you only have to run PHP.
How the week unfolded
Researchers at Wiz, Calif and OpenAI found the flaws. They say AI models helped them turn a subtle memory bug into working exploits in days rather than the months a team might need by hand. Then the disclosure got away from everyone: details leaked the day before the release, and PHP pulled its schedule forward to stay ahead of attackers.
What goes wrong
You do not need to read C to understand the shape of it.
When a PHP request runs out of memory, PHP does not tidy up and stop. It drops whatever it was doing mid-task and jumps to a recovery point, leaving its workspace half-finished: notes half-written, references pointing at things that no longer exist. Normally nobody notices, because the next step assumes PHP left everything tidy.
php2shell is what happens when an attacker picks the exact moment PHP trips. A specially shaped upload forces that out-of-memory stumble at a precise point. A second request then picks through the mess PHP left behind. Done carefully, the attacker can steer PHP into handing back snippets of its own memory, and eventually into running commands of the attacker's choosing.
Under the hood: two bugs, one root cause
Both CVEs share one root cause. When PHP hits a fatal error, such as running out of memory, it bails out. It jumps to the end of the request and skips the code that would put its workspace back in order. php2shell gives an attacker two ways to use that gap.
CVE-2026-109618: one request. An attacker sends an oversized upload that makes PHP run out of memory before it finishes setting up the request. PHP bails out, and its cleanup code then frees memory it never finished building. On Apache with mod_php, cleanup runs even after a failed startup, and all of this happens before the site's code loads. PHP-FPM tends to kill the worker at that point instead, so this path lands less often there.
CVE-2026-109619: two requests on the same worker. A PHP worker serves many requests in turn. During a request it keeps a few global pointers into that request's memory, such as the session upload-progress tracker, which PHP turns on by default. A request that dies partway through, from a fatal error, a timeout or the same out-of-memory trick, leaves those pointers aimed at memory PHP has already freed. The next request on that worker follows them. Security teams call this a use-after-free: code that keeps using memory after the program released it. This path works on PHP-FPM as well as mod_php.
Either path lets the attacker corrupt PHP's memory, and from there run code as the web server user.
A WAF rule can catch both paths at the edge, because the requests look odd before PHP parses them. Flag uploads with missing or misleading length headers, upload parts with an unusual number of headers or field names nested many levels deep, upload-progress fields sent to pages that never take uploads, and oversized session cookies. Attackers will change the shape of these requests, so the rule buys you time to patch.
Why this one is so dangerous
Three things make php2shell worse than the average vulnerability.
- No login required. The attack arrives as an ordinary web request. The attacker needs no account, no password and no help from the application.
- It fires before your code runs. On the most common Apache setup, PHP handles the malicious upload during its own startup, before a single line of the site's code executes. Well-written application code offers no protection.
- It leaves almost no trace. The server keeps answering requests as if nothing happened. The only sign in the logs is a routine out-of-memory error, the kind operations teams see every day and rarely investigate.
If an attack succeeds, the attacker runs commands as the web server. From there they can read database passwords, API keys and cloud credentials, reach the systems those unlock, plant a payment-card skimmer or a backdoor, and move deeper into the network. For a retailer that can mean mass card theft; for a hospital or a school, exposed patient or student records.
Who needs to worry
Anyone running PHP on a web server. The vulnerable code reaches back to PHP 5.4, so nearly every version still in use is affected. A few details change the urgency:
- Highest risk: Apache with mod_php. This is the classic setup behind countless WordPress and CMS sites, and the attack is easiest here.
- Also affected: PHP-FPM and the other runtimes (php-cgi, FrankenPHP, LiteSpeed). Exploitation is harder or less proven, but they are in scope.
- Old versions are the real trap. PHP 8.1 and earlier get no new official release, and a large share of PHP sites still run those versions.
The most exposed sectors run lots of PHP with generous upload limits and lean teams: ecommerce, media and publishing, education, hospitality, healthcare and shared hosting.
What to do now
Patch. It is the only complete fix. Update to the version for your branch, then restart the web server and workers. A running application does not mean the runtime reloaded.
On PHP 8.1 or older, there is no upstream release; lean on your distribution's backport or plan an upgrade. Check the package changelog for the CVE numbers, since vendors often patch without changing the visible version.
If you cannot patch this hour, these steps buy time but do not replace the patch: lower your upload and POST size limits, turn off upload-progress tracking and restart workers, and put a WAF rule in front of the exploit traffic. Treat any WAF rule as a bridge. php2shell is a property of the engine rather than one payload, so expect new variants. Only the patch closes it for good.
And start the inventory now. The hard part of a runtime flaw like this is finding every forgotten PHP install before an attacker does.
