PHP2Shell: How to Stay Ahead of a Zero-Day, from Asset Discovery to Threat Hunting

Critical vulnerabilities in PHP, the scripting language behind roughly 70% of the world’s websites, triggered emergency shutdowns of banking, airline, rail, tax and government services this week while they tested their systems and implemented appropriate patches.

The disruption stretched from Tokyo to Helsinki. “I’ve not seen anything like this in a long, long time,” said Microsoft CEO Satya Nadella.

Teams at OpenAI, Google-owned Wiz and a company called Calif uncovered the flaws, collectively referred to as PHP2Shell. Every PHP release from the past decade, back to version 5.4. carries at least one flaw. The two vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619.

What is PHP2Shell?

PHP2Shell is a pair of unauthenticated remote code execution flaws in the PHP core:

• CVE-2026-109618 (out of memory during request setup). An out-of-memory condition while PHP sets up a request leaves the request data partly built. The unfinished request can lead to code execution, or to server memory leaking back in the response.
• CVE-2026-109619 (stale state reused after free). PHP may retain references to request data after its underlying memory has been freed. Subsequent requests handled by the same worker can access these stale references. PHP's session upload progress feature is one confirmed path.

The defects sit in the scripting language itself, not in any application built on it. As a result, every web-facing PHP deployment running an affected version faces immediate risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Updating WordPress, Drupal or a framework does not fix the flaws; the PHP runtime itself has to be updated.

Threat actors can exploit the flaws remotely and seize control of a web server without presenting a single credential. A compromised server opens several paths for intruders, who can steal sensitive data, deface websites, disrupt services, or move deeper into the network.

The PHP project has released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and administrators must apply the updates to resolve the flaws.

Exploitation attempts began before the patch

Details of the flaw appeared to go public ahead of the patch. Exploitation began before a fix existed. On October 17th, Amazon’s Chief Information Security Officer, CJ Moses, reported that the company’s security team caught a PHP2Shell attempt in a monitoring system that was designed to bait hackers. A patch arrived on October 21st, four days after Amazon’s first detection.

Cloudflare CEO Matthew Prince described the surge across his company’s network. “In the 10 hours before it was publicly announced across the network, we saw thousands of attempts to exploit it.”

“That jumped to tens of thousands in the 45 minutes post announcement…” Prince said.

Sites went dark worldwide

Government and company websites around the world went dark as organizations moved to reduce exposure.

• Asia-Pacific: Japanese services including pixiv, Niconico, shop builder BASE, e-book store BOOK☆WALKER and several mobile games went into emergency maintenance on October 21 so operators could apply PHP’s emergency patches. pixiv’s maintenance ran into the early morning of October 22.
• United States: HR software provider BambooHR took its service offline across the United States, Canada and Ireland on October 21, warning that payroll would be interrupted. For its customers, a flaw in a programming language became a payroll disruption.
• Europe: Sites for Edinburgh and Oxford councils and London’s Metropolitan Police were reported unavailable, while the Netherlands pulled DigiD, its national login service, and its cyber agency’s own site. Finland, France, Denmark and Germany also took government services offline.
• Latin America: Brazil’s telecom regulator Anatel suspended its SEI electronic case-management system from 12:15 to 22:05 on October 21 as a precaution, and federal SEI systems were also pulled offline. Anatel told CNN Brasil there was no sign of intrusion.

“While vendors work to patch their individual software packages, it is important for organizations to assess whether additional mitigation steps should be taken…” CISA wrote.

Why patching can’t keep up

Jamie Moles, senior technical manager at ExtraHop, points to legacy software as the culprit behind the crisis. Roughly 45% of PHP websites run an outdated version of the codebase, leaving legacy sites exposed to flaws present in every release back to 5.4.

Moles is skeptical of the shutdowns. “Taking affected sites offline may offer a quick fix, but it is a stopgap for a problem of such breadth”, said Jamie. The larger challenge is tempo. “AI is accelerating vulnerability discovery every day, and attackers will race ahead of patching and upgrade cycles for legacy software. Defenders need to move at the speed of AI-powered adversaries”.

Sarah Cleveland, ExtraHop’s Senior Director of Federal Strategy, has reached the same conclusion from a government vantage point. A former U.S. Air Force Colonel, Cleveland oversaw network security and 1,500 personnel. “Patch Tuesday is obsolete,” she said in an interview.

