On October 21, the PHP project shipped emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, now known as “PHP2Shell.” Both are rated CVSS 9.2, and both let an unauthenticated attacker run code on a web server. No stolen credentials, no phishing. Just one crafted request.
The same day, CISA urged organizations to patch immediately. The FBI, CERT-EU and the UK’s National Cyber Security Centre added a fallback for anyone who couldn’t: take the system offline, or isolate internet-facing applications from public networks, until it can be fixed. That fallback is worth reading twice. When the agencies responsible for national cyber defense run out of options, their answer is to get the server off the public internet.
The blast radius is enormous. Every common way of serving PHP is affected, from Apache mod_php to PHP-FPM, LiteSpeed, and FrankenPHP, and every application built on PHP inherits the flaw, including WordPress, Drupal, Joomla, and Magento. Palo Alto Networks counts more than 22 million potentially exposed instances.
Why PHP2Shell Is Worse Than Usual
Attackers moved first
Amazon observed an exploit attempt four days before public disclosure, and exploit attempts climbed into the millions after the patch shipped. Unit 42 attributes at least one intrusion to an agentic attacker that reached MFA secrets roughly two hours after getting in.
Your login page can’t help
On mod_php, the flaw can trigger before any application code runs. App-level authentication and MFA never get a vote.
Legacy PHP is left behind
PHP 7.4–8.1 received only do-it-yourself source patches, and PHP 5.4–7.3 is end-of-life with no upstream fix, yet countless business-critical apps still run there.
The treadmill never stops
Two days after the emergency patches, PHP disclosed a third remote code execution flaw, CVE-2026-115560, separate from PHP2Shell and dependent on configuration. Patch, redeploy, repeat. Patch now. But patching is a race, and with PHP2Shell you started from behind.
Change the Question
Every PHP2Shell attack begins the same way: an anonymous request reaching a public server. So instead of asking, “Is my server vulnerable?” ask, “Can an attacker even reach it?”
Meet Dispersive® Stealth Networking: Applications Attackers Can’t Find
Most security tools determine access. They decide what happens once a request arrives. PHP2Shell exposes the gap in that model, because the attack lands before any access decision is made. Dispersive® Stealth Networking works one step earlier, on whether the application can be found and reached at all.
Dispersive Stealth Networking is a preemptive approach to that problem. Built on DARPA-origin research and inspired by military-grade spread spectrum techniques, Dispersive’s patented multipath software obfuscates and splits traffic across dynamically changing channels, so the networks and applications it protects remain virtually invisible and resilient by design. Rather than detecting an attack and responding to it, Dispersive removes the target.
Dispersive is a lightweight overlay. It works alongside the web servers, web application firewalls, identity providers and patch processes you already run, requiring no rip and replace. You can deploy it as DispersiveCloud® or on premises as DispersiveFabric™, and either way you control how it runs.
For PHP applications in the path of PHP2Shell, that comes down to three things:
No public footprint
Protected apps have no open inbound ports and no internet-facing address. The scanners hunting for those 22 million servers find nothing.
Verify before you connect
Users and devices are authenticated before a single packet reaches your server, so a “no login required” exploit is useless to an outsider.
Multipath by design
Traffic is split across multiple encrypted paths, leaving no single stream to intercept or target.
What About Sites That Have to Stay Public?
Your storefront’s public pages still need prompt patching. But the admin consoles, CMS back ends, database tools like phpMyAdmin, and internal APIs behind it don’t need to be public at all. Move them behind Dispersive and your exposed footprint shrinks to only what customers truly need, while the systems that hold the keys to your business disappear from view.
One caveat matters. Hiding an admin URL that lives on the same server as public PHP pages does not protect that server from PHP2Shell, because the public pages remain an entry point. Protection is strongest when back-office tools run on separate infrastructure. If yours don’t, PHP2Shell is a good reason to separate them.
Buy Back Your Timeline
Dispersive doesn’t replace patching. Instead, it changes who sets the schedule. You patch when you’re ready, not when attackers are. Legacy apps that can’t be upgraded stay protected. And when the next CVE drops, as one did just two days later, your hidden apps aren’t on anyone’s target list.
PHP2Shell FAQ
What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, disclosed and patched on October 21, 2026. Both are rated CVSS v4.0 9.2 and allow an unauthenticated attacker to execute code on a web server running PHP. CVE-2026-109618 stems from out-of-memory handling that can leave PHP’s internal request data only partly initialized. CVE-2026-109619 is a stale-state flaw in which a later request can run into internal state left behind by an earlier one.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fixes. PHP 7.4, 8.0 and 8.1 have minimal source backports only. PHP 7.3 and older has no upstream fix. If you use distribution packages, confirm the CVE numbers appear in the package changelog rather than relying on the version string.
Is PHP2Shell being exploited?
Amazon recorded an exploitation attempt on October 17, 2026, four days before disclosure, and multiple security firms reported broad exploitation attempts after the patches shipped. CISA had not observed exploitation as of its October 21 alert. Treat any unpatched internet-facing PHP system as a likely target.
Does disabling session.upload_progress fix PHP2Shell?
No. Disabling session upload progress blocks only one confirmed path for CVE-2026-109619 and does nothing against CVE-2026-109618. Configuration changes reduce exposure while you patch; they are not a fix.
Can stealth networking replace patching?
No. Stealth networking removes applications from public reach so attackers cannot send the requests that trigger the flaw. It is an additional layer that buys time and shrinks the attack surface. Public-facing systems still need to be patched.
Take the Next Step
The next PHP2Shell is already being written. Take the applications that don’t need to be public off the public internet before it lands.
📞 Schedule a briefing with Dispersive’s architects to assess your exposure and map a deployment path. www.dispersive.io
Sources
Header image courtesy of Pixel from Pixabay.
