PHP2Shell Exploitation Update: Mass Scanning, No Confirmed Compromises
This is an update to our October 21 advisory.
When PHP shipped an emergency fix for PHP2Shell on October 21, we expected a rush of exploitation. We got a rush of probing. In the eight days since our protection has logged more than 2.3 million requests that match PHP2Shell tooling or request shapes, across 62 hosting providers, and we have not attributed a single compromise to the vulnerability. This post covers what we've seen so far.
Why PHP2Shell looked like a mass-exploitation event
The disclosure had every ingredient of a mass-exploitation event:
- Unauthenticated remote code execution. Both CVEs (CVE-2026-109618 and CVE-2026-109619) are rated CVSS v4 9.2 and need no login.
- Proofs of concept in public before the patch. Details leaked a day before the release, and proof-of-concept code was circulating soon after.
- A huge slow-to-patch install base. PHP runs most of the web, and roughly a third of PHP sites are on end-of-life versions that get no upstream fix.
- An easy first step for scanners. The attack starts with an ordinary multipart upload to a PHP page.
We set up detection for the known request shapes within hours of the advisory and have watched them since.
Monarx telemetry, SecurityWeek, Bitsight · October 2026
PHP2Shell scanning activity in Monarx telemetry
From October 21, when our blocking rules went live, to October 29:
Monarx telemetry · 21–29 October 2026
Probing was heavy from the first morning and has not stopped. Eight days in we are still logging about 66,000 matches a day.
Who is scanning for PHP2Shell
Most of the traffic comes from scanners that say what they are. We logged dozens of tool names, many with the CVE or the word php2shell in the User-Agent, and several that describe themselves as an authorized audit.
| What the request looks like | What it is |
|---|---|
php2shell-scan/2.0, php2shell-verify/1.0, php2shell-masscheck/1.0 (authorized-audit), php2shell-go/1.0, php2scan/1.0 and similar | Named scanners; the bulk of the volume |
shellflow-php2shell/1.0, no User-Agent at all, short boundaries such as ----b and VERIFY | Raw HTTP clients built from the public proofs of concept |
Two form fields, PHP_SESSION_UPLOAD_PROGRESS and PHPSESSID, plus a small file part | The upload-progress arming request every proof of concept starts with |
| Chunked bodies, or many empty file parts | Attempts to push PHP past its memory limit |
A PHP_VALUE header such as auto_prepend_file | One tool trying to change PHP settings per request |
The payloads are polite. Uploaded content is filler and the proof strings are things like id, echo, PWNED and canary. In the PHP2Shell traffic we saw no second-stage download.
PHP2Shell proof-of-concept fingerprints and scanner behavior
- The public proofs of concept have fingerprints. One uses a very short boundary, a session ID starting
PoCand a setup request withpoison=1. Another floods headers or swaps the semicolon inContent-Typefor a comma to dodge WAF rules. We looked for all of them and found none verbatim. The closest was a scanner using a similar idea with different values. - Chunked uploads are mostly noise. We logged 2,988 chunked multipart requests in 24 hours across 2,873 sites, almost all from a handful of Internet-scanner address ranges. Treat the chunked-upload shape as a hint, not a verdict.
- One tool, many jobs. A cloud-hosted scanner sends a php2shell User-Agent among dozens of others while also probing for exposed
.envfiles and known plugin bugs. Files that appeared on sites it touched came from those other bugs, not from PHP2Shell.
Why PHP2Shell probes have not turned into compromises
Outside reporting points the same way, with one caveat that matters.
- Bitsight (October 29) reports no reliable exploitation yet. It describes the apparent surge in PHP scanning as largely a measurement artifact from noisy scanners, notes that a Sophos exploitation claim was retracted, and says a working chain needs a memory leak and a corruption on the same worker with build-specific details. It also measured fast patching. 68.6% of rescanned hosts on supported branches patched within a week, against 6.4% on end-of-life branches. See the Bitsight write-up.
- SecurityWeek reports a researcher's honeypots recorded 35 working shells on October 24, matching a public proof of concept, and that CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. The honeypots ran PHP 8.4.26 under
mod_phpwith a single worker, a deliberately favorable setup the researcher says does not measure reliability elsewhere. See SecurityWeek.
Both can be true. The exploit works in a lab built to help it. Production hosting is a harder target. Many workers per pool, different PHP builds, mixed configurations, and a patch that about two thirds of supported-branch hosts had taken within a week.
Bitsight, 29 October 2026
Our caveat. Monarx protection starts after PHP has started the request, and the earliest stage of PHP2Shell runs before that, as we said in the original advisory. We see files that PHP writes and code it runs once the request is under way.
Updated PHP2Shell indicators (IOCs)
Most of these identify scanners and audit tools, not necessarily attackers. Use them to find and triage probing and treat a hit on a site you own as a prompt to check patch level.
| Type | Values |
|---|---|
| User-Agent | php2shell-prefixed tools (php2shell-scan/2.0, php2shell-verify/1.0, php2shell-masscheck/1.0, php2shell-go/1.0, php2shell/4.0), shellflow-php2shell/1.0, php2scan/1.0, sudo3rs-PHP2Shell-Checker/1.5.0-batch, php-upload-progress-scan/1.0; or none |
| Multipart boundary | ----shellflow-php2shell, ----shellflow-inject, ----b, VERIFY, ----php2scan7351, ----p2sleak, B7kQpoc618, Bx9K618, ----xb |
| Form fields | PHP_SESSION_UPLOAD_PROGRESS together with PHPSESSID as body fields; file part named a, poc.bin or with a filename over 500 characters |
| Proof strings | system('id'), P2S_ plus a timestamp, PWNED, canary, shellflow_canary.txt |
| Probe files | php2shell-check-<hex>.php, __php2shell_version_probe_<random>__.php (they delete themselves) |
| Host files from public PoCs | /tmp/POP_PROOF, /tmp/RCE_PROOF, /out/p1, /out/c |
| Busiest sources, last 24 hours | 34[.]79[.]202[.]206, 45[.]159[.]58[.]80, 172[.]238[.]161[.]142, 172[.]232[.]192[.]243, 45[.]141[.]235[.]49, 45[.]192[.]213[.]7, 193[.]29[.]139[.]139 |
| Other tools seen | 192[.]26[.]55[.]29 (no User-Agent), 5[.]175[.]192[.]66 (VERIFY boundary), 217[.]217[.]226[.]156 (PHP_VALUE header), 162[.]141[.]167[.]33 (php2scan), 45[.]133[.]193[.]75 (object-injection probes) |
How to protect against PHP2Shell
Probing is not exploitation, but it tells attackers which servers answer and the end-of-life population will stay exposed long after the news fades. The advice from our original advisory still stands.
PHP2Shell guidance for site and server owners
- Patch PHP. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package, and restart PHP-FPM or the web server afterward.
- Treat 8.1 and older as unpatched. Upgrade, use a vendor that backports the fix, or take the site offline. About 60% of exposed hosts Bitsight measured were on end-of-life branches, and more than nine in ten of its PHP 7.4 hosts had not changed a week after the release.
- Reduce exposure until you can patch. Where the application does not need to upload progress, set
session.upload_progress.enabled=0, keepsession.use_strict_mode=1anddisplay_errors=Off, and cappost_max_sizebetween 8M and 32M. Restart PHP afterward. - Watch for post-exploitation behavior. PHP workers starting shells, new files in
/tmp, and repeated worker crashes or memory-exhausted errors are the signs that matter, and they only show up in server logs. - If you see them, isolate first. Take the site out of service, preserve logs and files, and clean from known-good copies.
PHP2Shell guidance for hosting providers
Monarx telemetry · 21–29 October 2026
- Switch detection-only protection to blocking for the known probe shapes. In our fleet, 17.5% of matches went through because agents were only logging.
- Patch internet-facing PHP 8 first, then decide a path for 7.x and older.
- Do not rely on a header match alone. At least one public proof of concept swaps the semicolon in
Content-Typefor a comma to get around signatures, so match on the multipart body and the form fields as well. - Collect crash and error logs for PHP workers, since that is where in-memory exploitation would show first.
- Share what you find. If you see a working shell, we want to compare notes.
Ready for next‑gen AI Server Security?
Start your Monarx journey in minutes
