Get a free audit

Field Notes / Vulnerability

Someone Left an Unpatched PHP Server Online With Bitcoin on It. It Fell in 19 Hours, With the Whole Internet Watching.

Steal My Bitcoin put a deliberately vulnerable PHP 8.4.26 server on the internet after the PHP2Shell disclosure and dared anyone to take the wallet key. It held for most of a day, and only after the setup was changed. Here is what the challenge proves, what it does not, and why your own unpatched host gets a quieter and less forgiving test.

Author
Red Team Partners
Read
6 MIN READ
Filed
26 Oct 2026
A system administrator at a server rack, checking the hosts a public PHP challenge says nothing about.

01 What happened

he post on Hacker News was short. A bitcoin key sat on a server, readable by the PHP user account through a small binary. The PHP version was picked from before the PHP2Shell fixes. First person to empty the wallet keeps it, and anyone who does not need the money is asked to donate it HN 2026 .

WhenWhat happened
21 Oct 2026PHP ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix PHP2Shell (CVE-2026-109618, CVE-2026-109619)
24 Oct 2026Steal My Bitcoin goes up on Hacker News with about 0.006 BTC in the wallet, on PHP 8.4.26
24 to 25 OctDonations push the pot to 0.0251 BTC. Heavy probing takes the site offline at times
During the challengeResearchers question whether the setup exposes the vulnerable code paths. The organiser adjusts it
25 Oct, 15:47 UTCThe key is recovered after 19.28 hours. The organiser checks the logs and pays out

The ending had a twist. The key the winner pulled out belonged to a different branch of the wallet than the funded address. Organiser James Pavur called it his mistake and sent the prize anyway Cointelegraph 2026 . The site itself now reads: my bitcoin was stolen after 19.28 hours Steal My Bitcoin 2026 .

02 Why 19 hours is the wrong number to keep

Anyone on the internet could try this server, and it still held for most of a day. That sounds like PHP2Shell is harder than the advisories made it look. Partly, it is. WordFence founder Mark Maunder pointed to it as “the absolute best explanation you’ll see on how hard #php2shell is to exploit” Cointelegraph 2026 .

Hard is a property of the conditions, though, and the challenge shows how much the conditions matter. One researcher suspected from the responses that the first version of the server never ran the vulnerable PHP code at all. That theory was never verified, and fingerprinting alone cannot prove it. What is on record is that the setup was questioned, the organiser changed it, and the box fell inside a day.

And the first real attempt came long before anyone posted a bounty. Amazon Threat Intelligence logged an exploitation attempt against its honeypots on 17 October, four days before the fix (our PHP2Shell note has the full timeline).

03 Your server gets no scoreboard

The challenge had rules that worked in the defender’s favour. Players could only attack the web application and the PHP container. Attacking the host, sabotaging the infrastructure or flooding the server was forbidden, and every request was logged Bitcoin.com 2026 . The game ended the moment one person won, and the win was announced.

  • No clock. A real attacker does not stop at 19 hours. Your host stays unpatched until someone notices, often for weeks.
  • No rules. Nothing stops them from chaining a second bug, a leaked password or a vulnerable plugin to reach the conditions PHP2Shell needs.
  • No announcement. The challenge winner wanted the prize and the credit. An attacker who lands a web shell on your server wants to stay there, and the first sign may be your data turning up for sale.
  • No single prize. The challenge held one key. Your server holds database credentials, API keys and a route into the rest of your network.

04 What to do on your own hosts

The fix list has not changed since 21 October. What the challenge adds is proof that the gap between a working exploit and a theoretical one is about a day of effort from people who wanted it.

This week, on every PHP host
  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. Branches 7.4 to 8.1 get only source backports, and 5.4 to 7.3 get nothing.
  • Restart every PHP worker after the update. A reload can leave old workers running the vulnerable binary.
  • Set session.upload_progress.enabled=0 with php_admin_flag. It covers CVE-2026-115560, which the 21 October releases do not fix.
  • Check the value on the PHP that serves web requests, per FPM pool, not with php -i on the shell.
  • Look for PHP files, cron jobs and accounts nobody created since 17 October 2026, in the web root, upload folders and cache directories.
  • List every host that runs PHP, including the ones a vendor or an agency manages for you. The unpatched host is usually the one missing from the list.

The patch details are in PHP2Shell: what to patch, and the setting for the second flaw, with how to prove it is live, is in CVE-2026-115560: the one setting.

The challenge server told everyone when it fell. Yours will not. Your Threat Map finds every PHP host under your name, shows which ones were exposed last week, checks them for signs of an intruder, and gives you the fixes ranked by what each host reaches. Enterprise-grade. Not enterprise-priced.

References

Sources

  1. Steal My Bitcoin. Challenge page and result. stealmybitcoin.com, accessed 26 October 2026. stealmybitcoin.com
  2. Redman, J. “Website Dares Hackers to Steal Bitcoin as the Clock Keeps Ticking.” Bitcoin.com News, 25 October 2026, updated after the win. news.bitcoin.com
  3. Cointelegraph. “Hodler’s Digest: AI agents help rescue ETH’s Glamsterdam fork, Steal My Bitcoin site.” 25 October 2026, updated 26 October 2026. cointelegraph.com
  4. “Show HN: Steal My Bitcoin.” Hacker News, October 2026. news.ycombinator.com
  5. The PHP Group. “Security advisory: Critical remote code execution vulnerabilities, update now.” php.net news archive, 21 October 2026. php.net