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.

https://aws.amazon.com/security/security-bulletins/2026-143-...??

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.

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

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

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 your head 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.

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?

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.

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 in 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 wanted to make it into a huge fucking marketing stunt first and foremost, providing absolutely zero added practical benefit or value.

https://www.php2shell.com/

https://patchtheplanet.org/

https://www.wiz.io/blog/php2shell-php-rce

https://calif.io/php2shell/

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

I predict that this take will age poorly.