Show HN: Steal My Bitcoin

> Yes! Was serving pure html through PHP before 13:00-ish UTC when I added that page

The entire exercise is to counter the claim that AI means every script kiddie with tokens can just have their AI create an exploit, and then have their AI scour the internet for vulnerable endpoints. If that were true, then the exploit has very little value, because everyone could make one.

In addition, the claim is that these exploits will all immediately have a thousand bots using them to exploit every possible website, and you can't leave your website vulnerable for a second or it will immediately be owned.

The fact that that hasn't happened to this server already proves the point. Whether professionals can create an exploit from the vulnerability was never the question.

No, I will not spend $5 in tokens to claim your $1000 bounty. My $5 exploit is worth more than $1000. Thank you very much.

This does effectively make the statement that, there probably are exploits out there for this, but even with a non-updated version, you're not at much risk unless someone with serious resources thinks they can make pretty big money from compromising your thing.

Zero days are valuable and kept in the bank to avoid detection. That ship has sailed.

That's part of the point. $500 or $1000 is a trivial amount. Since the money is still there, there's currently no trivial exploit.

> requires actively utilizing an unreleased 0 day exploit on a server that will certainly be able to track exactly what was done

Depending on the exploit, and the visibility stack on the server, one may or may not be able to determine how the rabbit got in the hat.

If prompting an AI could exploit this for less than $500 in token spend, then you should immediately do so, since if you don't, in a few minutes' time someone else will.

OP added php-version.php roughly 18–19 hours into the experiment (I'm not sure of the exact timing), so that period should be subtracted from the publicly displayed challenge duration.

Based on my external fingerprinting, I now believe the setup should actually be exploitable!

However, the server is being absolutely hammered with requests and crashes. Making it significantly harder to pull off. This is imo still an unrealistic target. If you are not taking the top 1% PHP websites, then they will have long periods (1 minute) of no traffic.

If someone manages to pull off a working exploit under these conditions, that would be crazy to me.

Shouldn't you be the one doing the proving here?

"Warning This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."

It's also singel threaded and very slow, so that explains why the site was so damn unusable.

It's a shame, as a realistic setup would be much more informative.

If you can get the php process to run the `print-flag` binary you will get the flag.

curl -X POST -d 'message=ping' https://stealmybitcoin.com/ping.php

edit: don't worry folks, kimi says a subagent "found a credible path to a real pointer leak". everything's under control and kimi will exploit the website in T-(?) minutes.

≈ $2,018.29 USD

Now

i picked the wrong profession

If that were true, and someone can hack the server for less than $500 of tokens, its an easy profit.

If that's the case, then there is a mitigation for all vulnerable versions, but the team that released php2shell said there is absolutely no complete mitigation and every PHP version between 5.4 and these latest updates is absolutely vulnerable. So which is true?

Then the guy never replied, "got busy", etc. A classic here.

Anyone that's thinking about defending basically stopped thinking professionally about this on Thursday midday when the PHP update was released and the patch was applied. Maybe on Friday we learned that there were no confirmed exploits or even theoretical exploits, so we discarded the marginal possibility of our servers being exploited stealthily and having a dormant attacker in our perimeter (it was a buffer overflow attack after all, very hard to execute).

So it's out of mind for us, it's almost saturday, the only reason to think about this anymore is to grift or to think about the social contagion angle. To many of us it was a random tuesday, business as usual, but some people are still thinking this was a somehow special event? My guess is that it was the fact that there was an embargo break and it caused some issues in that 12 hour period between the leak and the patch, but it was a nothingburger, now it just needs to die, at least after it makes its round through the content-creators whose 9 to 5 is looking at trend charts and monetizing views.

Whoever broke the embargo is a moron and it could have resulted in much more damage than was done.

1. there's no actual evidence that the key to the wallet is on this machine at all. it would be trivial to add a service that would sign challenges to prove so

2. a working RCE against PHP is worth much more than $1000, attacking this machine would easily burn that

I think it's clear at this point that the exploit exists, but is very hard to discover even with AI. It's likely that only top security groups and nation states have it right now, no one who would care about $2,000

Everyone with inside info was sounding the alarm so the rest of us had to take it incredibly seriously.

Exactly. This server is exploitable, but not with an off-the-shelf PHP2Shell PoC someone found on GitHub. The PHP2Shell exploit would need adjustment to the specific application configuration, and to that end, you’ve come to the same conclusion I was implying.

The easiest way is to use PHP2Shell _with_ another unknown vulnerability in the stack, such as nginx etc…

The challenge is trivial to those who know better than to even try. You cannot succeed at it without giving away far more than you could ever possibly hope to gain.

Of course, there’s always the wildcard of someone throwing away the nginx 0-day just to be funny.

I think what he's saying is if you had that, you certainly wouldn't use it on a known honeypot for 500 bucks.

No, I don’t think actual working exploit is trivial either, but people are wayyyy overselling this stunt in this thread.

No guarantee how long I can keep it up and you should assume people are doing all kinds of things to the server now that there is a PoC. Enjoy!

> in the binary itself does it perchance end in "fuL"?

Username and that comment earlier matches the "a few hours ago"/"confusion" statement by LiveOverflow.

again, i'm not sure if they actually succeeded (because the server is down and i don't really trust their local tests), but they seem to have done that.

