Bitcoin Bounty Falls in Under Three Hours After PHP Test Finally Gets Real

A public Bitcoin hacking challenge was finally breached after its operator changed the server so it actually exposed the vulnerable PHP functionality researchers had been warning about.

The sequence matters more than the bounty. Before the configuration change, the challenge was being treated as evidence that the underlying PHP flaws were overhyped; less than three hours after the server became a realistic target, that argument collapsed.

CryptoSlate reports that the Steal My Bitcoin challenge followed the October 21 disclosure of two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers warned could permit remote code execution on affected servers. Operator James Pavur initially served ordinary HTML through PHP’s built-in web server, a setup critics said did not expose the vulnerable path and was further distorted when heavy traffic overwhelmed the single-threaded service.

Pavur acknowledged the problem and added an accessible PHP page around 13:00 UTC on October 25. The successful attack arrived at 15:47:38 UTC, with the researcher known as Killa obtaining code execution and extracting a hidden wallet credential.

The win came with an odd twist: the server held the wrong Bitcoin private key, so the researcher could not directly claim the intended prize from that credential. Pavur nevertheless confirmed that server logs supported the exploit, and the researcher later published a proof of concept plus a separate laboratory reproduction.

The preserved evidence does not establish that an autonomous system completed the attack. It does establish that the earlier undefeated timer was a poor basis for telling administrators the vulnerabilities were harmless.

this is a very dangerous narrative. just look at the engagement it’s getting.

for the first ~10 hours, the challenge setup wasn’t even realistic. then the single threaded PHP server got effectively DoSed by traffic, making the challenge practically unsolvable, this is solvable.… https://t.co/2SW30INZVb

— s1r1us (@S1r1u5_) October 25, 2026

The dispute shows why public security stunts can mislead even when everyone involved is acting in good faith. A challenge measures the system that was actually deployed, not the vulnerability described in an advisory and not every production server using the affected software.

When the test environment blocks the vulnerable code path, surviving attacks does not disprove exploitability. When the server is overloaded by spectators, the resulting failures may say more about capacity than about the exploit itself.

That is what made the early narrative dangerous. Businesses watching the timer could mistake a badly configured contest for practical permission to delay emergency patches.

Someone has created a vulnerable PHP website, loaded it with a Bitcoin wallet, and challenged the Internet to hack into it and they can keep the Bitcoin. It has a running timer to show if the PHP exploitability was over-hyped. https://t.co/5Pk2aLtFR3

— hacker.house (@hackerfantastic) October 25, 2026

The final result is not a clean victory for every claim made around the challenge. The wrong wallet key complicated the payout, and gaps in the original run’s preserved records left the attack’s full method unresolved.

The operational lesson is much cleaner: patch critical remote-code-execution vulnerabilities based on credible technical evidence, not on a public timer attached to an imperfect server.

The Bitcoin prize made the experiment visible. The configuration change made it meaningful.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.