And PHP affects more than just websites, there are components in firewall management interfaces, security platforms, and more. It's not a "one patch fixes all" in this case. PHP2Shell highlights a software supply-chain and patch-dependency problem, as products can "inherit" vulnerabilities from underlying software components. These rely on vendor-issued fixes or firmware updates, even in highly specialized devices.

Can your organization spot an intruder who got in before the patch? 

A patch resolves a vulnerability. However, the network shows whether or not a threat actor exploited the vulnerability ahead of a patch. In ExtraHop's 2026 Global Threat Landscape Report, 49% of organizations said they did not detect an intrusion until after data had been stolen; up from 31% the year before.

Attacker movement after a compromise requires network communication across internal systems. Reconnaissance, privilege escalation, database queries and staging data for exfiltration all generate network traffic. Application logs and web application firewalls often miss this exploitation, because the flaws can trigger before any application code runs.

The network does see the exploit requests. By observing real-time network activity, defenders can see exploits as they happen, including zero-days like PHP2Shell.

What to do this week

Five questions turn a headline into a board-ready answer:

1. Do we know every PHP web server we run? Including servers behind load balancers, in the cloud and in business units that may never have been mentioned to the IT department. An inventory nobody has checked against live traffic is just an estimate.
2. Can we see the traffic going to our PHP servers, including encrypted traffic? Encrypted traffic that stays opaque to detection tools hides the exploit.
3. Were we hit before October 21st? How long will it take to answer "are we affected?", and will the answer hold up with auditors, regulators and the board?
4. If an attacker planted a web shell, would we see where they went next? The web server is rarely the target. The databases and the identity systems behind it are.
5. Is our detection independent of the systems the attacker controls? An attacker on a server can switch off the server’s agent and wipe the server’s logs. Out-of-band network evidence stays beyond the compromised server’s reach.

Research at the speed of the threat

ExtraHop researchers went from public disclosure to a field-ready PHP2Shell detector in days. Each stage of the published exploit chains has its own detection. The detector was validated against live attack replays on two of the most common PHP stacks and tuned against real-world traffic. ExtraHop RevealX customers install the detector through a single bundle import. It doesn’t need an agent, a new log source, or changes to applications.

The section below walks analysts and engineers through putting the detector to work.

How ExtraHop detects PHP2Shell at every stage of an attack

ExtraHop supports defenders with four layers of visibility:

1. Rapid asset discovery
2. Real-time detection of exploitation attempts
3. Identification of post-exploitation activity and lateral movement
4. Forensic and historical threat hunting

All detection described below comes from network traffic observed by agentless, out-of-band RevealX sensors, which run at up to 400 Gbps.

1. Find every PHP server

• Uncover hidden PHP footprints: In large environments, tracking every legacy PHP application or third party web tool is notoriously difficult. RevealX continuously parses network traffic in real time to identify every active web server, and the software behind it, across hybrid cloud and on-premises data centers. A new server is visible the moment it starts communicating, not on the next scan cycle.
• Follow coverage automatically. The PHP2Shell detector bundle installs a dynamic "HTTP Servers" device group. Detection coverage extends to every new web server as soon as it appears, with no list to maintain.
• Prioritize patching. Use the inventory to find exposed PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed services, and patch the public-facing portals first.

2. Catch exploitation as it happens

• The ExtraHop php2shell detector (version 1.2.1) is a RevealX trigger that runs on the sensor. It inspects HTTP requests, responses and connections to web servers. It ships seven custom detection types. All seven are in the Detection Catalog under the category Exploit and are mapped to MITRE ATT&CK T1190 (Exploit Public-Facing Application). Each one carries a risk score from 30 to 90.

Each stage of the published exploit chains has its own detection:

Paired detection. Most exploit chains need a second request. When a crashed request is followed by later-stage activity between the same client and server within five minutes, the detector raises the unparsed request at risk 90. Two linked indicators are stronger evidence than one loud one.

What each detection looks for

