For me, what was strange is there were no write-ups on how the vulnerability actually worked. It really does feel like a lot of people went "Claude found a bug, and Claude says it's dangerous" but no one actually verified how exploitable it actually is? Not to say its worth ignoring, but compared to Heartbleed (where exploits had to be written by hand) there are a lot fewer active PoCs.
There are multiple write-ups on how the vulnerability works. The Calif one is the most detailed. Also, no one used Claude. There's a whole world of information out there when you read the original sources instead of social media distortions.
> Calif identified a critical flaw using GPT‑5.6 Sol as part of our Patch the Planet initiative, with Wiz also independently discovering and reporting both vulnerabilities
> 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
I do tend to disclose my use of AI, but at the same time I don't feel like I'm required to. I'm doing it to signal that my use of AI was productive, and of value to people beyond myself.
Interestingly enough there are papers that suggest that AI feeding on itself will degrade output quality over time. What I've noticed from my peers is that everything produced now looks the same, and they're sick of it.
Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" and even the Prime Minister of Japan doing a nighttime PSA. They cite "the experts" posts on social media about the initial advisory, while the very same so-called experts share google search AI output mitigation strategies. None of these organizations or bodies had any details other than what was on the advisories and social media. (e.g "CVSS 10, that's bad!!")
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 ;)
I feel like half of working in the cybersecurity industry is just cultivating your social media persona. It's bizarre. I left a viral up-and-coming startup over it. It was mixing into everyone's personas at work in weird and uncomfortable ways, as someone who doesn't use traditional social media.
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.
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?
There is an argument to be made that taking down such a sizable chunk of the Internet automatically qualifies it as a pretty severe vulnerability, even if no actual exploits were involved in causing it.
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.
I'm in charge of my employer's ecommerce website. To me there's a critical difference in severity between a RCE vulnerability and being to takedown/crash a website.
* 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.
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.
If they're so confident this isn't exploitable this person should stand up a very basic nginx running php-fpm server running in an exploitable version of PHP and invite people to exploit it.
I totally agree. We can sit here and posture all day, maybe it might justify our paychecks. Exploit it and show me why it’s fucked. Otherwise it’s just words
Anime girl level cataclysmic security events definitely don't worry me as much as laughing man (笑い男) cataclysmic events; only then it's when I really start to panic.
the awful edit featuring an underage anime girl only exposes the childish, immature behavior of the people handling this situation, which makes this even more terrifying!
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.
Core run time vulnerabilities in PHP, the language and runtime itself, are rare. I remember the days when an exploit in the JVM was a daily announcement. To the point where they had to ban java applets from the web.
> Core run time vulnerabilities in PHP, the language and runtime itself, are rare.
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.
Did they learn not to fix overflows by checking a variable for "> PHP_INT_MAX"?
That patch was hilarious. But you might have to meet Perl greybeards to understand the fun the internet made of the PHP core devs after that.
Was it actually though? I worked at an MSP at the time and our tools were just flagging the mere existence of the library. It either wasn't being used or wasn't exposed in any meaningful way. Oh a dev happens to have it installed on his laptop? Who cares.
My employer at the time didn’t use log4j, but we were still plenty vulnerable. All sorts of open source packages we used had a transitive dependency on it.
Very few opensource packages actually used log4j directly. Libraries generally use some sort of shim like commons-logging or slf4j so they can log into whatever your application chooses as a long sink.
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.
> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.
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.
It's a weird move for this post to simultaneously line this vulnerability up against Log4Shell (very few serversides are going to measure up to L4S) and insinuate that it's not practically exploitable at all.
If it was just "everyone take a breath, we've been through something worse with Log4Shell", that would make a lot more sense.
The only other post on this blog is "Anything connected to the internet is going to get hacked to pieces." I'm not claiming any contradiction but it is funny.
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.
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.)
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.
Time is part of the point, but it is not the whole point. The whole point involves the fact that this impacts two decades worth of PHP versions. Even if it took months to exploit, there is going to be a long, long tail of breaches against ill-maintained legacy sites.
Huh, I thought we were talking about this because it's a massive security breach offering approximately unconditional RCE against half of the servers on the open web.
The specific reason for the current degree of consternation, to the point where many websites went down preemptively which didn't happen even with Log4Shell, is that for about half a day there were multiple alleged proofs-of-concept circulating on Twitter while the PHP Foundation refused to release the patch. If that hadn't been the case, we'd still be having a conversation, but a different one.
Suppose hypothetically there was no disclosure period at all. Suppose that at the time the PHP team made the announcement that there was an unmitigable unconditional RCE against ~every version of PHP with advice to take servers offline, they had just been made aware of it themselves, and simply did not have a patch ready yet. The pre-emptive taking of servers offline until a patch was available, the OP blog post that was written, and this comment thread would all still apply the same. Nothing in this thread was in any way related to the embargo period. It is extremely weird that you came into a thread irrelevant to the embargo and told me my comment was irrelevant to the embargo, and then have stuck to your guns arguing this incessantly. The embargo and the severe vulnerability are related. They are not the same thing, and much of the conversation would in fact be exactly the same regardless of the embargo.
You can never rule out the possibility that someone interested in attacking you has a non-public exploit, but it's dramatically less likely if there aren't already working exploits circulating all over the internet.
That "if" is load bearing and increasingly flat-out false.
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.
ease is somewhat relevant initially, since it determines how quickly you have to patch before exploits start popping up. I would be extremely curious to see if anyone has been pwned by this already, especially before the public release of the patches (not that I doubt it, but I heard some people saying they saw attempts in their logs, but not really enough information to tell whether they were understanding their logs correctly. The situation just seems a bit murky and unclear to me).
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.
Wiz: "These vulnerabilities include memory disclosure and unauthenticated remote code execution in PHP itself, independent of the application running on top of it"[1]
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.
The author isn't disputing that these organizations have developed working exploits, they're saying that the exploit is difficult enough to achieve that, as far as they can tell, nobody has publicly released a working exploit except for vibe coders whose exploits rely on insane misconfigurations on the server.
With previous showstopper security bugs, once you knew the vulnerability existed the exploit was immediately obvious.
At least with the PHP one they caveat this with "under the right conditions" which judging by what we know now, the right conditions are you've already exploited the server with a LFI
The certificates incident was mitigated by the fact it was revoked within hours so by the time people found out, it was resolved.
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]
It's not just IoT devices. It's also a very very long tail of programs which for some reason have their own copy of the CA certificates list, either because they don't trust the system's one, want to work identically on all platforms, have a severe case of not-invented-here, or all three at the same time (looking at you, Java...)
>> There's something important to be said here about how many people have Claude/GPT make design decisions for them, and how AI is the primary decision maker in the world right 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.
> but anything of importance would have already had active maintenance and patching
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.
I am so annoyed… I am trying to verify the claims of this article with my friend Claude but daddy Dario won’t let me because “cyber”. I pointed it at this article and a PoC [1] I found on DuckDuckGo. We live in a stupid world. I can’t run it right now so I am trying to figure out if it’s serious.
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 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.
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.
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.
IMO it is a little bit silly to describe “a system that works well until it intersects with a trillion dollar company’s PR campaign” as an outdated failure.
Or perhaps, trillion dollar companies should be more responsible. Either because they fear regulation that will force them to be responsible, or because there is regulation that will make the responsible.
I agree. At present I do not see any set of incentives, meta-incentives, etc., that are extant, or even rigorously imaginable[0], that will lead to such a state of affairs.
0: credit to Xenosystems for this excellent phrase
Very well said. Even for non-sensitive stuff that I was told was "super vulnerable", I didn't know if this was a full, actual RCE - some places said yes, others no. Did I need to take down everything running PHP? Just the apps dealing with data I didn't want leaked? Etc.
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.
Great reply, this hits the nail in the head and is pretty much exactly how I spent my day. Just reading, waiting and stressing while being essentially in the dark about the whole thing.
I'm assuming the next few days will probably confirm if this was mostly FUD or not.
RCE is incredibly dangerous not because it lets you execute arbitrary code, but because it lets you execute some code. Code you're not supposed to execute. As soon as someone can do that, all they have to do is probe until they find something to chain.
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.
I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.
(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)
The vast majority of web services are not written in memory unsafe languages so this is not surprising.
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.
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.)
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.
Glad to be proven wrong but as far as I can see there are no reports of it currently being exploited in the wild at the scale you are implying. It genuinely takes a lot of time to weaponize even with the assistance of frontier LLM models and it is way more difficult when you don't control the server.
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.
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 on their servers, yet no one who seemingly actually got pwned by it (were people just misreading their logs?)
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, on a vanilla installation. I couldn't divine that from reading the CVE. Is that true...? Is that why you'd need PHP to exec an existing file or something? Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP? If the latter, it's a bit ironic to complain about everyone's judgment skewing toward Claude's while using Claude-generated code not doing it as circumstantial evidence that such a thing can't be done.
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.
> 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
Thanks for the explanation. Maybe I don't totally understand.
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.
It’d be redundant for me to write up the whole explanation here, but the short version is that every process has its own memory space, provided in a clean state by the OS, that other processes can’t read from or write to, regardless of pointer values. The same pointer value in two processes doesn’t refer to the same memory unless there’s specific coordination. Keywords you can use to read more about the long version on previous Wikipedia link.
> Or is that always formatted by the next process' vm?
For me, what was strange is there were no write-ups on how the vulnerability actually worked. It really does feel like a lot of people went "Claude found a bug, and Claude says it's dangerous" but no one actually verified how exploitable it actually is? Not to say its worth ignoring, but compared to Heartbleed (where exploits had to be written by hand) there are a lot fewer active PoCs.
There are multiple write-ups on how the vulnerability works. The Calif one is the most detailed. Also, no one used Claude. There's a whole world of information out there when you read the original sources instead of social media distortions.
https://calif.io/php2shell/
https://www.wiz.io/blog/php2shell-php-rce
> Calif identified a critical flaw using GPT‑5.6 Sol as part of our Patch the Planet initiative, with Wiz also independently discovering and reporting both vulnerabilities
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
See? No Claude. Never mind that other man behind the curtain
Neither of those are Claude. Checkmate.
Haven't you heard? The popular thing to do nowadays is to accuse someone of using AI the second anything is produced whatsoever.
I do tend to disclose my use of AI, but at the same time I don't feel like I'm required to. I'm doing it to signal that my use of AI was productive, and of value to people beyond myself.
Interestingly enough there are papers that suggest that AI feeding on itself will degrade output quality over time. What I've noticed from my peers is that everything produced now looks the same, and they're sick of it.
but... Calif have said that AI did find this bug.
Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" and even the Prime Minister of Japan doing a nighttime PSA. They cite "the experts" posts on social media about the initial advisory, while the very same so-called experts share google search AI output mitigation strategies. None of these organizations or bodies had any details other than what was on the advisories and social media. (e.g "CVSS 10, that's bad!!")
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 ;)
I feel like half of working in the cybersecurity industry is just cultivating your social media persona. It's bizarre. I left a viral up-and-coming startup over it. It was mixing into everyone's personas at work in weird and uncomfortable ways, as someone who doesn't use traditional social media.
Marketing, for a while, has been about the personalities of the people involved - socMed just amplifies that
It’s unfortunate but you’re correct.
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.
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?
There is an argument to be made that taking down such a sizable chunk of the Internet automatically qualifies it as a pretty severe vulnerability, even if no actual exploits were involved in causing it.
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.
I'm in charge of my employer's ecommerce website. To me there's a critical difference in severity between a RCE vulnerability and being to takedown/crash a website.
It didn't 'take down a sizable chunk of the Internet'. Site owners took down their sites because of FUD and mass hysteria.
It's not getting tripped by "mass hysteria" to be careful and go offline for a couple hours.
Your average site is fine at 99.9% uptime.
It's risk assessment, nothing more. Some weighed the risk high and paused their site. Nothing wrong with that and not hysteria or FUD.
> why is it being proclaimed the worst vulnerability in years?
Also announced today: OpenAI’s software vulnerability initiative.
Docker images from Wordpress, joomla, and drupal were all exploitable.
https://www.wiz.io/blog/php2shell-php-rce
[delayed]
Name a more iconic trio when it comes to exploits.
But these communities all patched it immediately too. Does that not say something about the iconic trio when it comes to responsiveness?
They've had a lot of practice. Usain Bolt was also really fast because he ran a lot.
Not a trio, but Magento beats all of these 3 combined when it comes to being an exploitable POS.
> We all deep down know that PHP is insecure
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.
I think thats said tongue in cheek.
According to "Today's PHP Security Release, and How We're Strengthening PHP Security" discussed at https://news.ycombinator.com/item?id=50182987
* 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.
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.
If they're so confident this isn't exploitable this person should stand up a very basic nginx running php-fpm server running in an exploitable version of PHP and invite people to exploit it.
Bonus points put cryptocurrency private key on their server as bounty.
I totally agree. We can sit here and posture all day, maybe it might justify our paychecks. Exploit it and show me why it’s fucked. Otherwise it’s just words
As Linus says: talk is cheap; show me the code
Maybe the author does have a point. There are millions of PHP websites and do we know of any that was pwned?
> 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)
Anime girl level cataclysmic security events definitely don't worry me as much as laughing man (笑い男) cataclysmic events; only then it's when I really start to panic.
What is this in context of? Is the Laughing Man commonly used in (maybe Japanese) hacks?
All I know of Laughing Man in relation to exploits is from a small niche MMORPG called Toontown Online ( https://youtu.be/sGED1WcJhOM ).
https://ghostintheshell.fandom.com/wiki/Laughing_Man
One of the Ghost In The Shell animated series featured that face you saw in the video you linked.
It was used in a fairly popular anime Ghost in the Shell: Stand Alone Complex.
What's up with these weird ass videos with the anime girls though?
It's a normal video, I don't know what you're talking about.
For anyone wondering, this is the song https://soundcloud.com/marlonhoffstadt/highforever
the dancing anime girl is UI Shigure
If has anime girl, it means is serious
Also, High Forever track kind of bangs
the awful edit featuring an underage anime girl only exposes the childish, immature behavior of the people handling this situation, which makes this even more terrifying!
Since when is a 200+ year old immortal considered underage?
> 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.
Core run time vulnerabilities in PHP, the language and runtime itself, are rare. I remember the days when an exploit in the JVM was a daily announcement. To the point where they had to ban java applets from the web.
> Core run time vulnerabilities in PHP, the language and runtime itself, are rare.
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.
Did they learn not to fix overflows by checking a variable for "> PHP_INT_MAX"? That patch was hilarious. But you might have to meet Perl greybeards to understand the fun the internet made of the PHP core devs after that.
> It wasn't even a problem with the most popular logging framework at the time.
I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.
Was it actually though? I worked at an MSP at the time and our tools were just flagging the mere existence of the library. It either wasn't being used or wasn't exposed in any meaningful way. Oh a dev happens to have it installed on his laptop? Who cares.
I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)
My employer at the time didn’t use log4j, but we were still plenty vulnerable. All sorts of open source packages we used had a transitive dependency on it.
Very few opensource packages actually used log4j directly. Libraries generally use some sort of shim like commons-logging or slf4j so they can log into whatever your application chooses as a long sink.
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.
> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.
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.
> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.
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.
I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.
upgrading php is much easier.
It's a weird move for this post to simultaneously line this vulnerability up against Log4Shell (very few serversides are going to measure up to L4S) and insinuate that it's not practically exploitable at all.
If it was just "everyone take a breath, we've been through something worse with Log4Shell", that would make a lot more sense.
The only other post on this blog is "Anything connected to the internet is going to get hacked to pieces." I'm not claiming any contradiction but it is funny.
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.
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.)
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.
Time is part of the point, but it is not the whole point. The whole point involves the fact that this impacts two decades worth of PHP versions. Even if it took months to exploit, there is going to be a long, long tail of breaches against ill-maintained legacy sites.
Yes, but that's not really relevant to the controversy over the embargo.
Neither the OP nor any comment in this chain of replies is about the embargo?
The controversy over the embargo is why the post was written and why we're talking about this at all.
Huh, I thought we were talking about this because it's a massive security breach offering approximately unconditional RCE against half of the servers on the open web.
The specific reason for the current degree of consternation, to the point where many websites went down preemptively which didn't happen even with Log4Shell, is that for about half a day there were multiple alleged proofs-of-concept circulating on Twitter while the PHP Foundation refused to release the patch. If that hadn't been the case, we'd still be having a conversation, but a different one.
Suppose hypothetically there was no disclosure period at all. Suppose that at the time the PHP team made the announcement that there was an unmitigable unconditional RCE against ~every version of PHP with advice to take servers offline, they had just been made aware of it themselves, and simply did not have a patch ready yet. The pre-emptive taking of servers offline until a patch was available, the OP blog post that was written, and this comment thread would all still apply the same. Nothing in this thread was in any way related to the embargo period. It is extremely weird that you came into a thread irrelevant to the embargo and told me my comment was irrelevant to the embargo, and then have stuck to your guns arguing this incessantly. The embargo and the severe vulnerability are related. They are not the same thing, and much of the conversation would in fact be exactly the same regardless of the embargo.
But just because there isn't a working PoC on GitHub doesn't mean there isn't one and things aren't been actively exploited.
If you are a bad actor you probably don't share your PoC around as it means less boxes to hit.
You can never rule out the possibility that someone interested in attacking you has a non-public exploit, but it's dramatically less likely if there aren't already working exploits circulating all over the internet.
It was true before great LLMs era
With AI i think it's safe to assume it would only take hours after you give it what/where to look
AI makes developing this exploit faster though
That "if" is load bearing and increasingly flat-out false.
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.
ease is somewhat relevant initially, since it determines how quickly you have to patch before exploits start popping up. I would be extremely curious to see if anyone has been pwned by this already, especially before the public release of the patches (not that I doubt it, but I heard some people saying they saw attempts in their logs, but not really enough information to tell whether they were understanding their logs correctly. The situation just seems a bit murky and unclear to me).
I guess the main takeaway is: we (humans? current methodology?) are bad at estimating how urgent a fix is or needs to be.
Related LiveOverflow video about fake exploits going around https://www.youtube.com/watch?v=7CiZmq2llDg
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.
>This is absolutely exploitable...
OK, can you share a working one so we can test that our servers are fixed?
Aren't most PHP sites out there running mod_php anyway?
15 years ago absolutely. Most modern sites will be running php-fpm (or maybe FrankenPHP)
I predict that this take will age poorly.
"Script kiddies (and script adults, who have also switched their brains off)" not something i expected to hear ever but it's so real
Wiz: "These vulnerabilities include memory disclosure and unauthenticated remote code execution in PHP itself, independent of the application running on top of it"[1]
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...
The author isn't disputing that these organizations have developed working exploits, they're saying that the exploit is difficult enough to achieve that, as far as they can tell, nobody has publicly released a working exploit except for vibe coders whose exploits rely on insane misconfigurations on the server.
With previous showstopper security bugs, once you knew the vulnerability existed the exploit was immediately obvious.
At least with the PHP one they caveat this with "under the right conditions" which judging by what we know now, the right conditions are you've already exploited the server with a LFI
It's also weird that it seem to has overshadowed certificates incident, which, to me, appears to be of at least the same magnitude of impact.
The certificates incident was mitigated by the fact it was revoked within hours so by the time people found out, it was resolved.
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.
It's not just IoT devices. It's also a very very long tail of programs which for some reason have their own copy of the CA certificates list, either because they don't trust the system's one, want to work identically on all platforms, have a severe case of not-invented-here, or all three at the same time (looking at you, Java...)
>> There's something important to be said here about how many people have Claude/GPT make design decisions for them, and how AI is the primary decision maker in the world right now.
I suppose majority of the them now...
https://aws.amazon.com/security/security-bulletins/2026-143-...??
My take:
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.
> but anything of importance would have already had active maintenance and patching
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.
When they confuse the CA issue and the PHP issue in the opening paragraph, I have a hard time trusting their analysis
"I know, I know. It's all you're hearing about. That, and the number 4."
Doesn't look like confusion to me.
I am so annoyed… I am trying to verify the claims of this article with my friend Claude but daddy Dario won’t let me because “cyber”. I pointed it at this article and a PoC [1] I found on DuckDuckGo. We live in a stupid world. I can’t run it right now so I am trying to figure out if it’s serious.
[1] https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-...
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 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.
https://www.php2shell.com/
https://patchtheplanet.org/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
People mistake OpenAI and Anthropic for AI companies, but they are in fact primarily in the business of marketing, and business is good.
Every business is in the business of marketing, that's a meaningless distinction.
There's no ai in mrketng.
> 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.
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.
IMO it is a little bit silly to describe “a system that works well until it intersects with a trillion dollar company’s PR campaign” as an outdated failure.
Or perhaps, trillion dollar companies should be more responsible. Either because they fear regulation that will force them to be responsible, or because there is regulation that will make the responsible.
I agree. At present I do not see any set of incentives, meta-incentives, etc., that are extant, or even rigorously imaginable[0], that will lead to such a state of affairs.
0: credit to Xenosystems for this excellent phrase
Very well said. Even for non-sensitive stuff that I was told was "super vulnerable", I didn't know if this was a full, actual RCE - some places said yes, others no. Did I need to take down everything running PHP? Just the apps dealing with data I didn't want leaked? Etc.
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.
Great reply, this hits the nail in the head and is pretty much exactly how I spent my day. Just reading, waiting and stressing while being essentially in the dark about the whole thing.
I'm assuming the next few days will probably confirm if this was mostly FUD or not.
>script kiddie
Get on time, pa, they are called LLM kiddie now
RCE is incredibly dangerous not because it lets you execute arbitrary code, but because it lets you execute some code. Code you're not supposed to execute. As soon as someone can do that, all they have to do is probe until they find something to chain.
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).
But the author isn't saying that this isn't a crack in the door. He says it is. It's just not a wide open door.
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.
I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.
(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)
Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?
It was.
The vast majority of web services are not written in memory unsafe languages so this is not surprising.
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.
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.)
Huh? Heartbleed is literaly memory safety (buffer over read)
[removed]
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.
WAS not easy, now it's much easier.
Glad to be proven wrong but as far as I can see there are no reports of it currently being exploited in the wild at the scale you are implying. It genuinely takes a lot of time to weaponize even with the assistance of frontier LLM models and it is way more difficult when you don't control the server.
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.
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 on their servers, yet no one who seemingly actually got pwned by it (were people just misreading their logs?)
Clickbait bullshit from Internet nobodies.
https://www.ft.com/content/245778d9-597b-492d-b5b6-a2967c77e...
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, on a vanilla installation. I couldn't divine that from reading the CVE. Is that true...? Is that why you'd need PHP to exec an existing file or something? Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP? If the latter, it's a bit ironic to complain about everyone's judgment skewing toward Claude's while using Claude-generated code not doing it as circumstantial evidence that such a thing can't be done.
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.
> 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.
Thanks for the explanation. Maybe I don't totally understand.
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.
It’d be redundant for me to write up the whole explanation here, but the short version is that every process has its own memory space, provided in a clean state by the OS, that other processes can’t read from or write to, regardless of pointer values. The same pointer value in two processes doesn’t refer to the same memory unless there’s specific coordination. Keywords you can use to read more about the long version on previous Wikipedia link.
> Or is that always formatted by the next process' vm?
So yes, that’s sort of how it is.