On 25 October 2026, a UK-based pentester exploited the PHP flaw known as PHP2Shell on a server that researcher James Pavur had deliberately left unpatched, with the key to a bitcoin wallet as bait. The “Steal My Bitcoin” challenge fell a little over 19 hours after its launch, four days after the patches were released. For the security of Swiss SME servers hosting a PHP website, the experiment shows how quickly a known flaw becomes exploitable.

How was the “Steal My Bitcoin” challenge won?

James Pavur, a computer security researcher, put the stealmybitcoin.com website online on Saturday 24 October 2026. According to Cybernews, his server was deliberately running PHP 8.4.26, a version predating the patches of 21 October. The first participant able to execute code on it remotely could retrieve the key to a bitcoin wallet.

The rule fit in one sentence, BankInfoSecurity reports: a complete attack, replayed in a single Python file written with the standard library. The reward, around 500 dollars at the outset, was quadrupled by donations from the community. It reached 0.02511679 bitcoin, or around 2,000 dollars.

The winner is Jaydip Modhwadia, a 26-year-old pentester known as KillaBoi on GitHub. He achieved code execution on Sunday 25 October 2026 at 15:47 UTC. The website's counter then showed 19.28 hours.

This figure overstates the actual attack time. At launch, the challenge address led to a static page. Pavur only pointed it to a dynamic PHP page at around 13:00 UTC on the Sunday, according to BankInfoSecurity. Modhwadia says he worked for about three hours in total, according to Journal du Coin.

The wallet was not actually emptied by the attacker, either. Pavur acknowledged that he had placed on the server the key to the parent wallet, not that of the sub-wallet holding the funds. He verified the intrusion in his logs, then paid out the bounty himself.

What does the exploit do, in simple terms?

The attack relies on the two PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619. Modhwadia published the details on GitHub, with a script that requires at most 20 HTTP requests. Its principle, described in his write-up cited by BankInfoSecurity, comes down to three steps:

  • a 32 KB upload pushes PHP to consume far more memory, up to its 128 MiB limit;
  • running out of memory, PHP leaves a stale state in a reused process, and subsequent requests leak two memory addresses from it through the session cookies;
  • a final request plants a fake internal structure that PHP then executes as a system command.

The two addresses are used to bypass ASLR (Address Space Layout Randomization), the protection that places a program's code and data at random locations in memory. Alon Gal, chief technology officer of threat intelligence company Hudson Rock, called the exploit “impressive”, notably because it stays within the 1 MB per request limit of the Nginx web server.

What the experiment proves, and what it does not

The established fact lies in a timeline. The patches came out on 21 October 2026. A working, public exploit existed on 25 October. That same weekend, Adel Ka, head of detection and incident response at Perplexity, recorded 35 successful exploitations from two IP addresses across six honeypots. Administrator (root) access followed 1.6 milliseconds later.

The US cybersecurity agency CISA added both flaws to its catalogue of actively exploited vulnerabilities on 26 October 2026, according to Journal du Coin. It gave US federal agencies until 29 October to patch.

Experts draw different conclusions. Researcher Matthew Hickey believes the exploit, which is easy to adapt, makes updating urgent. British researcher Daniel Card offers a more nuanced view: each server is built, configured and protected differently, which makes many other targets harder to attack than this demonstration server.

Our analysis: the challenge does not prove that all unpatched servers fall in three hours. It proves that an exposed server running a standard, unpatched version can fall four days after the patch is released, with a tool that is now public. Pavur's server was only one version behind: 8.4.26 instead of 8.4.27.

What 2clics has already published on PHP2Shell

The patched versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) and the temporary settings are detailed in our article on the PHP2Shell PHP flaw. On 22 October 2026, more than 23,000 servers linked to Switzerland remained vulnerable, according to the Risikomonitor survey presented in our article on SME cybersecurity in the face of PHP2Shell.

One new element has emerged since. On Friday 23 October 2026, the PHP project reported a third code execution flaw, CVE-2026-115560, according to BankInfoSecurity. It considers exploitation unlikely in practice and will fix it in its next regular release, without an emergency patch. In the meantime, it advises setting session.upload_progress.enabled=0. A server that has already applied this setting against PHP2Shell has nothing else to do for this third flaw.

What does the FOCS recommend to an SME hosting a PHP website?

The Federal Office for Cybersecurity (FOCS) published a warning about these flaws on 21 October 2026. It does not limit the check to the public website: PHP can also run in an administration interface, an internal business application, a container or a device. Its recommendations, in order:

  • Inventory PHP installations, their versions, their accessibility and the people responsible for them, including at service providers; deal first with whatever is reachable from the internet or touches sensitive data.
  • Update without delay, and obtain confirmation from the hosting provider or manufacturer that the patch has been applied.
  • Restart PHP services after the update; containers may need to be rebuilt.
  • Check the version actually running: a Linux distribution may include the patch without changing the version number, so the package specified by the vendor is what counts.
  • Review the logs: unusual requests, crashes, modified files, unexpected processes. An update does not repair an intrusion that has already occurred.

If updating is not immediately possible, the FOCS asks that access be restricted to only the people and systems that need it. For a critical application, a temporary disconnection from the internet should be considered. Interim measures, such as disabling the upload progress bar or blocking multipart requests, only reduce certain attack paths. The office specifies that a web application firewall alone is not enough.

What this changes for an SME: since 25 October, reviewing the logs is no longer a theoretical precaution. A website patched after that date was exposed to a public exploit and warrants this check. Beyond the emergency, the Confederation's ICT minimum standard provides a framework for keeping the inventory up to date.

What we don't know yet

  • The share of attempts observed on honeypots that succeed on real, better-protected servers has not been measured.
  • James Pavur has hinted that he might launch a new challenge, without giving its format or date.

Sources