• Unparsed out-of-memory request (CVE-2026-109618). The out-of-memory attack sends one multipart part with thousands of headers, slowly, one header per packet. The flood isn't well-formed HTTP, so the detector judges the connection itself. The detection looks for more than 1 MB sent by a client on an HTTP connection, where less than half of it is readable as HTTP requests. The pattern is raised at risk 80 when the packets are small (under 200 bytes of payload on average) and the server sends nothing back. Shapes from the PHP advisory are also flagged at 65: a chunked form body over 8 MB, or a field name nested 32 or more levels deep. Oversized field names are raised at 30, as possible reconnaissance.
• Multipart crash (CVE-2026-109618). The detection pairs a multipart request (more than 20 parts or more than 8 MB) with a 5xx or aborted response. It ships switched off: real attack requests are not well-formed HTTP, and failed large uploads can trip it. The unparsed-request detection covers that traffic.
• Upload progress race (CVE-2026-109619). The detection watches multipart requests that carry the PHP_SESSION_UPLOAD_PROGRESS field. A lone hit (risk 40) is expected on a site with a progress bar. A burst is raised at 90: 10 or more from one client to one server within 5 seconds, or 6 or more within 1 second. A PHPSESSID containing characters PHP never issues, which exploit tooling used to prime the race, is raised at 70. The thresholds follow Talos SID 67360. Always investigate a burst.
• Serialized key collision (Talos SID 67359). The detection matches the serialized PHP array that exploit tooling sends: the colliding integer keys i:4294967296; i:8589934592; i:12884901888; in sequence, written literally or percent-encoded. The match carries a high-confidence match with no legitimate use.
• Session cookie memory leak (CVE-2026-109618). This is raised on the server's response, not the client's request. It flags a Set-Cookie PHPSESSID that PHP could never have issued: characters outside every PHP session ID format, or a value longer than 256 characters. Because it reflects what the server actually sent back, it is strong evidence that the server leaked memory. Check the PHP version on the victim.
• Upload filename injection (exploit chain: plant). PHP copies an upload's filename into the session's upload progress record, and exploit chains use that to plant code. The detection flags a PHP open tag (<?) or a serialized object marker (|O:) in a filename, and filenames of 10,000 or more characters sent with the progress field. Legitimate applications have no reason to do this, so always investigate.
• Session file include (exploit chain: run). The detection flags a request that names a PHP session file by path (sess_ followed by a session ID) under /tmp, /var/lib/php or a sessions directory, or through a ../ traversal. The detection is raised in real time on the request that runs the code. A 200 response is the strongest sign in this detector that code actually ran.

Why connection-level detection matters

The first version of the detector was built from the published Talos rules, and it missed every out-of-memory request in the lab replay. The reason became the key finding of the project: the most dangerous requests weren't readable as normal HTTP, which left rules that watched only HTTP transactions blind to requests. Comparing what each client sent with what was readable as HTTP caught them at the connection level. The next version caught 207 of 208 malicious requests.

The research produced several lessons analysts can apply beyond PHP2Shell:

• Shape beats size. Attack floods ran 74 to 117 bytes per packet. Ordinary large uploads ran about 1,430.
• Silence is a signal. PHP sends nothing until it has read the whole flood. Across all 263 attack connections, the server's share of the traffic was under 0.06%. Real conversations get answers.
• Status codes lie. The same crash returns a 500 or a 200 depending on PHP's error settings. Detections that rely on spikes in 5xx errors alone will miss attacks.
• Judge on what's on the wire. Buffering in nginx changes what reaches PHP, so the same attack looks different on different stacks.

3. See what comes after the shell

Once an attacker triggers the vulnerability to drop a web shell, the threat moves from web traffic to internal network behavior. NDR excels at catching post-compromise behaviors: 

• Suspicious outbound connections: If a compromised PHP worker process establishes an outbound connection to an unauthorized C2 server, ExtraHop detects this unexpected session.
• Interactive web shells: ExtraHop monitors internal traffic for anomalous base64-encoded commands in headers or non-standard file paths.
• Lateral movement: In highly targeted environments like financial services, compromised web servers pivot to back-end databases or Active Directory. RevealX decrypts and inspects the identity protocols attackers rely on, including Kerberos, NTLM and LDAP. RevealX flags non-standard SSH or RDP connections and SMB credential dumping that originate from these web servers. More than 450 detectors, mapped to more than 150 MITRE ATT&CK techniques, cover the behavior that follows the exploit.

4. Look back before disclosure