similarly to the guy from Trail of Bits talking about how it looked like a trap - apparently this PoC was not impossible for someone else to figure out, the window was not as long as you'd hope (again assuming no funny business), and the "trust me bro this exploit is real" messaging just kind of kills overall credibility and does more harm than good. As does a misconfigured CTF, potentially. People do not have a positive view of tech and especially AI right now and if there's a real threat then fueling the "it's just hype to boost stock price for IPO" narrative is maybe a bigger issue than the vulnerability itself no? Because you also tank your ability to get people to take any future vuln seriously.

Plus a broken CTF is apparently a good way to get people to not take a current vuln seriously while also working as a honeypot to get PoCs. Probably everyone involved with good intentions should make sure they're really thinking through all the implications (preferably ahead of time so there's a playbook). Meaning societal/psychological/narrative implications too and not just technical. Security of all fields should be deeply familiar with how human behavior is kind of critical, no? How many people reuse passwords? The AI industry is uniquely incompetent at this aspect. Like all the datacenter stuff where they make secret deals for tax breaks and cheap land with city councils under NDA and then are suprised that constituents react badly to being taken for a ride by an industry and elected officials they already don't trust. Like just from an optics perspective, charging for daybreak or similar frontier cyber-capable AI to defend from AI discovered/led vulnerabilities and attacks - y'all get how this looks like a protection racket right?

The worst outcome here is AI cyberwar/CVE-apocalypse hitting while the industry is treated as the boy who cried wolf even when there actually were previously wolves because everyone involved just sucks at comms and doesn't think things through and now has no credibility to organize a response.

Are these 500$ laying on a ground for anyone to take?

OpenAI and others are infesting the influencer space with what is basically dark money, not saying you're one of the guys on the take but I just don't trust any large influencer atm who only talks positively about OpenAI (or any lab).

I guess you can prove us AI cyber doubters all wrong with this CtF tho.

This is easy to exploit for example: `docker docker run -d --rm -p 0.0.0.0:80:80 wordpress@sha256:c96e9e9a8ead2fea02f05469b356134da45681aaefa0f961a87653d58c462794` (basically `wordpress:7.1.3-php8.5-apache` with vulnerable php version 8.5.11)

OP (and anyone else who exploits the server) would be able to see the transcript between the backend and the vulnerable server, containing the payload customised for the server, but not the actual code of the backend. This would be useful if it was a 0day vulnerability, but with a disclosed vulnerability getting a payload that doesn't work except on their server, without the code that generated it, might not be that much value over what they already have.

That said, there are other ways to scam by structuring things like the OP (none of this should be taken to imply the OP has actually done this, but rather why this structure as a general approach might be a bad idea):

* This could be a 'stone soup' scam where the OP has the wallet keys (obviously), and puts this up to bait the addition of more funds into the wallet by other interested people. The key might not actually even be on the server, or it might not be vulnerable. Once sufficient other people add funds, the OP could withdraw the funds, recouping their original funds plus anything others added. * This could be run as a propaganda scam either to falsely sell that it isn't an easily exploitable vulnerability when it is (by making it unreasonably difficult to exploit compared to real-life deployments), or to over-inflate how exploitable it is (by an insider withdrawal from the wallet). Manipulating public opinion could allow an attacker with a working exploit more time, or help to sell services to fix the problem.

I think an alternative scheme that is less vulnerable to scams would be to have a ZKVM (Risc0 or similar) executing vulnerable code, such that the attacker needs to produce a zero knowledge proof transcript of getting the ZKVM into a particular state that would not be possible if they didn't have an exploit. It should also take an Ethereum address as a public input. Then write an Ethereum contract that will allow funds to be transferred to the public input Ethereum address if submitted with a valid proof transcript, and back to the source of funds after some time has passed. Everyone who wants to add to the jackpot could deploy their own version of the contract, so the one proof transcript could claim from all of them, but if unclaimed the funds go back to the source.

Alternatively (avoiding the risk exploits may be so large as to make the cost of producing the proof transcript impractical), they could be built using a public cloud provider's trusted computing offering (e.g. Google Confidential VMs). The person making the challenge could make it so the derivation (NixOS for example) to produce the entire image executing on the cloud provider in a deterministic way (with publicly known source, and hash codes of each stage publicly available). Then, from the code with the known hash, they use the vTPM to generate an attestation that a key was generated while the vTPM PCRs were in a known state (corresponding to the publicly reproducible hashes), and ensure the only way to access the key from the instance is via an exploit. It would also include logic to generate and wrap a Bitcoin wallet key, and emit the public key (with the attestations and a signature linking back via a vTPM attestation to the cloud provider's key). This way, unless the cloud provider is also in on the scam, people could be assured that the OP isn't scamming them.

  $ curl -sS -D - -o /dev/null -X FOO https://stealmybitcoin.com/
  HTTP/1.1 501 Not Implemented
  Server: nginx
  Date: Sat, 24 Oct 2026 22:06:58 GMT
  Content-Type: text/html; charset=UTF-8
  Content-Length: 495
  Connection: keep-alive
  Host: stealmybitcoin.com
  X-Powered-By: PHP/8.4.26

  curl -sI http://stealmybitcoin.com/
  HTTP/1.1 301 Moved Permanently
  Server: nginx
  Date: Sat, 24 Oct 2026 22:01:11 GMT
  Content-Type: text/html
  Content-Length: 162
  Connection: keep-alive
  Location: https://stealmybitcoin.com/

I genuinely have no idea how to even start calculating this probability. How would we do it? Is there reliable data on honeypots?

thank me later