Yes, you were. These exploits are happening in processes like php-fpm before it actually executes any code for the web application, so its not like you need to find endpoint where a specific class is being invoked or anything like that.
Extremely wrong. I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone. Exploiting the PHP request parser bypasses basically all security checks and it doesn't matter how secure your code is because the exploitable component runs before your code and can't be disabled.
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
> I am very curious to hear why you thought it was overblown.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
Its overblown in the sense that 70% of the internet was not in fact vulnerable, as widely reported. And not everyone is a hackor because they have access to llms. Go look at normie coverage from people like Linus tech tips and you'll see them saying how millions of servers were under attack by script kiddies with llms, amd how llms are so dangerous.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
I agree. There's nuance to it. I believe the CVE was overblown, and I also believe that it is a severe vulnerability that should be addressed ASAP. 2 things can be true at once.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
The CVE was not overblown. It's correctly marked as a 9.2.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
"There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day."
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
Also, unless I am reading this wrong, it does not seem like what actually got the bitcoin was a 2shell-like exploit? Seems like memory corruption leading to printing out the flag through just http requests? How would you use this outside of a CTF context?
2shell is catchy shorthand for "do anything". log4shell (originator of the name?) didn't directly give you a shell either, it ran some Java code. You could have a shell if you wanted to.
I think it goes back to the huge amount of anti-AI sentiment that's out there today. Any AI accomplishment gets undersold by haters, i.e. people maintaining that the Navier-Stokes solution was stolen, people saying that Lean proofs can't be relied on, exploits like PHP2Shell are esoteric and not usable in the real-world, etc. Those are just comments I recall reading off the top of my head but I could find sources if anyone wants. I think it's just a way for people to cope and fool themselves into thinking that this whole AI thing isn't a big deal and will just blow over.
Respect, hats off to reevaluate when presented with the info. Will fully admit, I myself lacked the ability to assess the true severity, mainly cause I try to stay away from PHP since my first encounter in sixth grade, so was going a bit back-and-forth due to what I was reading.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
it probably starts with a correct and safe authorization check, but this vulnerability happens before any user code runs, so every PHP page is vulnerable.
True-ish? If your firewall's admin page is internet-accessible, you have no excuse for not doing "bolted to bedrock" lockdowns of your web server config and your PHP config. Either of which could have blocked exploitation of the PHP vuln.
I'm actually somewhat surprised at the clumsiness here.
I'm a complete amateur that had DeepSeek build a PHP2Shell exploit, and once the stealmybitcoin site went up and set an upload limit, i had DeepSeek try to shrink/amplify it.
DeepSeek couldn't find anything but a 2x reduction, but reading the report of how it was done - https://github.com/KillaBoi/StealMyBitcoin-PoC - I was somewhat surprised it didn't find it, and equally horrified at PHP allowing such a memory bomb of creating nested objects by parsing `f[0][x][x]...` from random requests.
Point being; these aren't amateurs but i kind of expect most well funded pros to have found this method to avoid sending massive filenames and session progress data.
For our US friend, as context, this is akin to Rudy Giuliani being a cybersecurity expert. Partly, because it simply never was Sebastian Kurzs area of expertise, mainly because the referenced corruption scandal centered around the use of Whatsapp to facilitate said corruption, so, you know...
He has already IT experience then. Surely he learned something out of it. Securely using apps. Discretely handling deals, etc.
Anyway from their webpage:
> We work directly with heads of state, ministries, national cyber authorities, and the senior officials responsible for executing national strategy.
So I presume he has and provides contacts. Just the usual one hand washes the other. Nothing nefarious I'm sure.
LMAO, you mean he learned to install Signal and turn on disappearing messages after all of his chat messages, obviously implying corrupt political practices, were read in a special government committee?
The guy doesn't even know what DHCP is, "I'm sure".
I almost feel bad that company is getting traffic from HN. Kurz is such a disgusting little worm.
Nah, I guess it is Palo Alto. PHP and Appweb is their stack AFAIK. Forti does not use PHP, Juniper uses Appweb with PHP but on FreeBSD - but the article mentions SELinux.
Reading this I'm almost certain the firewall vendor is Palo Alto Networks. They included a PAN-OS setting verbatim and the SELinux config matches my experience.
Why does a world-class firewall stack need PHP? I'm sure PAN-OS has some neat DPI features, but I would love to see firewalls that are implemented in FPGA, where the tasking was compiled down to gates to be performed deterministically, much like the low port count network switches we have today.
For some reason I’m not allowed to respond to the child comment so I’m putting this here:
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
> Irrational hatred aside, that's literally what PHP was designed for.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
This is great to say with the benefit of hindsight but nobody is changing the underlying language of their well established product for literally no reason.
And that is even with the assumption that other languages don't have issues - they do.
This makes me kinda furious. The us government makes me do so much goddamned work to comply with their cyber security regulations (only about half of which actually contribute to my security posture), and here they are running their fucking firewall management page publicly exposed (the globalprotect portal was not vulnerable, only the _actual_ management page).
The title is misleading as the article says "including systems in a US government-affiliated environment" which reads more like a 3rd party the government is contracted with versus actual government systems.
Remember that the non-defense sector of the government has been having cuts for decades and lots of important work is outsourced to rotating contract teams. This is definitely unacceptable but I'd bet there were more than a few people there who were profoundly unsurprised that the backlog caught up with them.
> Since this discovery, the Dream research team has been sharing updates and collaborating on an investigation with Palo Alto Networks, the vendor of the firewall in question. More information is available on the Palo Alto Networks website. Additional details are now included in the post itself.
So logical flaws can't be patched without hardware replacement? Software isn't fundamentally unsafe. We're in a gap era where the capability to discover bugs is greater than the response time and pre-emptive hardening of software written without AI assistance. This gap will eventually get smaller.
That's wild, I remember in early 2000s it was super easy to upload a PHP file with a shell. Back when hostings were shared, one shell could get you access to the whole host.
76 comments
[ 3.0 ms ] story [ 41.6 ms ] threadhttps://news.ycombinator.com/item?id=50272530
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
19 hours: https://stealmybitcoin.com/
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
https://github.com/KillaBoi/StealMyBitcoin-PoC
https://news.ycombinator.com/item?id=50188948
We need more of this.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
Maybe compare with https://github.com/php/php-src/blob/master/php.ini-developme..., too.
Then similar for your web server (Apache, nginx, whatever).
I'm actually somewhat surprised at the clumsiness here.
I'm a complete amateur that had DeepSeek build a PHP2Shell exploit, and once the stealmybitcoin site went up and set an upload limit, i had DeepSeek try to shrink/amplify it.
DeepSeek couldn't find anything but a 2x reduction, but reading the report of how it was done - https://github.com/KillaBoi/StealMyBitcoin-PoC - I was somewhat surprised it didn't find it, and equally horrified at PHP allowing such a memory bomb of creating nested objects by parsing `f[0][x][x]...` from random requests.
Point being; these aren't amateurs but i kind of expect most well funded pros to have found this method to avoid sending massive filenames and session progress data.
All my NYC relatives seem to have choice (unfavorable) words to say about every single one of their politicians, and have ever since Koch's 3rd term.
It's hard to serve 11M people, so most people who get into that position do so by promising to serve 11M people and then serving themselves.
Anyway from their webpage: > We work directly with heads of state, ministries, national cyber authorities, and the senior officials responsible for executing national strategy.
So I presume he has and provides contacts. Just the usual one hand washes the other. Nothing nefarious I'm sure.
- Rust didn't exist at the time
- Go didn't exist at the time
- nodejs didn't exist at the time
- Java and Python likely used too much resources for a once-in-a-while used GUI
Irrational hatred aside, that's literally what PHP was designed for.
Perl?
Perl 4 specifically of course though.
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
And that is even with the assumption that other languages don't have issues - they do.
I just do not understand. CC is not the sole harness in the world, why the attackers insist to use it.
FPGA stocks? DV is about to become hot again..
Wat
Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
E.g. this came out today: CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation [1].
I just disabled mtcp on my systems since I don't use it. Why was it enabled by default?
Can I disable this XFRM thing too?
[1] https://www.penligent.ai/hackinglabs/cve-2026-98432/