Chained PHP2Shell Exploit Roots 25 Servers, Including US Government Servers
59 points by 882542F3884314B 4 hours ago | 26 comments

xxmarkuski 34 minutes ago
Dream is btw founded and led by Sebastian Kurz, who was head of the Austrian government. He had to step down because of a corruption scandal.
reply
Topfi 5 minutes ago
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...
reply
cookiengineer 33 minutes ago
One of the three co-founders also founded NSO Group, and was developing the Pegasus malware.

Just for context, that is the type of evil we're talking about here.

A German comedian made an episode about it [1]

[1] https://youtube.com/watch?v=_PF23EdGNcE

reply
athrowaway3z 48 minutes ago
> A1 — Memory Exhaustion (~383MB):

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.

reply
tensegrist 2 hours ago
reply
Topfi 3 minutes ago
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.

Mainly saw the severity in the economic impact of having to quickly patch so much along with all the decades old blogs being botnet targets someday in the future, akin to Wordpress and Ransomeware hosting. 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...

reply
Vaushite 2 hours ago
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.

reply
jerf 15 minutes ago
"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."

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.)

reply
NitpickLawyer 13 minutes ago
It's not 19hours. The server was originally configured with no running php. Once they added a php file, the server got pwned in 2 hours.
reply
cowlevel 11 minutes ago
Shutting down half the internet was the right move. If it took someone 19 hours to exploit a site, you'd better have shut it down before 19 hours and not after.

I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.

reply
1718627440 54 minutes ago
> 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.

reply
cowlevel 11 minutes ago
Can you? Initial suggestions to block multipart content-types were a red herring.
reply
jrflo 9 minutes ago
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.
reply
jstanley 55 minutes ago
> 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.

reply
tkz1312 42 minutes ago
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
reply
lifeisloving 35 minutes ago
The point is, under normal configurations when you're serving the PHP server correctly with table-stakes best practices the server is not exploitable

This was not a scary vuln at all.

reply
cowlevel 10 minutes ago
Which best practices did you use to prevent exploitability?

And would you stake your bitcoin on it?

reply
lifeisloving 39 minutes ago
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.

reply
rkozik1989 2 hours ago
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.
reply
aaomidi 47 minutes ago
I commend you to having corrected your thoughts this publicly fwiw.

We need more of this.

reply
codegeek 37 minutes ago
I am confused. Is this attack possible even after the PHP patches OR these servers just didn't patch ?
reply
jdiff 31 minutes ago
> The affected devices run specific versions of a large vendor’s firewall software.

And the vendor's firewall software runs an unpatched version.

reply
sznio 2 minutes ago
I bet it's fortinet.
reply
jvandijk 16 minutes ago
Haha woopsie
reply
lunargamma676 2 hours ago
Same here, though what stuck with me is that a firewall's admin PHP page was reachable from the internet at all, keep that on a mgmt VLAN.
reply
cowlevel 9 minutes ago
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.
reply