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.
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.
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.
Time is not the whole point. How are people in this thread this clueless?
Risk is the whole point. The websites going down first were government / healthcare.
Do you expect these websites to take the risk? Risks that you now feel is justified because hindsight seemed to have collapsed the possibility-space?
We can talk about this again next year; if still nobody has demonstrated a working consistent attack that _could_ have pwnd my gov and medical records, then we can reflect on the severity score and the response.
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).
> Ease is irrelevant because you only need expertise once and then everyone can reuse the result.
Not if your LLM relies on existing code and you collectively create a million repos with hallucinated broken implementations that do not work before a good public exploit exists, which later LLMs rely on. LLMs are self-defeating that way.
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.
The CA thing is bad, but in practice a lot more high effort to exploit. As a prerequisite the attacker has to be present on the same network, which makes any individual attack a lot more high effort. With a MITM, you also mainly breach confidentiality, but this doesn't directly give you an exploit chain to pwn the device (though the many auto-updaters people are using nowadays might be one).
For IOT devices, there are also factors that limit the exposure. The certs are only from 2025/2026, so few devices with them installed are likely present in any given home, and depending on the hardware footprint devices may only come with the few select CAs bundled that they require due to size constraints anyways.
Yeah, it's going to be hard for someone to pick an arbitrary target and get into a position to exploit it, but there are an enormous number of people who are in the position to exploit someone.
One rogue employee at Cloudflare could MITM half the Internet if they are able to get around whatever internal safeguards exist.
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.
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.
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
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!
Shigure Ui is an illustrator and vtuber. She has a teenage character which is her main character. She also has a young girl character (age 9) which is the one that was put into the exploit explanation video.
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.
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.
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/dis have a working exploit would have been enormous.
We do need to eventually see the proof that this was so urgent. Because if it wasn't then this was effectively a massive DOS attack on society.
"9.2" is a big claim and a powerful justification for action, but with OpenAI involved my faith is very low that this isn't largely a publicity stunt. Especially given the age of the vulnerability.
You've got under 5 minutes to decide whether or not a widely reported critical security vulnerability actively being exploited in the while is severe enough to warrant taking down your site or not. The downside for taking down your site is approximately 0, and the upside is that you don't get shrekd
No security expert can or should work that fast. Its a completely reasonable thing to do given the hyperbolic reporting just in case it turns out to be true. Some websites being down for a few hours doesn't end the world
Agreed. This is all lazy chair hindsight talk, maybe by those not affected by it. In the moment you act on the imperfect information you have available and you use the safe than sorry rule. And to demand perfect information is also a fallacy, it doesn’t exist until after the fact.
I hear you, but also I'm not so sure. I remember Log4j, heartbleed, etc. and they were just as serious, but I don't recall people just going dark immediately. Scripts to validate whether or not you had exposure were built, people ran them, and if you did have exposure you started checking to see whether or not it was exploited. This timeline for this seems wildly different to me.
Because it’s not the same type. There was no actual info until the patch dropped, with some people in the know , which made it dangerous to leave your site up. The stopgaps were wild guesses. The multi-upload mitigation wouldn’t have worked.
There was no check that could be trusted to be the check to mitigate it. So that left the scenario that we went through.
> The downside for taking down your site is approximately 0
> Some websites being down for a few hours doesn't end the world
Many governmental websites are still down and they say might stay down for days or weeks. Some are not directly related to PHP, but auth doesn't work due to firewall hardening or similar. There definitely is a non-zero downside.
There wasn't any info on the exploits beyond hearsay and the claim that they're very serious, so the risk assessment, sober or not, boils down to "do I trust the PHP people when they claim this is very serious"
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.
I mean Patch the Planet. This was the first I had heard of it, and I assumed from seeing the press releases from OAI working their way through journalism’s digestive tract that it was announced today - but perhaps it was previously announced.
If that is case, I’ll refine my statement to “Also happening today: OpenAI is doing a PR push on their software vulnerability initiative”, which I think suffices to convey the same meaning as the original.
All the people with LLM on their hands, looking for fame to post PoCs on GitHub, but without zero understanding whether it actually exploited the described vulnerability. Even that most cited blog post here was pure slop, and the exploit did not actually work.
> 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.
> 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.
TBH this would have happened if they used the same approach in any language, and wouldn't have happened if they used a different approach in C.
They wrote their own allocator. That's the problem. If they didn't use their own allocator valgrind or sanitisers would have caught this.
If they used this approach in any other language, like Java or C#, heartbleed would still have happened.
I love that in a subthread I started about the limits of memory safety in security analysis, everyone gets stuck on Yet Another Rust Proxy Fight over whether the custom allocator the library wrote represents a problem with the design or the implementation language.
I repeat the claim: This isn't where you should be spending your tokens and it's not the hole through which the apocalypse will arrive. People fighting over Rust will be the first to fall when the auth-exploiting robots arrive.
> No, they used a language where the preferred way to share memory is raw pointers. That is the problem.
That's irrelevant - had they used the same approach in C#, heartbleed would still have happened. The language here makes no difference because the error is in the approach they chose which bypassed any ability for tooling or language features (such as found in C# and similar) to prevent reuse of deallocated memory.
> only in C you'd return overread-prone raw pointer.
If that was all they did, tooling like valgrind and sanitisers would have caught it.
Heartbleed was an issue because they used their own allocator. If they didn't use their own allocator, the error (over-running an array/reusing deallocated memory) would have been caught by the tooling.
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.
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 are trying to make it into a huge fucking marketing stunt, providing absolutely zero added practical benefit or value.
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.
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.
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.
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.
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.
IDK why someone flagged your reply, but basically your list shows that since 2015 there been practically no security issues that can really be exploited in default configuration.
10 years like thid seem pretty stellar for me considering half of internet runs on PHP.
To be fair, 2024's "PHP-CGI" and "Windows" are legacy features nobody is probably using. CGI was a technology to write servers using bash scripts (most popular programming language for Linux) and has been outdated for like what, 20 years?
That's not what CGI is. CGI is just mode of operation where full php process being spawned on each request and then killed. It's kind a less prone to security actually because no memory or state is reused ever.
But yeah since it's inefficient I doubt it used much after 2010 when php-fpm matured and nginx got popular.
> 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.
Log4J was utterly trivially exploitable across basically all configurations, so in that sense it was worse. But any unauthenticated RCE that's on the default configuration of such a widely deployed piece of software is a good cause for sounding the alarms, even if there isn't a script kiddie exploit that will do all of those versions.
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]
Couldn't this be enforced at the router? Intercept outbound TLS. If the client hello is to a new domain, hold it and start a new outbound connection and see if the server responds with a certificate on the CRL. If so, ban it. Otherwise let the original TLS connection proceed.
That doesn't stop you from asking for the certificate on a separate connection with your own session key, and terminating the original connection if you don't like the certificate.
The certificate incident requires a working MitM of TLS traffic. That isn't easy to pull off and browsers will immediately warn you the second they see someone try that.
The PHP exploit, as presented, runs directly from attacker to server. There's no requirement for an attacker to already be in the network.
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.
Most cybersecurity is performative, like war, cybersecurity is mostly boring and if you are doing your job, zero drama. If you want to stand out you need piercings and hot takes.
The pop culture makes you think cybersecurity is wearing black clothes, having wild tatoos and jacking-in the matrix with a dripped up thinkpad while at the back of a nightclub. Turns out, its wearing suit, and showing slide to corporate begging them to have a review process for their firewall and a decommission plan for their 20 years old services made in java 6 and never updated.
True, but I am talking about the whole vibe of security as an industry and how the corporatization of defcon shapes it. The primary issue with security, it is difficult to show efficacy. It is akin to proving a negative. If you are doing your job, no one notices until they have laid you off. You need to be loud, flashy, dangerous, brash to stick around. So now the ecosystem breeds for a signal isn't related to how qualified one was at security.
I would argue that Krebs is exactly the type of guy who will do anything for a good story, whatever it costs. I saw him lying more than once and this eroded my trust completely.
I actually rather like 'SOCMED', given that social networks these days can be weaponized in various ways, so it deserves a name akin to 'OPSEC' and other military-like terms
you'll find egomaniacs in any industry. From experience the people who actually speak regularly at cybersecurity conferences do tend to have a "cult of personality" aura about them. Part of it is industry incentives too. If you have a bunch of stuff on Github / technical blog posts / social media presence it helps a lot finding a job. So I wouldn't necessarily entirely blame them for cultivating a social media persona.
It’s not. Social media personas is most of what gets seen, hence your understandable conclusion. What most don’t see are those who do not give a damn about that and just do the work.
Just to be clear, when we’re talking cyber security and social media, we’re talking Twitter right, or is there a new netsec waterhole? Because after Elon bought it and renamed it 卐, I saw most of the netsec community splinter and disappear
So I have been failing to do half of my career this whole time?
The people you hear from are famous personalities... That's the nature of being a famous personality. There are plenty of us who are just normal people with opinions of our own and no desire to cultivate a public name or face for ourselves...
Unfortunately part of some cyber sec jobs is literally doing sales. I remeber in the begging of my career I was offered cyber sec job and the guy hiring me said you will be doing sales and will be reaching out to people on top of your job. I just declined.
Yes, the cybersecurity industry definitely oversells itself on every (social media) channel it can find. But to be fair, it kind of has to. Many people and companies are notoriously lazy about secutity and patching until something goes wrong. So you have to cause a stir, oversell the risk, and create a sense of urgency, to get them to act.
Obviously, there are also some people in cybersecurity who oversell not for the greater good, but only to further their careers... and even those who are honest and would prefer not to self-promote like that, are sort of forced to, because visibility can matter as much (if not more than) expertise when trying to find a job in cybersecurity, as you'll look like an underachiever if you don't oversell yourself like everybody else.
Yep. First few years is just getting a read on who is accurate, who is precise, and who is both. Lots of alarms going off all the time in this industry.
People seem to not understand that cybercriminals are lazy, as well. They're not gonna sink a lot of effort into doing something technically impressive when there are way easier ways to generate a decent ROI. Why would they mess around with remote heap grooming when there are plenty of nday rce in widely-deployed enterprise slop just laying around, makes no sense.
This was big news because it was the news that a sector was looking for - that is, “AI Discovers a Cataclysmic and Widespread Vulnerability” - and confirmation bias does the rest.
It took me five minutes to realise that this was something of an nothingburger. As the author states, you basically have to have PHP running as root, and allow an attacker to upload and then execute malicious code on your server already - and if you’re there already the house is already on fire.
The problem is, by and large, that AI has drastically reduced time to exploitation of vulnerabilities that modern CVEs are often under-representing their severity. If you've worked in security this year, it's been a march of vulnerability after vulnerability and everyone is waiting for the next big one that exposes your systems.
The fact that this particular CVE doesn't have an easily exploitable path has meant very little, historically, in the modern threat landscape. AI has proven it's able to pull off chaining multiple exploits that are very difficult or hard to pull off, but a machine does not care for "ease" or "difficulty".
All that is to say, the security community is currently a little gun-shy, but with good reason.
Nobody listens to experts. Maybe you mean cybersecurity influencers?
You are basically correct in your estimate of the severity. Exploitation, at least now, requires knowing exact PHP config and a lot of tweaking.
There was a complete panic on the internet and in all HN threads, with people claiming insane things like "this is already exploited in the wild" (it was not), "it took me 10 minutes to replicate this vulnerability from a public information" (yeah, sure) or "there is a public blog post with a writeup" (it was hallucinated AI slop). Voices of people who knew more, while present, were drowned in fake news. It didn't help, that in the first threads people who knew more (and were serious about coordinated disclosure) couldn't say much, so people sharing the most, knew the least.
I wish I could help, but honestly there were so many people parroting incorrect information that it's impossible. Signed, someone who got information about this vulnerability before it was publicly known, and worked to remediate it.
Just reading all of these made me question if it actually was this secure. It seemed very much like a moral panic. Sure I patched as soon as it came out, but taking websites offline seemed a bit much.
To be fair, the warning to either take down websites or patch immediately on release came from the people who've been working on this for months (or those with advance notices like CERTs), not out of nowhere. People just took it down pre-emptively since exploit attempts (whether working or not) popped up in logs way before the patch was released, but it also took forever until the fix actually landed downstream after the advisories were released.
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.
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.
Yeah, I don't think I've touched mod_php ever since Apache 2.4 came up with mod_proxy_fcgi, allowing dead simple integration with php-fpm.
PHP does need to invest more in the built-in web server, though. All other popular runtimes provide a standards-compliant HTTP daemon that any other HTTP daemon can proxy to, it's just the way things work nowadays.
Also by that measure we're never safe. Which is fine, I think we can agree there are almost always unknown exploits out there but that's not the discussion.
There is more nuance to this as well, it might work, but only in certain circumstances which seems to be where this is going at the moment.
It's not a case of 'unknown exploits' it's that a proof of concept attack is just to show that there is a problem, and not meant to show the lack of a problem. It's not meant to work in all cases that the vulnerability exists nor as a means to demonstrate that the vulnerability is fixed. It's very easy for small changes (whether a patch, config change, or exploit mitigation) to break a proof of concept in a way that would be possible for an attacker to work around (the effort ranging from 'trivially easy' to 'needing quite a lot of extra development').
The point is you that the criteria for "am I safe from this vulnerability" is "I have applied the patches and/or config changes recommended by the author of the software" and not "I tried to run the PoC against my system and it didn't work". (nor, as was common in this case, "I have applied some config changes that some random people online feel like should help")
> There is more nuance to this as well, it might work, but only in certain circumstances which seems to be where this is going at the moment.
It's memory corruption. That requires some guesswork or understanding of the underlying system (platform + ABI) and heap grooming to actually exploit but that's not a security boundary. Any vulnerable version is just going to get hammered with requests until it either crashes without an exploit or actually gets popped.
* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."
* The other CVE had "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.
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.
Revealing that before people have had time to update, or it is already being exploited widely just increases the risk that more attacks will happen. I'd be sceptical if we don't get info eventually, but for now, things being vague is expected.
Yeah, I also got a POC working against a live serve.
The author of the article made a critical mistake in gaining my trust. He said the POC's don't work and told me to run it.
--Which-- POC's, Charlie? Why aren't you giving a full listof what you tried. This isn't reddit, and you're not doxxing or attacking anyone. Post the links. Give sources or shut up.
Very weird thing for you to complain about when the writer did list multiple PoCs he tried, and here you are saying there's one that works but you won't share the link.
437 comments
[ 3.8 ms ] story [ 30.7 ms ] threadIt'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.
Risk is the whole point. The websites going down first were government / healthcare.
Do you expect these websites to take the risk? Risks that you now feel is justified because hindsight seemed to have collapsed the possibility-space?
We can talk about this again next year; if still nobody has demonstrated a working consistent attack that _could_ have pwnd my gov and medical records, then we can reflect on the severity score and the response.
Not if your LLM relies on existing code and you collectively create a million repos with hallucinated broken implementations that do not work before a good public exploit exists, which later LLMs rely on. LLMs are self-defeating that way.
For IOT devices, there are also factors that limit the exposure. The certs are only from 2025/2026, so few devices with them installed are likely present in any given home, and depending on the hardware footprint devices may only come with the few select CAs bundled that they require due to size constraints anyways.
One rogue employee at Cloudflare could MITM half the Internet if they are able to get around whatever internal safeguards exist.
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.
I'm assuming the next few days will probably confirm if this was mostly FUD or not.
0: credit to Xenosystems for this excellent phrase
> 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
All I know of Laughing Man in relation to exploits is from a small niche MMORPG called Toontown Online ( https://youtu.be/sGED1WcJhOM ).
you new here?
It's a video of an underage-looking ("loli") anime girl insulting the viewer for being a pedophile.
At this point it's mostly used by pedophiles in a sorta tongue-in-cheek way.
Of course, all the best security professionals are either pedos, israelis, furries, or all of the above, so it's not really surprising.
Basically terminally online autistic people, some of which are paid by their government. It's like 99% of the female population on Mastodon & co.
https://en.wikipedia.org/wiki/Ui_Shigure
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 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.
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/dis have a working exploit would have been enormous.
Your average site is fine at 99.9% uptime.
"9.2" is a big claim and a powerful justification for action, but with OpenAI involved my faith is very low that this isn't largely a publicity stunt. Especially given the age of the vulnerability.
I'd set up a model with cyber capabilities, maybe GLM 5.3, not sure if it needs to be abliterated?
Disable web access and let it work on exploiting the pre-patch PHP version in a VM, given the info we had yesterday.
Can it do it? How long does it take, and writing the findings into a skill, how quickly can it be used on new targets?
I'd be interested in giving it a try, but unfortunately I'm very busy this week.
crickets
No security expert can or should work that fast. Its a completely reasonable thing to do given the hyperbolic reporting just in case it turns out to be true. Some websites being down for a few hours doesn't end the world
There was no check that could be trusted to be the check to mitigate it. So that left the scenario that we went through.
> Some websites being down for a few hours doesn't end the world
Many governmental websites are still down and they say might stay down for days or weeks. Some are not directly related to PHP, but auth doesn't work due to firewall hardening or similar. There definitely is a non-zero downside.
Also announced today: OpenAI’s software vulnerability initiative.
Or do you mean something different?
If that is case, I’ll refine my statement to “Also happening today: OpenAI is doing a PR push on their software vulnerability initiative”, which I think suffices to convey the same meaning as the original.
> 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.
TBH this would have happened if they used the same approach in any language, and wouldn't have happened if they used a different approach in C.
They wrote their own allocator. That's the problem. If they didn't use their own allocator valgrind or sanitisers would have caught this.
If they used this approach in any other language, like Java or C#, heartbleed would still have happened.
I repeat the claim: This isn't where you should be spending your tokens and it's not the hole through which the apocalypse will arrive. People fighting over Rust will be the first to fall when the auth-exploiting robots arrive.
That's irrelevant - had they used the same approach in C#, heartbleed would still have happened. The language here makes no difference because the error is in the approach they chose which bypassed any ability for tooling or language features (such as found in C# and similar) to prevent reuse of deallocated memory.
If that was all they did, tooling like valgrind and sanitisers would have caught it.
Heartbleed was an issue because they used their own allocator. If they didn't use their own allocator, the error (over-running an array/reusing deallocated memory) would have been caught by the tooling.
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.
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 are trying to make it into a huge fucking marketing stunt, 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/
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.
It may have not been the most popular in the wild (I can't say), but it was a nightmare fuel 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.
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.
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.
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.
10 years like thid seem pretty stellar for me considering half of internet runs on PHP.
But yeah since it's inefficient I doubt it used much after 2010 when php-fpm matured and nginx got popular.
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.
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.
The PHP exploit, as presented, runs directly from attacker to server. There's no requirement for an attacker to already be in the network.
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.
https://www.collinsdictionary.com/submission/11194/SocMed
The people you hear from are famous personalities... That's the nature of being a famous personality. There are plenty of us who are just normal people with opinions of our own and no desire to cultivate a public name or face for ourselves...
Obviously, there are also some people in cybersecurity who oversell not for the greater good, but only to further their careers... and even those who are honest and would prefer not to self-promote like that, are sort of forced to, because visibility can matter as much (if not more than) expertise when trying to find a job in cybersecurity, as you'll look like an underachiever if you don't oversell yourself like everybody else.
It took me five minutes to realise that this was something of an nothingburger. As the author states, you basically have to have PHP running as root, and allow an attacker to upload and then execute malicious code on your server already - and if you’re there already the house is already on fire.
I think the problem that "coordinated disclosure" has too many people and companies with conflicts of interest.
For example, this PHP "coordinated disclosure", you have:
The fact that this particular CVE doesn't have an easily exploitable path has meant very little, historically, in the modern threat landscape. AI has proven it's able to pull off chaining multiple exploits that are very difficult or hard to pull off, but a machine does not care for "ease" or "difficulty".
All that is to say, the security community is currently a little gun-shy, but with good reason.
Nobody listens to experts. Maybe you mean cybersecurity influencers?
You are basically correct in your estimate of the severity. Exploitation, at least now, requires knowing exact PHP config and a lot of tweaking.
There was a complete panic on the internet and in all HN threads, with people claiming insane things like "this is already exploited in the wild" (it was not), "it took me 10 minutes to replicate this vulnerability from a public information" (yeah, sure) or "there is a public blog post with a writeup" (it was hallucinated AI slop). Voices of people who knew more, while present, were drowned in fake news. It didn't help, that in the first threads people who knew more (and were serious about coordinated disclosure) couldn't say much, so people sharing the most, knew the least.
I wish I could help, but honestly there were so many people parroting incorrect information that it's impossible. Signed, someone who got information about this vulnerability before it was publicly known, and worked to remediate it.
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.
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.
PHP does need to invest more in the built-in web server, though. All other popular runtimes provide a standards-compliant HTTP daemon that any other HTTP daemon can proxy to, it's just the way things work nowadays.
OK, can you share a working one so we can test that our servers are fixed?
Also by that measure we're never safe. Which is fine, I think we can agree there are almost always unknown exploits out there but that's not the discussion.
There is more nuance to this as well, it might work, but only in certain circumstances which seems to be where this is going at the moment.
The point is you that the criteria for "am I safe from this vulnerability" is "I have applied the patches and/or config changes recommended by the author of the software" and not "I tried to run the PoC against my system and it didn't work". (nor, as was common in this case, "I have applied some config changes that some random people online feel like should help")
It's memory corruption. That requires some guesswork or understanding of the underlying system (platform + ABI) and heap grooming to actually exploit but that's not a security boundary. Any vulnerable version is just going to get hammered with requests until it either crashes without an exploit or actually gets popped.
"We found a potential vulnerability, but not sure how this would be exploitable, but you better fix it when you have the time"
or a
"Fix it yesterday if you dont want an immediate server burn."
matters alot to small maintainers
* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."
* The other CVE had "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.
Get on time, pa, they are called LLM kiddie now
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.
https://www.wiz.io/blog/php2shell-php-rce
The author of the article made a critical mistake in gaining my trust. He said the POC's don't work and told me to run it.
--Which-- POC's, Charlie? Why aren't you giving a full listof what you tried. This isn't reddit, and you're not doxxing or attacking anyone. Post the links. Give sources or shut up.
https://github.com/david-alvarez-rosa/php-rce https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-... https://github.com/ikow/php2shell-poc