PHP2Shell Scanning: How to Separate Exploits from Look-alike Traffic

PHP2Shell scans were appearing hours before PHP’s coordinated fix, but identifying real exploit attempts takes more than matching a tool name or an unusual request body. Fastly says its Next-Gen WAF telemetry recorded more than 100 source IPs using PHP2Shell-branded tools by the scheduled release on October 21, 2026. By midday the next day, its dataset included about 250,000 requests from roughly 3,200 public IP addresses. The practical challenge for defenders is separating exploit traffic from routine checks and look-alike requests.

Why request shape matters

PHP2Shell refers to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2. Both can allow unauthenticated remote code execution. One involves an out-of-memory condition that interrupts PHP while internal request data is only partly initialized; cleanup then relies on that incomplete data. The other leaves internal state pointing to memory that is no longer valid, which a later request on the same worker may use.

Neither issue depends on a distinctive payload string. The exploit relies on causing a failure at a particular point in request handling. That makes a single text signature a poor fit: defenders need to inspect how requests are formed, then look for evidence on the server that a worker failed or behaved unexpectedly.

PHP says all installations serving web requests are affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php as the most exposed configuration. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier have no upstream fix, so operators on those versions need to check whether their package distributor offers a backport or plan an upgrade.

Scanning started before the fix

The chronology helps explain why early requests were hard to interpret. The CVE identifiers began circulating on forums and social media around 15:00 UTC on October 20, initially with an incorrect release time and CVSS score. PHP published a pre-announcement at 19:30 UTC, setting the coordinated release for 14:00 UTC the following day. Around 20:00, a proof-of-concept video was briefly posted and then removed; copies continued to circulate. Around 23:00, mitigation advice shared with a small group of critical infrastructure providers may also have leaked, according to the source’s account of the disclosure.

Fastly saw no PHP2Shell-named tools in its telemetry during the period from midnight on October 20 through 03:59 UTC on October 21. The first such request arrived at 03:59. The first request from the most widespread exploit kit followed at 05:11, using the User-Agent PHP2 shell-109618 and multipart boundary B7kQpoc618. Chainguard published built images containing the fix at 07:41, more than six hours before the coordinated release. GitHub security advisories for both CVEs appeared at 13:34. At the scheduled 14:00 release, Fastly had observed more than 100 source IPs using PHP2Shell-named tools.

The IDs had circulated without technical details, and the first named tools appeared roughly eight hours after the proof-of-concept video. Fastly’s observations establish the sequence, but not what prompted any individual tool. Its figures are also limited to requests its WAF recorded.

Finding the exploit kits

Fastly collected about 250,000 requests from PHP2Shell-named tools between the first observed request and midday on October 22. Roughly one third identified themselves as defensive checks, using descriptions such as “authorized exposure check,” “patch-state check” or “non-exploiting.” Those labels cannot prove intent, but the requests matched the pattern of small, harmless probes. The remainder included a mix of tools that changed quickly: one PHP version-inventory tool moved from version 4.0 to 7.2 in about eleven hours.

PHP2Shell-named requests by tool type, from October 21 at 03:59 UTC to midday on October 22. Figures are rounded.

For exploit hunting, the strongest clue Fastly found was the multipart boundary in the Content-Type header. Each identified kit used a fixed or patterned boundary. Fastly identified more than ten candidate kits this way, with five linked to PHP2Shell by name, User-Agent or behavior.

The most widespread example sent POST /index.php or POST /, used the User-Agent php2shell-109618, and set the boundary to B7kQpoc618. Its request had a fixed-size multipart body and few headers. It addressed raw IPs rather than hostnames and sent one or two requests per host, a pattern consistent with scanning broadly across IP space. Body sizes differed substantially between kits, so a size threshold alone can miss relevant traffic or catch unrelated requests.

User-Agent signatures can become stale within a day when tool versions change this quickly.

Two sources of false matches

React2Shell, CVE-2025-55182, accounted for most matches to two request patterns that were circulating as PHP2Shell indicators: chunked multipart requests without a Content-Length header and bodies padded with long runs of the letter A. In a measured hour, React2Shell represented 98.6% and 99.9% of those matches, respectively. The padding pattern was already 99.7% React2Shell in the same hour the previous day.

React2Shell share of two circulating PHP2Shell signatures, measured by the Next-Action header on POST requests to PHP endpoints from October 21, 21:00–22:00 UTC. In the matching hour the previous day, the padding signature was already 99.7% React2Shell.

The useful separator is the Next-Action request header, used by Next.js Server Actions and not by PHP. React2Shell also sends requests to many paths, including /xmlrpc.php and /wp-login.php.

A second look-alike is wp2shell, which targets a separate unauthenticated remote-code-execution flaw in WordPress core disclosed in July 2026. Its kit sends large multipart requests to WordPress index.php with a boundary beginning ----wp2shell. It was active before PHP2Shell became public. Counting those requests as PHP2Shell would distort the timeline.

A request-shape signature identifies a kind of request, not who sent it. Compare activity with a pre-disclosure baseline, then divide apparent matches by identifying headers and boundaries before assigning them to a vulnerability.

What edge data can confirm

Edge telemetry can show that an exploit attempt reached an application, but it can’t establish whether the attempt succeeded. A successful request and a failed one may look alike from outside because the flaw can crash or corrupt a PHP worker. If an application may have been targeted, check the origin: PHP-FPM error logs, Apache error logs for worker crashes such as AH00051 child-process exit-signal entries, and unexpected outbound connections from PHP workers. A connect-back shell would appear as outbound traffic from the origin.

Fastly observed dozens of named tools and traffic from roughly 3,200 IPs within about a day of the first tool appearing. That pace does not establish whether the tools were written with AI. The observed requests used familiar scanning patterns and infrastructure, including VPN and hosting services. Defensive work also remained hands-on: teams checked their own systems, compared indicators with baseline traffic, patched software and reviewed origin logs. Automation can help, but choosing the right signals still takes careful analysis.

Actions for PHP operators

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the patched package supplied by your distributor. For PHP 8.1 and earlier, ask the distributor about backports or move to a supported fixed release. In logs, prioritize multipart boundaries and request structure; treat User-Agent strings, source IPs and body size as supporting clues. Check for React2Shell and wp2shell before attributing a match to PHP2Shell.

Be cautious with IP blocklists. Fastly says some addresses on lists circulating for this issue belong to VPN or Tor exits, residential services and mobile networks, where blocking can affect ordinary users. Fastly Next-Gen WAF customers can opt in to the CVE-specific Templated Rule covering both PHP vulnerabilities. The rule acts as a virtual patch by looking for structural signs of exploitation. Fastly also recommends considering its Automatic CVE Virtual Patching setting in Workspace Configuration.

Fastly’s post on proactive protection

Indicators and measurement

Fastly’s figures come from Next-Gen WAF request telemetry recorded from October 20 through October 22, 2026. Disclosure timing draws on the PHP Foundation’s postmortem and GitHub advisory records. Counts are lower bounds: they include only requests the WAF saw and retained, and some header-level comparisons use selected sample hours rather than full days.

The useful takeaway is operational: patch the affected PHP versions, use request boundaries to refine edge detection, and inspect origin logs to determine whether a worker was affected. Fastly’s protection notes for CVE-2026-109618 and CVE-2026-109619 contain further details.