What happened
Pavursec created a challenge site, stealmybitcoin.com, after seeing claims that PHP2Shell could enable remote code execution against millions of PHP services. The author rented a Debian VPS for $2.50 per month, deposited $500 in bitcoin in a clean wallet, and used Codex to make a basic webpage and put it online with PHP. A binary named print-flag could read a file containing the wallet’s WIF key. The author took down the firewall and posted the challenge to Hacker News. These choices made the server a deliberately exposed test target, not a representative sample of ordinary websites.
Traffic quickly overwhelmed the initial machine, which had one vCPU, 500 MB of RAM and 10 GB of disk. The author scaled it to two vCPUs, 4,096 MB of RAM and 80 GB of SSD. The host took the site down once over suspected distributed denial-of-service activity and again over excessive CPU use. Individual PHP workers also went down amid high request load, partially successful memory-exploitation attempts and other activity. The operator used regular resets and health checks rather than maintaining true high availability.
The challenge started at 20:30 UTC on October 24, 2026. The first recorded PHP segmentation fault occurred at 01:14 UTC the next day. The author later added an endpoint that returned the PHP version and UTC time, followed by a ping endpoint. At 15:47 UTC on October 25, a PHP process ran print-flag; the author associated that execution with the eventual winner. The source says a challenge participant exploited the server over the open internet using PHP2Shell, targeting the particular configuration and setup. One person extracted useful application content. The account also says the winning participant’s write-up was posted, but the supplied source material does not include its details.
The author’s logs had important gaps. During ten hours of reliable web-request logging, around 20,000 unique IP addresses engaged substantively with the challenge, about 120,000 distinct source IPs visited, and the server received more than 13 million HTTP requests, peaking above 18,000 requests a minute. Over roughly 26 hours, the author recorded approximately 2,075 distinct PHP SIGSEGV events. The post cautions that these may have other causes and only roughly correlate with attempts closer to triggering the exploit. Of the attempts, two IPs triggered print-flag; one extracted useful content. The author estimates tens of thousands of people tried, but says missing network data prevents statistically credible extrapolation. The post’s direct conclusion is that PHP2Shell is exploitable outside a lab, but that the experiment does not show relatively unskilled attackers with AI and PHP source code could exploit it reliably.
What the archive adds
This is a new fact on a known story, not a new vulnerability announcement. The archive covered the PHP security release and its urgency in the October 21 Field Note, then the affected versions and patching context in a PHP2Shell advisory note. A further note on the disclosure described the early announcement and the mistakenly published proof-of-concept video. Pavursec adds an account of a controlled public challenge and its observed outcomes; it does not supersede the advisories or establish prevalence across production sites.
Trend signal
No supplied SITE_PATTERNS entry genuinely fits this PHP exploit challenge. The account concerns the practical exploitability and limits of a particular vulnerability, not a broader pattern about agent systems, protocols, or AI-native operations.
Why now
Pavursec published the account on October 30, after the public challenge ran on October 24–25. Its timing follows the PHP vulnerability coverage and subsequent debate over whether the exploit worked outside a lab. The experiment supplies observations from an exposed test server, but it is not a population-level measurement of vulnerable sites or attacker capability.
Connections to other events
Earlier Telegram coverage described PHP2Shell as a critical vulnerability and discussed both patching and reports of a proof-of-concept video. The October 29 post also described a separate honeypot experiment and cautioned that large traffic figures do not mean there were millions of reliable targets. Pavursec’s account is distinct: it reports a successful extraction from its challenge server, alongside a very low number of successful print-flag executions relative to the reported volume of attempts. Both accounts illustrate why exploitability claims need configuration details and careful interpretation of measurements.
Why it matters
For security teams, the useful distinction is between a vulnerability being exploitable and an attacker being able to exploit it reliably across real deployments. Pavursec provides evidence for the first proposition in one internet-facing configuration, but not the second. The server’s particular setup mattered, and the post records substantial instability and incomplete monitoring. Its figures should therefore not be translated into a general success rate or a count of compromised production systems.
The experiment also gives teams a reason to separate patching decisions from speculation about attacker skill. A difficult exploit is not a safe exploit, especially when a critical vulnerability is already known; this challenge does not justify delaying updates. At the same time, the result does not establish that AI makes PHP2Shell straightforward for inexperienced attackers. Security planning should follow the vulnerability advisory and the affected deployment’s configuration, while incident response should rely on evidence from the organization’s own systems rather than challenge traffic totals.
Limits and uncertainty
This was one deliberately exposed challenge server, not a random or representative sample of PHP deployments. Its configuration, endpoints, resource limits, firewall state and frequent resets shaped what participants could attempt and what the operator could observe. The post says only one participant extracted useful content; it does not establish how many distinct people or automated tools were behind all requests.
Request logging covered only about ten hours of a challenge that lasted roughly 1,600 minutes, and the author says the missing network data prevents statistically credible extrapolation. SIGSEGV events may have causes other than PHP2Shell. The supplied account does not establish how many production systems were vulnerable, whether any unrelated real-world victims were compromised, or which AI tools, if any, were used by successful participants. It also does not establish a general success rate for exploitation.
Reader takeaway
The challenge demonstrates that PHP2Shell could be exploited over the internet against a specifically configured server; it does not show that arbitrary PHP sites were easy targets or that AI made exploitation routine. Treat the result as a concrete exploitability demonstration, not a measure of the vulnerability’s prevalence or a substitute for patching guidance. For teams, the practical response remains to assess affected configurations, apply the relevant fixes and investigate their own evidence.
Open question
How closely did the challenge server’s PHP configuration match common production deployments, and what evidence can establish that comparison?