Exploitation began before public disclosure. RevealX's continuous packet capture and record retention let teams rewind network history. Automated Retrospective Detection (ARD) re-checks stored traffic when new indicators emerge and every detection links to the transaction records and the packets behind it. ExtraHop has published suggested historical searches to help analysts hunt for exploit signatures from the days and weeks before the patch announcement. Useful starting points:

• Client connections to web servers that sent more than 1 MB in small packets and received almost nothing back.
• Bursts of multipart requests carrying PHP_SESSION_UPLOAD_PROGRESS from a single client.
• Set-Cookie PHPSESSID values longer than 256 characters, or with characters PHP never issues.
• Request URIs or query strings containing sess_ paths, or ../ traversal toward session directories.
• New outbound connections, or new east-west connections to databases and domain controllers, from any web server that matched one of the patterns above.

Triage guidance for analysts

• Read detections as attempts, not compromises. A detection shows that an attempt was seen, not that the server was vulnerable or breached. Check the victim's PHP version first.
• Know which detections to escalate. A Session File Include with a 200 response, a Session Cookie Memory Leak, or a paired detection at risk 90 calls for immediate escalation. Isolate the server, preserve the packets, and hunt for lateral movement from that host.
• Know the attribution. On every detection, the client is the offender and the server is the victim. Repeat activity between the same pair merges into one ongoing detection per hour, on any port.

Prerequisites, tuning and known limits

Prerequisites

• The sensor must decrypt HTTPS. Traffic it can't decrypt isn't inspected.
• Confirm that the "HTTP Servers" device group includes your PHP servers, including any behind a load balancer.
• Set L7 Payload Bytes to Buffer to 16384. The default of 2048 is too small for multipart requests.
• Add web vulnerability scanners and load testers to EXCLUDE_CLIENTS.

Tuning (one settings block in the trigger; make narrow changes first)

• RAISE: one switch per variant. A switched-off match still logs when debugging is on.
• PAIR_WITH: sets which follow-ups can complete a paired detection. It works independently of RAISE.
• EXCLUDE_CLIENTS: lists addresses or IPv4 blocks that never raise or pair a detection.
• UNPAIRED_RISK: ships at 0. Set it above 0 to also raise unpaired, full-size unparsed connections. CDNs, printers and one-sided captures cause most of those.

Known limits

• Only the first 16 KB of each request body is guaranteed to be inspected.
• Behind a CDN or reverse proxy, the two halves of an attack can arrive from different addresses, so they won't pair.
• Variants that change the published request shapes may not be detected. Some CVE-2026-109619 paths leave no network signature. Patching remains the remediation.

How the detector was built and validated

ExtraHop built the detector with a repeatable process that went from disclosure to field-ready detection in days:

1. Researchers studied PHP's advisories, the fix commit and its roughly 100 out-of-memory regression tests, and six same-day public proofs of concept.
2. They built an isolated lab of unpatched PHP 8.4.26 servers on Apache with mod_php and on nginx with PHP-FPM, watched by a standard RevealX sensor. A traffic generator replayed realistic attacks alongside a benign twin for every attack shape, and logged every request as ground truth.
3. An offline harness of 119 test cases runs the shipped script before every deploy, and each release is rescored live before its bundle is exported.

The final round on version 1.2.1 produced these results:

• 207 of 208 malicious requests flagged across six attack phases.
• 6 of 6 lone out-of-memory floods raised on both stacks.
• The full plant-and-run chain caught in real time.
• No unparsed-request detections from any benign control.
• Zero trigger exceptions.

Early field deployments then removed false positives from CDNs, printers, scanners and etcd peers.

The team used AI-assisted engineering to compress each score, fix and retest round to minutes. Two engineering agents split the work: one owned the trigger and scoring, the other owned the attack traffic. An ExtraHop engineer directed both agents and made every release decision. It is the same principle ExtraHop applies to the agentic SOC: AI moves fast, and the decisions stay defensible.

ExtraHop supply chain

ExtraHop engineering teams conducted a thorough review of RevealX dependencies to verify that the RevealX platform does not rely on vulnerable PHP implementations.

Learn more

To learn more about attackers use web shells and internal pivots after exploiting a zero-day, read ExtraHop’s NetScaler Exploitation, Hidden Web Shells, and Internal Pivots and learn how ExtraHop detects each stage of an attack.