layer816 minutes ago
> So why was everyone so scared?
> Because:
[…]
> 3. The exploit video had an anime girl in it
Lol, somehow I had missed this. Since I had to dig a bit for it, here it is for everyone’s enjoyment: https://www.youtube.com/watch?v=pfWZrdzvooc (via https://calif.io/php2shell/#php-5-4-0-rce)
pinevale25 minutes ago
I've seen many posts like this. None of them stood the test of time. Ease is irrelevant because you only need expertise once and then everyone can reuse the result.
It's also not easy to pop an iPhone, but reliable, weaponized exploits are available in trade and governments use them in a plug-and-play way.
Gigachad11 minutes ago
Time is the whole point though. Everyone was terrified and shutting their websites down because they believed the exploit would be running wild on the internet in between it hitting git and them being able to update the server.
If it takes a week to come up with a working exploit code, the critical services have time to update.
mrheosuper4 minutes ago
With AI i think it's safe to assume it would only take hours after you give it what/where to look
ameliaquining23 minutes ago
The specific controversy here is about the disclosure timeline. Some people allege that the disclosure and patch release of this vulnerability were mishandled; others dispute this. The dispute turns crucially on how available exploits were during the embargo period. Nobody is arguing that the vulnerability doesn't need to be patched at all. (The PHP core team didn't initially treat it with much urgency, but they've acknowledged that this was a mistake.)
j16sdiz21 minutes ago
I guess the main takeaway is: we (humans? current methodology?) are bad at estimating how urgent a fix is or needs to be.
stickfigure4 minutes ago
> It isn't a Log4J moment.
The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.
I wouldn't downplay this.
amstan19 minutes ago
On the other hand, my local qwen model (3.8-flash-next) was trying to convince me that the eMudhra CA thing is no big deal since you need to be "positioned correctly" (eg: any wifi network) to be able to MITM, and most of the IOT devices would have patched stuff by now.
kgeist11 minutes ago
I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?
Retr0ida minute ago
I predict that this take will age poorly.
richardbarosky6 minutes ago
What kind of pisses me off was that there were kind of two sides of the continuum.
You've got the detailed technical writeup on one end of the patches themselves, and on the other end you've essentially got the AI and security companies both together (php2shell) and independently with their highly polished microsites and blog posts with attractive infographics and stylized pitch deck looking images.
Every org on the other side of the detailed technical writeup in the patches themselves are trying to make it into a huge fucking marketing stunt, providing absolutely zero added practical benefit or value.
squidlib23 minutes ago
Tadpole918119 minutes ago
> So why was everyone so scared?
I think this section misses the mark.
The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer.
Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked".
So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do?
We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?"
So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires.
This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad.
thomasfromcdnjs2 minutes ago
Yeah, I suggested to take down the app someone between seeing the Gina (core) comment (saying php.ini etc changes won't do anything) and after seeing the Cloudflare CTO tweet.
ajross6 minutes ago
It's a digression, but FTA:
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
tptacek3 minutes ago
Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.
(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)
cookiengineer12 minutes ago
I would recommend to absolve this person from any infra ownership.
Working PoCs appeared in Telegram channels already an hour after the initial announcement yesterday, because their agents already figured out the exploit primitive from 2004.
Yes, in 2004, there was a PoC for this vulnerability, working, and implemented as an RCE, and responsibly disclosed and (well, assumed to be) fixed.
If the author would know what they're doing, they would have easily found that out. But they don't know shit about what they're talking about. That's my point. In an infra ownership position you need to be able to act rationally, and not lose it during social noise like this.
It's good to be generally critical about LLM generated claims, but this is a legit exploit, verified, already discovered in ongoing malware campaigns. All kinds of forums and phpbbs were being raided yesterday, not because the owners took them down but because they were actively exploited.
The author seriously needs to start setting their personal opinions aside. Their behavior is hostile and negligent to the company they're working for. And in all seriousness, Claude isn't relevant for exploit development since GLM 5.3 and DeepSeek v4 pro came out.
asddubs3 minutes ago
Do you have any links to a working PoC that appeared before the details were released? I'm seeing a lot of conflicting info, and I'm not really sure what to think. People saying they were seeing people trying to exploit this hours ahead of the patch release, yet no one who seemingly actually got pwned by it (were people just misreading the logs?)
lukev4 minutes ago
If anything, claiming that this vulnerability has been known and unpatched for 22 years supports the author's point: clearly it's not that easy to actually use.
medler4 minutes ago
Can you share a link to a working PoC
elmer2an hour ago
[flagged]