"No successful PHP2Shell exploits seen so far"... in the wild, specifically in Wiz's honeypot. The vulnerability itself has been successfully exploited, most notably for the "Steal my Bitcoin" challenge [1] as one example.
Dan Guido, of Trail of Bits, claims they have an "universal" exploit [2]. Knowing their track record, I don't currently have a reason to doubt this claim.
It's funny that when stealmybitcoin.com was posted on HN (https://news.ycombinator.com/item?id=50224916) there were hundreds of top voted comments saying "see no one has been able to steal it, the reported vulnerability was fake, it's all AI marketing" etc.
Since it was successfully exploited there has been zero further discussion, and I bet most people who participated in the original thread aren't even aware.
As one of those comments I dispute your characterization of it as the reported vulnerability being fake, very few people were saying that. The main thing being called fake was the narrative that with AI it was trivial to exploit the vulnerability.
It has not escaped me that the successful exploit did in fact just say “codex, exploit this” and got it.
I had assumed the rash of commenters saying “lol I am not revealing my AI’s exploit for a measly 500 bucks” were saying that because their AI attempt failed. Now I know they didn’t even try!
HN load isn't exactly a high load for a server. The automated traffic was most likely much higher, but not high, as the server used the super slow single threaded php dev http server, so high traffic was not possible, everyone had to wait their turn.
The vulnerabilities kinda rely on having to make quite a number of requests to exploit + can crash the process as I understood, so if many people try to force their way in at once 2h doesnt seems like a long timespan.
IIUC, the first setup couldn't be exploited because the site didn't run any php. You kinda need the server to run some php if you're gonna use a php vuln. It got solved ~2h after they added a php-version.php ...
As far as I know, there has been no proven vulnerability on a modern PHP (production) stack. The "Steal my Bitcoin" challenge was a toy project. The "lab" target used the embedded PHP server (`php -S`) which is for development only.
1. mod_php which is obsolete and requires Apache prefork (which should also be avoided)
2. php-fpm (FastCGI) which has been the default for more than a decade.
3. FrankenPHP is a new official interface much more suitable for containers.
There were 2 vulnerabilities.:
1. "OOM corruption".
The advisory says there was a proven exploit with mod_php, but only for that obsolete SAPI. "Source analysis therefore supports FPM as a susceptible, though *no complete FPM exploit* has been demonstrated for this SAPI."
2. "stale global state".
The advisory is
The last PHP release (8.5) was vulnerable when the debug parameter fatal_error_backtraces was on. There was a suspicion that an exploit could exist in the session code for php-fpm, but it was unproven and probably unrealistic.
The "evidence" given at the end of the article seems old news to me. The honeypot was based on Apache-prefork + mod_php. As stated in the CVE, there is a proven exploit for that (obsolete) stack.
The steal my Bitcoin challenge was nothing like a realistic common PHP setup. It was a extremely unrealistic and stupid setup, using the built in php dev server. It's even explicitly stated that it should never be exposed to the internet.
If it needs to hit the same worker to get it to work, that is a whole other problem, and that was not a part of the steal my bitcoin challenge. And what if pm.max_requests is set to 1? Is it then 100 % safe, as it respawns for each requests, making any statement for an universal exploit completely BS, or is a single requests exploit possible?
Just last week companies were saying php2shell has been rampant for months, but if that were the case, wouldn't we all have strange errors in our logs? Something seems fishy to me.
What does being from a particular country have to do with a verified CVE?
It’s not like it was their first rodeo and they got lucky. There are lots of competent security companies located in countries all around the world, including ones you may not politically agree with.
Yes, they are also highly suspect. "Israeli" is not an ethnicity. I judge Israeli companies based on their actions, their ideology and their history. There is zero reason to trust an Israeli source. Do so at your own peril.
For teams still working through the patching, the practical first step is an inventory of which internet-facing hosts and containers actually run an affected PHP version, since that list is often incomplete. Patching also does not remove anything already planted, so on exposed hosts it is worth checking web roots and upload directories for new or modified PHP files and reviewing access logs from before the patch date. Honeypot data showing few successful attempts is a useful trend signal, but it says little about whether your own servers were hit.
> but these scanners did successfully exploit Adel Karimi's honeypot, which was a likely contributing factor to CISA’s decision to include PHP2Shell in their KEV list.
This has been my hyperfixation for the last few days, and I've been trying to keep together a detailed and timestamped timeline of the evolving situation:
TLDR is multiple entries that show successful exploitation against particular setups (quite often honeypots that were kinda set up to be exploitable e.g. single worker mod_php or lab setups that are unclear on how well they match real deployments), one claim from dan guido / trail of bits about a broad exploit (but few details), millions of attempts in the wild but very little evidence of actual compromise (unit 42 withdrew theirs).
A lot of PHP environments were set up years ago, and run versions below PHP 8.1. If they don’t do something, eventually, they might be exploited, and turned into botnets or worse. A lot of the old PHP forums and other websites might get back door doors and impersonate people, etc.
I developed a proxy that sanitizes input before it reaches PHP. I had to put it together quickly, but since then, I’ve made it a lot more user-friendly, including PHP installation scripts that automatically scan your Web server configuration, and suggest exactly how to install the proxy. The proxy itself is written in C, and I recommend running it under a Linux user that has absolutely no file permissions. All it’s supposed to do is transform input into safe output. I would argue that this proxy might even be safer than the patch, because it might prevent other vulnerabilities that researchers haven’t found yet.
It’s just a generally good idea to sanitize input before it reaches your app servers anyway. But if you are running and older PHP environment, I don’t think there are any other good options than this…
If there was a well known company, TrustedExploitAndPatch Inc, that had faces and contact info and dropped an 'oh by the way.txt' file with the details, screen recording, etc. after patching showing they didn't exfil all the coins - would people be happy?
Even if someone finds your wallet and returns it, full of its original cash, they still would have had time to snag your credit card numbers, figure out your address, what coupons you have.
The alternative is a guy in a suit walking up and saying "I saw your wallet in the bushes on 144th and 132nd."
- but anyone who deploys thousands of lines of vibe-coded C that implements a transforming HTTP proxy from scratch instead of a patch (hey, it “might even be safer than the patch”!) deserves what they get
Dan Guido, of Trail of Bits, claims they have an "universal" exploit [2]. Knowing their track record, I don't currently have a reason to doubt this claim.
[1]: https://stealmybitcoin.com/
[2]: https://news.ycombinator.com/item?id=50226010
EDIT: The HN title has been changed since posting this comment.
This is the winner: https://github.com/KillaBoi/StealMyBitcoin-PoC
The challenge website was not exploitable at launch because it wasn't actually running PHP; it got cracked in two hours aftewards
In the video, LiveOverflow shows his exploit that reliably gets RCE from two requests.
Since it was successfully exploited there has been zero further discussion, and I bet most people who participated in the original thread aren't even aware.
It has not escaped me that the successful exploit did in fact just say “codex, exploit this” and got it.
I had assumed the rash of commenters saying “lol I am not revealing my AI’s exploit for a measly 500 bucks” were saying that because their AI attempt failed. Now I know they didn’t even try!
Either way, this was not true.
[0] https://news.ycombinator.com/item?id=50237379
1) A motivated human eager for $500 and internet cred can exploit a vuln (perhaps using AI tooling to help)
2) The vuln is not easily exploitable at scale by driveby bots.
> Warning. This web server is designed to aid application development. [...] It should not be used on a public network. https://www.php.net/manual/en/features.commandline.webserver...
There are 3 main PHP interfaces (SAPI):
1. mod_php which is obsolete and requires Apache prefork (which should also be avoided)
2. php-fpm (FastCGI) which has been the default for more than a decade.
3. FrankenPHP is a new official interface much more suitable for containers.
There were 2 vulnerabilities.:
1. "OOM corruption". The advisory says there was a proven exploit with mod_php, but only for that obsolete SAPI. "Source analysis therefore supports FPM as a susceptible, though *no complete FPM exploit* has been demonstrated for this SAPI."
2. "stale global state". The advisory is The last PHP release (8.5) was vulnerable when the debug parameter fatal_error_backtraces was on. There was a suspicion that an exploit could exist in the session code for php-fpm, but it was unproven and probably unrealistic.
The "evidence" given at the end of the article seems old news to me. The honeypot was based on Apache-prefork + mod_php. As stated in the CVE, there is a proven exploit for that (obsolete) stack.
If it needs to hit the same worker to get it to work, that is a whole other problem, and that was not a part of the steal my bitcoin challenge. And what if pm.max_requests is set to 1? Is it then 100 % safe, as it respawns for each requests, making any statement for an universal exploit completely BS, or is a single requests exploit possible?
I don’t suppose you’re thinking of when the issue was discovered? That was August 1st, according to https://calif.io/php2shell/#the-discovery.
It’s not like it was their first rodeo and they got lucky. There are lots of competent security companies located in countries all around the world, including ones you may not politically agree with.
https://github.com/pizlonator/fil-c/blob/deluge/projects/php...
Adel is doing an amazing job. Both in open source (https://github.com/perplexityai/bumblebee, https://github.com/perplexityai/numbat, https://github.com/0x4D31/galah) and with his reports.
So proud of him!
https://claude.ai/artifact/5cZex56WutyVnpMBrWXxzV
TLDR is multiple entries that show successful exploitation against particular setups (quite often honeypots that were kinda set up to be exploitable e.g. single worker mod_php or lab setups that are unclear on how well they match real deployments), one claim from dan guido / trail of bits about a broad exploit (but few details), millions of attempts in the wild but very little evidence of actual compromise (unit 42 withdrew theirs).
I developed a proxy that sanitizes input before it reaches PHP. I had to put it together quickly, but since then, I’ve made it a lot more user-friendly, including PHP installation scripts that automatically scan your Web server configuration, and suggest exactly how to install the proxy. The proxy itself is written in C, and I recommend running it under a Linux user that has absolutely no file permissions. All it’s supposed to do is transform input into safe output. I would argue that this proxy might even be safer than the patch, because it might prevent other vulnerabilities that researchers haven’t found yet.
It’s just a generally good idea to sanitize input before it reaches your app servers anyway. But if you are running and older PHP environment, I don’t think there are any other good options than this…
https://github.com/Qbix/proxy
Even if someone finds your wallet and returns it, full of its original cash, they still would have had time to snag your credit card numbers, figure out your address, what coupons you have.
The alternative is a guy in a suit walking up and saying "I saw your wallet in the bushes on 144th and 132nd."
- but anyone who deploys thousands of lines of vibe-coded C that implements a transforming HTTP proxy from scratch instead of a patch (hey, it “might even be safer than the patch”!) deserves what they get
edit: shocker https://news.ycombinator.com/item?id=50199456