I want my Wednesday back
B · Useful, limited A freelance security engineer gives a reasoned, checkable counterweight to PHP2Shell alarm based on reading the public PoC, but it is a back-of-envelope estimate by someone who says he is not an exploit developer, and later updates partly undercut it.
Summary based on the full text·Original: about 3 minutes to read
In short
A 23 October 2026 post by Lucas Luitjes, a freelance developer and security consultant, arguing that PHP2Shell is serious but that claims of near-instant mass exploitation were overstated. Reading the best public proof of concept, he notes it needs four consecutive requests to the same PHP worker and knowledge of the exact build. On a real site with load balancing, many workers and bot traffic, he estimates days of noisy brute force per target. Updates on 25 October report the first public evidence of exploitation against a honeypot and a Trail of Bits claim of a reliable exploit under load.
Key numbers
- fourconsecutive requests that must hit the same PHP worker process for the public PoC to work
- 150default mod_php worker count the PoC relies on, keeping 149 busy with half-sent requests
- 50kattempts for 50 common PHP/OS builds across 10 to 1,010 workers, before repeats for background traffic
- 3-4 secondstime per PoC attempt against localhost, estimated at 10 seconds over the internet
As reported by the source.
English·Web page·opens blog.luitjes.it
What it reports
- The PoC fills 149 of the default 150 mod_php workers with half-sent requests, then sends four exploit requests to the remaining worker, against a known build.
- Estimate: 50 common PHP/OS builds times any worker count from 10 to 1,010 is about 50k attempts, each repeated against background traffic, at roughly 10 seconds each over the internet, one at a time. In practice, multiple days of traffic that looks like a denial-of-service attack.
- WAFs and rate limiting on busy sites, and filtering rules published at disclosure, further cut the odds.
- Low-traffic sites near stock configuration that leak their version are the realistic early targets.
- At writing, "exploited in the wild" claims referred to attempts; HoneyLabs had seen none that could run successfully.
- 25 October updates: honeypot exploitation matching his description, so mass exploitation of low-traffic sites has likely begun; a public $2k bounty on a high-traffic test site was unclaimed; Dan Guido of Trail of Bits claims an exploit that works under load, unconfirmed publicly.
How they got it
Reading the public PoC (github.com/9bie/php2shell-bypass-aslr-exp) and reasoning about production conditions. No live testing against production-like setups is reported.
Limits
- The author states he is not an exploit developer; the estimate assumes no smarter technique to find the worker or build.
- His own updates show the low-traffic case moved within days, and a skilled team claims to have solved the high-traffic case.
- Opinion piece; no data beyond the PoC and public reports.
Why it matters for companies
Patch urgency should be set by exposure, not headlines: small, unprotected, stock-configured PHP sites (marketing microsites, forgotten campaign pages) are the likely first victims and the easiest to overlook. Busy sites behind a WAF have more time, but not much, given the claim of a working exploit under load. Inventory every PHP deployment, including agency-run ones, and patch the low-traffic tail first rather than last.
Summary based on the full text. Read the original for the full argument and data.Read the original on blog.luitjes.it
- Tags
- AI security