To me, it seems more more akin to broadpwn, technically severe, wide scope (millions of iphones), yet will never be a one-size-fits-all-PWN-button.
Even in the age of AI, I don't think this is going to be weaponized down the line like how Eternalblue was... but I'm not the social media cybersec guy with 15000 followers, so don't take my words at face value ;)
There are a few “social media famous” cybersecurity folks really worth their salt who didn’t immediately dumpster their morals and skills at the first sign of an ego boost.
People like Krebs, Allison Nixon, Joanna Rutkowska.
Most of them though are just addicted to likes as it’s become a core part of their self worth.
More seriously, though, I read it as bad because of the potential. All versions of PHP going back a full two decades were affected, all users of PHP are affected regardless of which features they use, and it’s still unclear if there’s an effective mitigation. So the blast radius if anyone does/did have a working exploit would have been enormous.
Your average site is fine at 99.9% uptime.
* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."
* Regarding the other CVE, "A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php."
Since those exploits exist, I expect that LLMs will duplicate them soon.
Do we? This was certainly true years ago. But I haven't really thought that modern PHP was any worse than any other scripting language.
Many apps (eg chrome) frequently fix bugs that are actively exploited in the wild yet have no public weaponized chain (sometimes for months).
The fact that there is no fully public weaponized chain does not mean it does not exist or that this bug is not as scary. It only means that it is not as trivial to exploit as log4shell/shellshock/etc.
According to cloudflare [1], it is being exploited in the wild.
My phone autocorrected to that and I'm keeping it.
As Linus says: talk is cheap; show me the code
> 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)
All I know of Laughing Man in relation to exploits is from a small niche MMORPG called Toontown Online ( https://youtu.be/sGED1WcJhOM ).
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.
They may be rare today but they have historically been very common.
> To the point where they had to ban java applets from the web.
Those are not RCEs, they were sandbox violations. Sandboxing untrusted code is hard and really only javascript engines have pulled it off. Java and Dotnet gave up, and that's fine.
PHP's security failures are not from trying something ambitious. They're from generating web content on a server. These are not comparable.
I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.
Merely declaring a transitive dependency didn't mean that the code was executing nor did it mean that user input was actually being logged through those libraries.
Log4j v2 (the vulnerable version) just wasn't that common at the time. Most everyone had moved on to Logback, and Log4j v1 (not vulnerable) was still more popular than v2.
Some software written in PHP has a long history like that.
PHP itself mostly dont. Tbh runtime itself has fairly stellar track record on security considering it written in C.
What makes you say that? I know several websites that ran on unpatched PHP 5 versions for over a decade, without a care in the world until now, because there were no known serious vulnerabilities in the interpreter itself.
upgrading php is much easier.
If it was just "everyone take a breath, we've been through something worse with Log4Shell", that would make a lot more sense.
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.
If it takes a week to come up with a working exploit code, the critical services have time to update.
If you are a bad actor you probably don't share your PoC around as it means less boxes to hit.
Crowdstrike's average "breakout times", the time gap between a first successful infiltration and maximal exploitation, has gone from days or hours prior to 2024 to minutes or seconds now.
That said, OP is basically full of shit. This is absolutely exploitable and people are going to just assume the platform and ABI and spray it against the internet, particularly hoping for mod_php.
Calif: "the available exploitation paths depend on the PHP version and SAPI but are always exploitable under default configurations" ... "This results in RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 5.4.0."[2]
PHP Foundation: "full remote code execution was demonstrated with default settings."[3]
Unless all of these organizations are lying, the exploit can work against a default PHP installation running a Hello World script.
[1] https://www.wiz.io/blog/php2shell-php-rce
[2] https://calif.io/php2shell/
[3] https://thephp.foundation/blog/2026/10/21/todays-php-securit...
With previous showstopper security bugs, once you knew the vulnerability existed the exploit was immediately obvious.
Yes there is a long tail of Internet of Shit devices that have a fixed non updated cert store, but these devices are being absolutely ripped to shreds by AI from all angles already.
Most non-browser TLS clients (so basically everything else, with default settings), things like curl, Python, Node, Go, Java, git, package managers and every script and daemon you've got, do three things that matter here: they trust a CA bundle on disk, they don't check revocation by default, and they don't check CT. So the fact that eMudhra and Sectigo have revoked these intermediates doesn't help them at all. [1]
I suppose majority of the them now...
I have had this take but for things like exploiting with a DRAM interposer ala Battering RAM. They say it's a low cost attack, but the amount of obstacles you need to overcome (including having root on the system and physical access) is intractable to virtually everyone, and a nation state wouldn't go to that kind of gymnastics when it is more than likely there is a quicker and easier way in.
But this? I doubt any high value targets will be exploited in the wild since news travelled fast and from what I can see pretty much most took preventative action. Looks like pretty much everyone heeded the warning and suggestions. It'll mostly be a nothing burger like Heartbleed. There'll be of course low hanging fruit of unpatched servers out there, but anything of importance would have already had active maintenance and patching.
Now that Calif has released the details, I'm sure there'll be a contingent that can actively and easily exploit this, either now or very soon, with or without the guidance of LLMs.
But yeah if someone said Battering RAM, I would say fuggedabout it, but if someone said PHP vulnerability with a CVE of 9.2, I would say patch it ASAP or bring the servers down until you can.
Mostly because people either "did it" or yelled long enough and loud enough that it "got done". There is a saying about horses and water, but some people needed to be dragged, kicking and screaming and have their faces shoved in the well.
When headlines like "there wasn't an easy exploit" come out I have burned a lot of good will, on what people will perceive as "nothing burger". The security space has a knack for making a complete mockery of itself and then wondering why no one seems to give a fuck.
"I'm getting too old for this shit" really does apply to today.
Doesn't look like confusion to me.
[1] https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-...
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 publication 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.
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.
The rather long delay in getting official Docker images didn't help; we were told "patch now!!1!!" but that apparently meant building from source.
Almost every system on the internet has some local code you can chain to gain root, or a way to put some in place. It gets worse when it affects legacy systems, because they're the bastard stepchild of security. RCE on a box that hasn't been patched since Obama's first term is what little blackhats' dreams are made of. And developers are way too lazy to intentionally design their apps into different privilege domains to protect against chaining. Unless your app runs chroot() (is my neckbeard showing?) or in a container with nothing but a Go binary, somebody can LFI it.
A crack in the door is plenty of space to get a crowbar in (especially with interpreted languages).
> 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.
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)
One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.
(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.)
I largely agree with the author and it is a common annoyance in cyber security discussions where people make strong claims but have nothing to back it up with.
https://www.ft.com/content/245778d9-597b-492d-b5b6-a2967c77e...
I'm no expert on UAF exploits. I guess one thing I'm wondering is whether the pointer to "freed" memory in this case is still pointing to memory reserved by the system for a PHP process, or if it's some address that's truly free and could be picked up by another process.
This isn’t a thing; virtual memory (https://en.wikipedia.org/wiki/Virtual_memory) is very old, and Linux has never not used it. It takes a separate vulnerability (a “local privilege escalation”) to do what you’re getting at. (However, those are plentiful, and arbitrary malicious code with PHP process privileges is often already catastrophic for a web service.)
That said,
> OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself
No, nowhere does the article imply that at all.
And yeah, obviously it's still dangerous to have arbitrary code running with PHP's privileges.
Just one thing: With mod_php, those httpd processes are spun up on demand. After that the memory is released to the system, right? There's no master Apache webserver process holding all those addresses.
Just for clarity, I took the OP's point to be that the only way this could be used to escalate privileges would be if there were existing scripts on the server with credentials that PHP itself could be made to exec() ...but... if you know a process is going to be spun down and no longer holds a pointer to the memory you're writing to, couldn't you theoretically write something that might be picked up by the next process? Or is that always formatted by the next process' vm?
Appreciate your patience, I'm not a low level coder.
> Or is that always formatted by the next process' vm?
So yes, that’s sort of how it is.
https://calif.io/php2shell/
https://www.wiz.io/blog/php2shell-php-rce
https://openai.com/index/coordinated-disclosure-of-critical-...
> Using Gemini 4 Argon, the team at Wiz has shown why frontier AI is a game-changer for cyber defense. For over a decade, these critical vulnerabilities remained unaddressed because vulnerability discovery and exploitation were incredibly complex.
- Raluca Ada Popa, Head of Gemini Security, Google DeepMind