Rendered at 16:20:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hn773746483 15 hours ago [-]
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 ;)
iaaan 14 hours ago [-]
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.
renehsz 5 hours ago [-]
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.
n0on3 10 hours ago [-]
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.
sam_lowry_ 5 hours ago [-]
And get pennies for the work while social media personas rake in millions.
alfiedotwtf 5 hours ago [-]
[flagged]
prettyblocks 4 hours ago [-]
It's still there.
micoti 8 hours ago [-]
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.
4 hours ago [-]
arcfour 9 hours ago [-]
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...
leafletsigh 4 hours ago [-]
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.
ofjcihen 13 hours ago [-]
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.
ahofmann 10 hours ago [-]
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.
Darkstryder 10 hours ago [-]
I think you’re talking about Brian Krebs while the person you’re replying to is talking about Chris Krebs.
Both of them are well known in cybersecurity but are very different people with very different reputations.
LaurensBER 10 hours ago [-]
Would you have examples to share? I'm genuinely curious.
genxy 11 hours ago [-]
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.
maeln 8 hours ago [-]
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.
byt3bl33d3r 10 hours ago [-]
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.
syshyk 6 hours ago [-]
In fairness sometimes its thrust upon some by followers themselves, just depends how they handle this _fame_.
awesome_dude 13 hours ago [-]
Marketing, for a while, has been about the personalities of the people involved - socMed just amplifies that
vasco 12 hours ago [-]
Not everything needs to be abbreviated
thoughtpeddler 10 hours ago [-]
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
6 hours ago [-]
Ohmec 4 hours ago [-]
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.
ishouldnotbutk8 4 hours ago [-]
>"cybersecurity experts" had a big role in this
Nobody listens to experts. Maybe you mean cybersecurity influencers? Actual experts, like in most industries, are not the most visible.
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 everywhere 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.
traceroute66 5 hours ago [-]
> Social media and "cybersecurity experts" had a big role in this.
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:
- OpenAI, Wiz etc. no doubt looking for ways to sell you a subscription to the highest tier
- Chainguard with a vested interest in selling their wares and being "first" with a patch.
- etc. etc.
Then governments probably have various "pro alerts" subscriptions so they get all in a panic because the company sending out the alerts starts ringing the alarm bells.
Meanwhile the rest of the world with good-old LAMP (Linux Apache Mysql PHP) installations ? Meh ... a mere afterthought to the money-making opportunities. Some posts on HN suggest there was a 2 month delay between discovery and "coordinated disclosure" ?
Historically you might have written this off as an un-necessarily cynical view. But sadly I think it is a valid reflection of the world we live in today.
decidu0us9034 10 hours ago [-]
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.
madaxe_again 7 hours ago [-]
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.
tibbar 10 hours ago [-]
Two things can be true: it's a real, exploitable CVE 10, and it's hard enough to construct that you need a good harness + verification process to keep your LLM from cheating. So, the exploit may not be easy to construct, but it doesn't actually require the artificial settings that the OP implied.
> What we demonstrated
> Pre-authentication RCE on WordPress, Drupal and Joomla
From my understanding, the PHP bug is memory disclosure.
The RCE exploit is application dependent: it requires exploitable PHP code already deployed in the server. However, that exploitable code path is widely deployed by the most popular PHP software: WP, Drupal, Joomla, etc, so in practice most PHP deployments are vulnerable to the RCE attack.
codedokode 4 hours ago [-]
From my understanding, the vulnerability is a use-after-free, i.e. PHP allocates memory, stores pointer to it, frees it, maybe re-uses the memory for something new and then accesses the pointer. So totally exploitable.
Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.
preg_match 46 minutes ago [-]
PHP itself is a memory safe language, this is a bug in the language implementation and VM. Which happens in other memory safe languages like Java or C#. This is sort of the equivalent of a Rust compiler bug that allows unsafe behavior to slip through, which also exist.
megous 3 hours ago [-]
Not all UAF are explotiable. It really depends on what code that uses the stale pointer does with it and how controllable the freed/re-used data are. Although when evaluating I'd count much more on the first condition, rather than the second one, which may not be so easy to ascertain.
Buy 5$ on deepseek and have it write a script to grind out the right offsets to use for the most popular docker images.
I got it working just now; shell on any docker image i pull.
GG this dumb ass blog-post and thread.
lwhi 9 hours ago [-]
In practical terms:
1. An attacker identifies a publicly accessible website running vulnerable PHP.
2. They send specially crafted HTTP requests to the website.
3. The requests trigger vulnerabilities in PHP's internal memory handling.
4. If exploitation succeeds, the attacker can execute arbitrary code on the server under the privileges of the affected PHP process.
tempfile 6 hours ago [-]
I don't understand this comment. You seem to be describing in basic terms what a remote code execution vulnerability is. What does that have to do with the comment you're replying to?
lwhi 6 hours ago [-]
I think the original comment may have been amended.
Either that, or I wasn't fully awake when I wrote it.
nemothekid 13 hours ago [-]
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.
letmevoteplease 13 hours ago [-]
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
malfist 13 hours ago [-]
See? No Claude. Never mind that other man behind the curtain
syshyk 6 hours ago [-]
Claude is the new Hoover.
what 13 hours ago [-]
Neither of those are Claude. Checkmate.
SyneRyder 11 hours ago [-]
They even did try Claude Mythos earlier in the year, and it didn't find this. There's a reason "no-one used Claude" for this now.
"Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports."
This is the least professional
Video I’ve ever seen for anything like this. I can’t even follow what’s happening on screen.
fock 10 hours ago [-]
that's the point: it essentially shows (notice the --profile-flag) the work of 2 months making the exploit work reliably on every app-php/fpm-linux-combination. The only purpose is to spread fear - and then have 50% of the internet update to a patched version with 425 changed files reviewed by ~100people and their clankers at 1400 UTC sharp while for the vast majority (using fpm like recommended for ~10years everywhere...) disabling the progress-something-flag and (optionally...) disabling multipart-uploads would have nicely mitigated this.
IshKebab 8 hours ago [-]
> disabling the progress-something-flag and (optionally...) disabling multipart-uploads would have nicely mitigated this.
I wouldn't be so sure. Many vulnerabilities have been "fixed" by blocking the particular ingress path of the demo exploit, and then it turns out that there were plenty more ways to exploit the bug, they just picked the easiest one.
joquarky 6 hours ago [-]
Yep, perhaps turning off the feature doesn't stop the data from being parsed.
BetterThanSober 10 hours ago [-]
Have you tried asking Claude? Maybe we're in the age of agent-to-agent communication /s
SignalsFromBob 8 hours ago [-]
The video looks like it's making this whole thing out to be a joke. Everything about it conveys a lack of seriousness. The dancing cartoon character, the ascii art, the music, the whiz-bang visual effects that obscure anything interesting or useful.
bitlad 8 hours ago [-]
this video made the government websites go offline and patch their servers.
sam_lowry_ 5 hours ago [-]
Was it parroting and cargo-culting in an unfortunate chain of events?
9 hours ago [-]
63stack 6 hours ago [-]
AI generated comics for your CVEs, I can't even anymore
yorwba 4 hours ago [-]
"Comic illustrated by Stephanie Cortes of Ibis Craft.
Poster and comic story by Michal Zalewski (@lcamtuf) of Calif."
account42 3 hours ago [-]
I'm not sure if this is better or worse. Why needlessly expand the in-the-know circle for fluff like this.
12 hours ago [-]
ra0x3 13 hours ago [-]
Haven't you heard? The popular thing to do nowadays is to accuse someone of using AI the second anything is produced whatsoever.
ultrarunner 13 hours ago [-]
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.
DonHopkins 11 hours ago [-]
Someone had to say it:
DSHR's Blog
I'm David Rosenthal, and this is a place to discuss the work I'm doing in Digital Preservation.
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.
thoughtpeddler 10 hours ago [-]
I'm not saying the 'Claude says this is bad so therefore it's bad' is at the heart of this PHP vuln, but I'm also seeing the same phenomenon in workplace settings with 'meatproxy'-behavior of so much AI use that tends to overfit and hyperfocus on narrow issues, that then punts the work to other people in ways that just waste time (whereby pre-AI, humans would simply not have the capacity to investigate minuscule issues so they'd never be reported as such). But these days, it's just hardcore meatproxy and reverse centaur vibes all over the place (people just acting as the face of AI, and creating so much work that the other people can't really keep up with any of it anymore), and I wouldn't be surprised if that's happening to some extent in infosec more broadly too. (not saying the vulns and exploits aren't real - but there's definitely a long tail of them now where only a few are deserving of a lot of attention, patching, mitigations etc).
jdprgm 12 hours ago [-]
Agreed. The only main post was somebody on jackly something .com who overdosed on the matrix and communication skills of a squirrel picking random tokens from a dozen trees.
I'm actually curious if a lot of shit got hacked because so far it doesn't seem so. Though it seems like it should have? We always see these catastrophic vulnerabilities showing up but when are the ones where it is actually just widespread publicly dumping databases everywhere and at a point where someone non technical even registers it.
technion 12 hours ago [-]
I'm sure there is more to it than generally "ask Claude". I asked Claude this as a joke and it downgraded all the way to Sonnet before it would answer, and I was previously approved for their dual use cyber program.
The latest POC video for the php2shell exploit features a dancing anime girl. How would you create a video like this?
gkanai 10 hours ago [-]
> How would you create a video like this?
You would need to hire the team that made the original video (which as of this comment has 148 million views)
The writeups showed up after 14UTC, after the embargo. All of those clowns sharing non working PoCs didn't actually know the bug, they only contributed to the general hysteria
codedokode 4 hours ago [-]
Lot of non-working PoC and slop are actually good because they waste hackers time to find the working exploit.
kgeist 16 hours ago [-]
I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?
bunderbunder 15 hours ago [-]
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.
cpburns2009 14 hours ago [-]
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.
prox 9 hours ago [-]
This is all hindsight talking. You act on the information as it becomes available. At the moment, the being safe than sorry rule applied.
NackerHughes 14 hours ago [-]
It didn't 'take down a sizable chunk of the Internet'.
Site owners took down their sites because of FUD and mass hysteria.
Dylan16807 13 hours ago [-]
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.
theboblong 9 hours ago [-]
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.
user43928 8 hours ago [-]
This should be somewhat testable.
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.
philsquared_ 13 hours ago [-]
It's risk assessment, nothing more. Some weighed the risk high and paused their site. Nothing wrong with that and not hysteria or FUD.
devin 12 hours ago [-]
I think the article is suggesting that a sober risk assessment was not done by most folks period, not that they merely perceived the risk differently.
asddubs 19 minutes ago [-]
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"
20k 11 hours ago [-]
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
prox 9 hours ago [-]
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.
devin 51 minutes ago [-]
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.
popcornricecake 6 hours ago [-]
> 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.
plorg 11 hours ago [-]
Presumably the lack of sober risk assessment was on the part of the hyperbolic reporters.
11 hours ago [-]
syshyk 4 hours ago [-]
Of of course, an excuse to email a user base to say "sorry we're offline for xyz", from a company I haven’t dealt with in 7 years...
fwlr 15 hours ago [-]
> why is it being proclaimed the worst vulnerability in years?
Also announced today: OpenAI’s software vulnerability initiative.
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.
12 hours ago [-]
nicce 8 hours ago [-]
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.
nallerooth 9 hours ago [-]
This is such a strange claim from someone trying to sound knowledgable in the field of cyber security (maybe they are, I have no idea who this person is). Even if the exploit would be difficult to use properly, it's not like there's a lack of groups out there trying.
Anyone serious about this would consider the fact that a working PoC was reported to the PHP security team. They confirmed the vulnerability and started making a lot of noise about the severity of it, by reporting 2 CVEs and pushing the patch to Linux distros ahead of the official patch release.
Trying to understand what the message of the post is all about, I flipped the whole thing around in my head - and the message is basically "you don't need to upgrade your servers". Which is something someone with a working exploit would say. Or it's just noise on the Internet.
pms 8 hours ago [-]
That's clearly not the message, the author writes at the top:
> You should patch your servers anyway. There is a real vulnerability here, but exploiting it is significantly harder than people are making it out to be.
The take-home message is about human herding behavior being reinforced by LLM use:
> 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. You've got this bizarre case of "Decision Schelling Points" where a method of solving a problem is extremely overrepresented, because it's what Claude does out of the box.
athrowaway3z 7 hours ago [-]
And when the prevailing wisdom loaded into Claude is making people do dumb shit, then you write a blog post complaining about it.
---
Having Claude re-inforce to people the severity - who do not have the security background to make a call - is a feature of herd behavior.
The risk is all that mattered.
The risk, unless the original reports have been lies, is very real.
Posting this AI complaint-blog because with hours of hindsight nobody released a seflreplicating variant, is the wrong lesson at the wrong time for the wrong reasons.
I guarantee you there well be a better time to post this complaint about AI-driven herd behavior. But it was not today about this.
silentbob7 7 hours ago [-]
I would like to disagree, I read it like - people calm down, no need to panic. As vanilla php with default config is not easily rce exploitable.
Why attacking him personally?
syshyk 7 hours ago [-]
Because it goes against the grain maybe?
Try telling people they are wrong often enough it happens a lot. ad hominem.
Virtue signalling is really coming more of a problem these days, specially in the security sphere.
samuell 8 hours ago [-]
> it's not like there's a lack of groups out there trying.
Indeed. And those who knows how to implement this, might also be the ones with capabilities to deploy it on a large scale (via bot nets or whatever).
What about state actors, suddenly getting a possibility to plant backdoors in millions of websites, etc.
You don't have to be too imaginative to see the "economics" of this.
nickysielicki 15 hours ago [-]
Docker images from Wordpress, joomla, and drupal were all exploitable.
Name a more iconic trio when it comes to exploits.
panki27 9 hours ago [-]
Windows, Exchange, Active Directory.
red-iron-pine 2 hours ago [-]
Word Outlook IE
SOLAR_FIELDS 14 hours ago [-]
But these communities all patched it immediately too. Does that not say something about the iconic trio when it comes to responsiveness?
santoshalper 13 hours ago [-]
They've had a lot of practice. Usain Bolt was also really fast because he ran a lot.
system2 13 hours ago [-]
Not a trio, but Magento beats all of these 3 combined when it comes to being an exploitable POS.
opsaythepocs 10 hours ago [-]
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.
joaohaas 8 hours ago [-]
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.
hdgvhicv 8 hours ago [-]
Which POC did you get running against a vanilla unmodified php server. Which server, which OS?
Article's very vague about how the RCE actually works. They talk about the memory corruption bugs but not how exactly those become RCE.
glacier9147 10 hours ago [-]
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.
* 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.
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.
1over137 14 hours ago [-]
>This is absolutely exploitable...
OK, can you share a working one so we can test that our servers are fixed?
rcxdude 8 hours ago [-]
A PoC exploit failing isn't very strong evidence you're actually safe.
syshyk 4 hours ago [-]
Moving goal posts much?
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.
rcxdude 3 hours ago [-]
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'). This is especially true for binary exploits which can be quite sensitive to things like compiler versions and options (as well as explicit mitigation features), but where there are a range of techniques for adjusting them for a specific target.
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")
codedokode 4 hours ago [-]
Just keep your servers with outdated versions and someone will "test" them for you.
busssard 3 hours ago [-]
the thing is exactly the urgency. If this is a
"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
13 hours ago [-]
noduerme 14 hours ago [-]
Aren't most PHP sites out there running mod_php anyway?
Ardren 14 hours ago [-]
15 years ago absolutely. Most modern sites will be running php-fpm (or maybe FrankenPHP)
kijin 11 hours ago [-]
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. Last time I checked, they still recommend against using it in production.
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. Insisting on FastCGI limits integration with more modern web servers and HTTP-speaking middleware.
educar 10 hours ago [-]
Can you share a patch or test program to test the issue?
0x1F8B 14 hours ago [-]
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.
Maxion 10 hours ago [-]
I ain't paid to find exploits in PHP, but I will be fired if our shit gets hacked. So I'm taking down the servers until there's a patch.
TheCapeGreek 9 hours ago [-]
There's been a patch since yesterday.
syshyk 4 hours ago [-]
For any instance or any known instance?
As there is always the chance, basically unfair to go that far.
SOLAR_FIELDS 14 hours ago [-]
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
codedokode 4 hours ago [-]
No. I think writing PoC and exploits is a waste of time and nobody should do it. PoC brings zero value to society and only helps criminals. If there is use-after-free, it is potentially exploitable and needs to be fixed ASAP. If you don't believe the theory, just keep using the vulnerable version.
philsquared_ 13 hours ago [-]
Bonus points put cryptocurrency private key on their server as bounty.
berkes 6 hours ago [-]
It needs only one working exploit to invalidate this post entirely.
Even if there aren't any that work OOTB today, there may be tomorrow. Or in a week. They may improve over time. They may combine other vectors. They will probably not exist on Github but somewhere on the dark web as a .zip you pay for in Monero.
They will combine shodan with fingerprinting and other ways to find "older PHP versions". There will be brute force versions, that just try every home router for insecure NextCloud. And so on.
This is real. This is dangerous. This will be exploited. Because I am sure even after all the noise, (hundreds) of thousands of PHP servers won't be updated for weeks. Many running on a forgotten corner of the web, on homeservers, on a VPS that no-one has access to anymore, in a CI, in a company on the old desktop underneath Jim's desk, on a raspberry-pi everyone totally forgot about.
joaohaas 3 hours ago [-]
There only needs to be one working exploit, and yet even with thousands of people working either manually or with LLMs, no one managed to get one so far.
Again, obvs you should patch your servers, but the point that this is not an easy exploit stands.
How do you know there is none? Because both the PHP devs themselves and the companies involved in the patches said they had working PoCs.
Do note that commonly a blackhat, or state operative will not chuck their code on github, but either try to sell it, or try to use it to quietly get footholds on strategic places.
silentbob7 6 hours ago [-]
Just like every other bug, we should patch, but calm down as there seems to be -currently- no evidence for wide rce exploitation in the wild. If that will change this would be new evidence and shall be taken into risk considerations.
Why are you speculating?
berkes 3 hours ago [-]
> Why are you speculating?
Because the PHP devs and the researchers all explicitly stated that they have PoCs that can exploit it. Are they lying? Exaggerating? Spreading FUD?
I am speculating as to why the ones who have the most information tell us something very different than a "random blogger who tried repos on github".
stickfigure 16 hours ago [-]
> It isn't a Log4J moment.
The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.
I wouldn't downplay this.
bouncycastle 14 hours ago [-]
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.
stickfigure 13 hours ago [-]
> 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.
account42 1 hours ago [-]
Sandbox violations in a technology marketed as a way to run untrusted remote code safely are RCEs.
GuestFAUniverse 13 hours ago [-]
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.
Insimwytim 15 hours ago [-]
> 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.
esikich 14 hours ago [-]
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.
kgeist 14 hours ago [-]
I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)
bunderbunder 15 hours ago [-]
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.
stickfigure 13 hours ago [-]
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.
SXX 13 hours ago [-]
> 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.
stickfigure 13 hours ago [-]
This doesn't look like a stellar track record to me.
Year CVE Vulnerability Exploitation prerequisites
2004 CVE-2004-1019 Memory corruption in unserialize() Application processes untrusted serialized data
2006 CVE-2006-4812 Integer overflow in PHP's memory allocator through unserialize() Untrusted serialized data
2007 CVE-2007-0906 Buffer overflows in bundled PHP modules and string handling Application passes attacker-controlled data
2007 CVE-2007-1286 Integer overflow in unserialize() reference counting Untrusted serialized data
2010 CVE-2010-2225 Use-after-free in SplObjectStorage deserialization Untrusted serialized data
2019 CVE-2019-11043 Buffer underflow in PHP-FPM Particular web-server configuration
2024 CVE-2024-4577 PHP-CGI argument injection on Windows Particular Windows CGI configuration
SXX 7 hours ago [-]
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.
codedokode 4 hours ago [-]
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?
SXX 3 hours ago [-]
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.
bawolff 15 hours ago [-]
I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.
upgrading php is much easier.
tptacek 14 hours ago [-]
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.
il-b 7 hours ago [-]
Log4g was exploitable from the second it was published
bakugo 13 hours ago [-]
> 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.
rcxdude 8 hours ago [-]
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.
amstan 16 hours ago [-]
On the other hand, my local qwen model (3.8-flash-next) was trying to convince me that the eMudhra CA thing is no big deal since you need to be "positioned correctly" (eg: any wifi network) to be able to MITM, and most of the IOT devices would have patched stuff by now.
hobofan 11 hours ago [-]
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. In contrast for something like PHP2Shell (if exploitable) any PHP instance exposed on the internet can be attacked by anyone from anywhere.
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.
joaohaas 8 hours ago [-]
Anyone in the connection chain can easily exploit the CA leak. Easiest example is your ISP.
pizzaiolo 12 hours ago [-]
Ah yes, IoT devices, known for their rock solid security
sznio 11 hours ago [-]
sounds like you quantized it a bit too hard
ivolimmen 10 hours ago [-]
I have the feeling that for some time now the CVE scores are insane. A while back we have a security issue with a dependency in Java that had a score of 9 I believe. It had a requirement that the attacker had root access.
dns_snek 8 hours ago [-]
Do you have the CVE number? That's not unreasonable per se, but it could be bogus as you say. A CVSS (base) score is a measure of intrinsic severity of the vulnerability in isolation which is somewhat unintuitive.
A high severity CVE can have zero impact on your system because the vulnerable code path is unreachable, and a pair of low severity CVEs in your system components/libraries can compound and create a critical vulnerability in your system.
kloop 4 hours ago [-]
I think OP's point is that, if the attacker already has root, they haven't gained any new capabilities from the CVE. They could just do whatever they wanted much more directly. Therefore, the inherent risk seems fairly low.
dns_snek 4 hours ago [-]
Yes if that was an accurate description of the supposed vulnerability then I would agree that it's bogus, but we're filling in a lot of blanks here and something tells me there's more to it than that.
saagarjha 4 hours ago [-]
*CVSS
SoftTalker 13 hours ago [-]
> 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.
jamesfinlayson 10 hours ago [-]
I think PHP is fine as long as you use a maintained framework, at least in my experience. I've used SlimPHP and Yii2 in the past and never had any security issues. I've worked on a few PHP sites that rolled their own frameworks which in retrospect was pretty iffy. One of them got yearly pen tests and there were never any issues found but the other two probably had some latent issues.
OrangeDelonge 13 hours ago [-]
I think thats said tongue in cheek.
eknkc 11 hours ago [-]
Yeah, given that the next bulletpoint is:
- The exploit video had an anime girl in it
abc42 10 hours ago [-]
That's a false dichotomy. PHP is mainly used in creating web pages, and a scripting language is not a requirement there.
If you compare it with production languages, PHP looks pretty weak.
TheCapeGreek 9 hours ago [-]
"Production languages" is a false dichotomy by implying PHP isn't one.
lelanthran 7 hours ago [-]
> If you compare it with production languages, PHP looks pretty weak.
8f your comparison excludes all the vulnerabilities they come with, sure.
In practice no one using Node is using it without npm. Same for every other language that has insane transitive dependencies for any non-trivial project.
PHP is no more vulnerable than those languages.
abc42 1 hours ago [-]
>PHP is no more vulnerable than those languages.
In theory, perhaps not. In practice, much more vulnerable.
preg_match 35 minutes ago [-]
Okay but is it though? The PHP language and runtime itself has had practically no exploitable vulnerabilities for the past 10 years.
PHP applications might do suspicious things, by choice. But the runtime itself is fine. Certainly, there are less vulnerabilities in recent years in the PHP runtime than in, say, V8.
cosinetau 11 hours ago [-]
In my Slim PHP application container, the only way I could reproduce the PHP2SHELL behavior was by adding `index.php` and `upload.php` from the attached gist to the webroot.
As others have said, there are probably other ways to reproduce it, but it requires a lot of prior knowledge of the app environment, or at least a good guess.
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.
3 hours ago [-]
3 hours ago [-]
arccy 3 hours ago [-]
what a morally self righteous comment that only serves to ruin a good song
15 hours ago [-]
citruscomputing 14 hours ago [-]
It's a normal video, I don't know what you're talking about.
sznio 11 hours ago [-]
it's the software engineering tradition
you new here?
aizk 12 hours ago [-]
Anime fans permeating throughout on the internet? Impossible. Never heard of such a thing.
rf15 10 hours ago [-]
Culture? In MY internet?
11 hours ago [-]
Genego 16 hours ago [-]
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.
judge2020 14 hours ago [-]
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 ).
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.
yeah it's funny the translation of the song is not good lol oof
adiabatichottub 15 hours ago [-]
Also, High Forever track kind of bangs
nerosk 15 hours ago [-]
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!
postalrat 15 hours ago [-]
Since when is a 200+ year old immortal considered underage?
csense 3 hours ago [-]
Amazon reports finding evidence of an exploit attempt in logs from Saturday October 17, four days before public disclosure [1].
yeah there were several exploits running live by someone before the CVE got posted
honest to god the insane 1-to-1 "show us the code!1" responses we keep seeing here make me wonder if the state-level actor is trying their hardest to keep people from patching.
it's painfully clear this is KEV and remotely exploitable on damn near every PHP install -- it's a big deal
pinevale 16 hours ago [-]
I've seen many posts like this. None of them stood the test of time. Ease is irrelevant because you only need expertise once and then everyone can reuse the result.
It's also not easy to pop an iPhone, but reliable, weaponized exploits are available in trade and governments use them in a plug-and-play way.
ameliaquining 16 hours ago [-]
The specific controversy here is about the disclosure timeline. Some people allege that the disclosure and patch release of this vulnerability were mishandled; others dispute this. The dispute turns crucially on how available exploits were during the embargo period. Nobody is arguing that the vulnerability doesn't need to be patched at all. (The PHP core team didn't initially treat it with much urgency, but they've acknowledged that this was a mistake.)
jeroenhd 10 hours ago [-]
I think it's entirely possible that the released exploit and the early released video are independent of each other. The video contains a couple of hints and stack traces, so someone could've used that to pinpoint the problem and write an exploit of their own (or, based on the website it appeared on, had an LLM generate one).
On the other hand, Chainguard did release their patches before the agreed upon time, proving they can't be trusted if you're working on coordinated patch releases. That was an absolute mess.
athrowaway3z 11 hours ago [-]
> The dispute turns crucially on how available exploits were during the embargo period.
I sure hope thats not true.
All signs indicate that writing a self-replicating exploit that'd flood the internet without warning is possible. All we know is that nobody did.
A lot of websites - especially the ones who made the call to go down first like government / healthcare - do not have the luxury of taking any risk.
Writing this blog post with the "hindsight" of no exploit going viral for several hours after the patches is - let me be frank - complete bullshit; and i dont want this person anywhere near an important system.
If by next _year_ nobody has proven a successful consistent hack, then we can start to doubt the videos. If there is, then all of this has been warranted.
Gigachad 16 hours ago [-]
Time is the whole point though. Everyone was terrified and shutting their websites down because they believed the exploit would be running wild on the internet in between it hitting git and them being able to update the server.
If it takes a week to come up with a working exploit code, the critical services have time to update.
anonymous908213 16 hours ago [-]
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.
ameliaquining 16 hours ago [-]
Yes, but that's not really relevant to the controversy over the embargo.
anonymous908213 16 hours ago [-]
Neither the OP nor any comment in this chain of replies is about the embargo?
ameliaquining 15 hours ago [-]
The controversy over the embargo is why the post was written and why we're talking about this at all.
anonymous908213 15 hours ago [-]
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.
ameliaquining 13 hours ago [-]
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.
anonymous908213 13 hours ago [-]
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.
ameliaquining 11 hours ago [-]
There's no need for an embargo before the patch is available, because the core team can just not tell anyone. It's only once there is a patch that the decision has to be made whether to embargo it.
martinald 16 hours ago [-]
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.
ameliaquining 15 hours ago [-]
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.
fomine3 14 hours ago [-]
It was true before great LLMs era
ameliaquining 11 hours ago [-]
I don't think that's very true. Certainly, modern LLMs make it much easier to discover a vulnerability given only limited clues—but if it's easy to find that way, then probably someone will do that and post it for clout. So if no one has, then it probably isn't.
athrowaway3z 11 hours ago [-]
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.
mrheosuper 16 hours ago [-]
With AI i think it's safe to assume it would only take hours after you give it what/where to look
nextaccountic 14 hours ago [-]
AI makes developing this exploit faster though
hannasanarion 16 hours ago [-]
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.
asddubs 15 hours ago [-]
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).
rf15 10 hours ago [-]
> 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.
j16sdiz 16 hours ago [-]
I guess the main takeaway is: we (humans? current methodology?) are bad at estimating how urgent a fix is or needs to be.
dguido 12 hours ago [-]
Hi, I am the CEO of Trail of Bits (https://www.trailofbits.com). We've had two of our staff independently write working exploits for this flaw. The first one took about 4 hours, start to finish. The second was a similar amount of time spread over the course of a day. We've tested our exploits to work on an unmodified MediaWiki.
tl;dr writing exploits still requires expertise, even when you're being aided by an LLM
fock 10 hours ago [-]
good to know! are these working generically against fpm with the multipart-progress disabled or against mod_php?
demibabs 11 hours ago [-]
RCEs?
chainofdisaster 10 hours ago [-]
I am also curious, but I do want to butt in to disagree with the point you're implying.
We've had red team exercises against our systems multiple times, and the victory always goes to someone who exploits not one thing in isolation, but a sequence of multiple they go around prodding for. It doesn't matter if this exploit goes 0 to 100%, as long as it works half way, I still want to hear of it.
hobofan 10 hours ago [-]
I think it's a relevant question here.
Parts of the exploit chain that was laid out in the blog posts that claim an RCE were bugs that have previously been reported. Dealing with them in the past in the severity you outline would have possibly prevented the exploit chain.
However, it's specifically the ability to complete this to an RCE what makes or breaks the headlines here.
Insimwytim 16 hours ago [-]
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.
Gigachad 15 hours ago [-]
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.
Insimwytim 15 hours ago [-]
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.
bsharper 11 hours ago [-]
That would work with TLS 1.2, but not TLS 1.3. TLS 1.3 sends the certificate after the session key is derived and symmetric encryption is established.
yorwba 8 hours ago [-]
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.
cesarb 15 hours ago [-]
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...)
jeroenhd 10 hours ago [-]
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.
furyofantares 14 hours ago [-]
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.
ameliaquining 10 hours ago [-]
That actually increased my credence that the post is correct, because it indicates that the author isn't just a blind AI skeptic.
Retr0id 16 hours ago [-]
I predict that this take will age poorly.
antiloper 9 hours ago [-]
There seems to be a group of actors, both in this thread and the one about the PHP release, that try to convince readers that patching existing PHP installations is not that critical.
I think this group has a good reason for not wanting PHP installations to get patched.
bpbp-mango 6 hours ago [-]
Agreed. Just because no one has shared the exact exploit doesn't make it not exist.
aeyes 4 hours ago [-]
It's also extremely short-sighted, a working exploit could be published at any time. The PoC was confirmed by the PHP developers so this is only a question of time.
And what do you do then? Walk around the block? Flip a coin?
syshyk 3 hours ago [-]
Other unknown exploits likely exist so we'll patch.
What you don't do is patch in a panic every patch that is out there, people are not doing this in most instances already.
So the question here is the difference between the two, and what is it based on.
SyneRyder 9 hours ago [-]
Some of them have Karma numbers around 75 and accounts created in mid September.
dhruvagoyal 13 hours ago [-]
"Script kiddies (and script adults, who have also switched their brains off)" not something i expected to hear ever but it's so real
apexalpha 7 hours ago [-]
This was absolutely exploitable. The fact 1000 not-working PoCs exist does not invalidate the one that does.
Sure maybe not on a vanilla install but most people don't install Php, they use a pre-made container or a platform using Php under the hood.
Yesterday I simply wasn't confident in the security anymore and the data in my database is important enough to go offline for a few hours.
pier25 12 hours ago [-]
Maybe the author does have a point. There are millions of PHP websites and do we know of any that was pwned?
Not to take away from the GP's claims but where in that whois does it say 3 days old? The page has two posts, one is "We are all doomed" and the other is "AI is bad at what it supposedly does", first post created (according to the site itself) just after the domain was registered 20 days ago.
tgv 8 hours ago [-]
The whois creation date is 2026-10-02, which is 20 days ago. I suppose the parent misinterpreted something.
QuantumNomad_ 8 hours ago [-]
Probably misread 2026-10-02T19:14:35Z by glancing at it too quickly and thinking it said 2026-10-19. With 19 coming from the clock hour after T.
I think the main point is mostly the same regardless of that though. 3 days ago or 20 days ago it’s a very recently created site.
stef25 8 hours ago [-]
Creation date ?
sippingabonedry 8 hours ago [-]
22 - 2 is not 3; did you write the key generation scripts for the eMudhra CA?
pfych 9 hours ago [-]
It looks to be at least 20 days old, with another blog post on the site
yreg 10 hours ago [-]
The article should be easy to refute (if it is wrong).
Chainguard broke the embargo being convinced they have the evidence of this being widely exploited already yesterday. Where is it?
quotemstr 10 hours ago [-]
Everyone has evidence of widespread exploit attempts. I totally believe that there are widespread attempts. Where are the compromises?
vanviegen 8 hours ago [-]
Why would you do attempts on someone else's server if you haven't been able to exploit a local server yet?
milkshakes 8 hours ago [-]
what makes you so sure these would be publicized? what incentive does an adversary have to be loud about it?
whizzter 8 hours ago [-]
I wouldn't be surprised about a timeline like
1: Wiz finds the exploit , begins responsible patching procedure
2: Chainguard,etc gets to know about it, adds some monitoring on top of their patches.
3: OpenAI being happy for the upcoming publicitiy starts an automated run to _count_ vulnerable instances for _marketing_ purposes.
4: Chainguard interprets it as wild exploitation and pulls the trigger early.
milkshakes 7 hours ago [-]
lol.
> I wouldn't be surprised
yeah i am not surprised you're not surprised. you seem to have already made up your mind. that said, every single guess you have made here is completely incorrect and not based in facts at all.
literally you have no idea what you're talking about! but don't let that stop you from having an opinion
quotemstr 8 hours ago [-]
Any particular compromise might not be published. But 70% of the internet is vulnerable. Even with a low reporting rate, wouldn't you expect to see something?
yorwba 8 hours ago [-]
Surely all the websites that had scheduled downtime for the patch are no longer vulnerable? Would be kind of pointless otherwise.
hypfer 10 hours ago [-]
> easy to refute
Please keep in mind that Brandolini's law exists, and so does a whole arsenal of stuff like the Gish Gallop.
Also, extraordinary claims require extraordinary evidence, and here, the extraordinary comes from that blogpost's claim, as the developers saying "yes the software we made is actually broken" is not extraordinary.
sippingabonedry 8 hours ago [-]
> so that they end up with 200 comments on #2 on the HN front page
I'm more curious why the top post in this thread is solely attacking the guy's character and not refuting any of his claims.
> An empty blog by a person that may or may not exist with no contact info.
I'd hate to upset all the 'this guy is Keyser Söze' internet detectives, but you've described 90% of posters here (including yourself).
stnikolauswagne 8 hours ago [-]
> I'm more curious why the top post in this thread is solely attacking the guy's character and not refuting any of his claims.
I read the blogpost and was left waning on the post actually making strong claims. "The biggest starred PoCs on Github are not viable exploits" does little satisfyingly justify "This vulnerability is not a big deal". The kind of malicious actors who would exploit this vulnerability at scale have no incentive to make their own versions public and without the author showing some serious expertise I see little reason to trust them at their word.
>I'd hate to upset all the 'this guy is Keyser Söze' internet detectives, but you've described 90% of posters here (including yourself).
Exactly, it however does not really apply to the actors warning of the exploit, from what I can tell there is at least some track record there.
rf15 10 hours ago [-]
Yes, but the same is true about LLM output. Guess there's actually no way around this than to go look yourself.
silentbob7 10 hours ago [-]
The question remains: is vanilla PHP with its default configuration easily exploitable? What are the prerequisites, and what configuration deviations are required compared to default config in the anime girl video?
whizzter 8 hours ago [-]
I'd say yes-ish, the 9.2 rating hints that it's not a straight to-shell exploit, but still serious enough that the step is probably easy enough, imagine the DB connection string or similar leaking through the working memory leak.
The reason it's so bad is because the multipart/form-parsing by the accounts I've read happens- or begins before the PHP code is actually run, ie it's in the initial runtime stage of a request.
hypfer 10 hours ago [-]
If core developers say "this is actually bad", don't bargain if a patch is needed. Patch it.
There is no higher authority on "this is actually fucked" other than the people that actually make that very sausage.
Patching it is painful. It needs to be done regardless.
silentbob7 10 hours ago [-]
Yes, we should all patch like every other bug - but its the CVSS score and the panic which is in question.
hdgvhicv 9 hours ago [-]
I think I’ve identified every device on my internal networking running php, but I’d love a reliable poc I could poc that I could run before someone starts lateral movements.
If it’s easy to exploit then it should be easy to find a POC
ferngodfather 9 hours ago [-]
CVSS scores are a bad measure anyway
hypfer 10 hours ago [-]
Yeah mentioning that a lot of nonsense has been happening with LLMs is the truth anchor that untruthful writing uses to pass through people's firewalls.
Not too dissimilar to anti-vaxx stuff or that whole other space of these kinds of dysfunctions.
You always need some kind of hook that is correct.
amoss 9 hours ago [-]
Why would the identity of the author relate in any way to the correctness of their claims?
The claims:
* The existing exploits don't work.
* Reasoning chains producing an exploit have cheated the test.
If the claims are wrong then rebutting them is easy:
* Ask an LLM to produce a real exploit.
* Test it.
fartfeatures 8 hours ago [-]
Humans use heuristics such as credentials to navigate an overwhelmingly complex world. They are not infallible but they are quick enough and right enough that we reach for them instinctively.
amoss 5 hours ago [-]
Explaining what a heuristic is does not address why one should be used in this case.
eecks 5 hours ago [-]
and it's often not the right thing to do. Let's say the blog post was from a top social media influencer. Would that carry more weight for you? We should look at the content of the post more than the poster.
heliomattress 9 hours ago [-]
they have contact info. look at the first post [0] on the blog, it has their email, zkldi@proton.me
the user "zkldi" is who submitted it to hn also. seems like a real person to me.
edit: unless there is AI that fakes being human since 2021 and has its own Twitch channel in order to post a blog post to Hacker News.
hypfer 8 hours ago [-]
Let's run with that then, shall we?
> I'm a 21 year old programmer from the UK. In my free time, I play ITG and create rhythm game adjacent stuff.
Is this a good source for "actually, the people are wrong and you shouldn't worry. This is overblown"?
Should that be guiding people's decisions on how to treat this very real and confirmed by the devs and third parties vulnerability?
karel-3d 7 hours ago [-]
I have no idea! I just react to the claim that this is not a real person. I have no idea if there is a PHP exploit, I have not looked that hard; but it is interesting nobody actually linked one so far, and all the write-ups people link are obviously LLM generated.
But again this is very very simple to refute by actually linking a working PoC.
hypfer 7 hours ago [-]
You've misread the claim.
Which is partially on me, of course, but also not.
The statement was that it's not a real (primarily as in credible, relevant. Actually real also an aspect but not the primary one) person.
There could technically be a human behind it, just like Jia Tan could've been a human. But for judging the input, that is irrelevant and misleading.
The biggest problem reality is facing is that people's consensus operates on "having every voice heard", which is good in a small village, but terrible in a globalized internet.
And thus, if we want to keep "every voice needs to be heard", we need to reclassify "voice" and "real" not just on "has cells".
That's the mental shorthand I operate on, which I should have resolved down fully to make it work with "normal" people's brains. Regrettably.
vintermann 10 hours ago [-]
At least it wasn't the lighthouse keeper Elias Thorne.
Should be easy enough to verify the central claim that you need to be able to read the password file through some other means to use this exploit.
syshyk 3 hours ago [-]
Don't trust their site, but entire new sites dedicated to exploits with fancy graphics spin up at short notice with exploit logos and we drool...
pms 8 hours ago [-]
Ad hominem attacks on HN, at the top of a comment thread, just because LLMs were criticized by a human. Welcome to the new age.
quotemstr 10 hours ago [-]
> And who exactly is Elias Taylor
A human being, presumably. But he could be a dog or a diffusion model and I wouldn't care, because arguments stand on their own. There is no special caste of people who alone have permission to propose ideas.
You advocate critical thinking. Excellent. Can you critically evaluate "Elias Taylor"'s argument?
lwhi 10 hours ago [-]
For all we know, Elias Taylor has been fabricated in order to remove the sense of urgency from as many sysadmins and devops as possible.
arc-in-space 9 hours ago [-]
I literally know them in person. It's a guy. They have a signal and an email right there, you can message them and talk it's not that deep
hypfer 9 hours ago [-]
Can you tell them that they're acting recklessly here then?
CER10TY 9 hours ago [-]
Are they, though? I seriously doubt some sysadmin is going to look at this and say "Maintainers said to patch, but clearly _this guy_ knows better, so I won't."
Besides, he's got a point. The initial PoC that kept popping up on Mastodon (the ones he linked in the post as well) simply didn't work. One of them even posted an updated exploit later that still didn't work, but supposedly meant the vulnerability went from CVSS 10 to CVSS 4.
lwhi 9 hours ago [-]
I know someone who hacked his own site using the exploit and managed to obtain a database dump.
lwhi 9 hours ago [-]
Well, tell him from me, he'll probably regret writing the article when he reaches his thirties.
hypfer 9 hours ago [-]
Which, if true, would at least be kinda funny and would hit institutions that deserve it for having failed to hire trustworthy people that aren't susceptible to that.
So that's a silver lining I guess.
Whoever gets pwned due to this might get naturally out-selected. The system works!!11 Thank you darwin.
quotemstr 9 hours ago [-]
If Satan himself proves a theorem, is it nevertheless a true theorem? Claims are either true or they are false. There is no such thing as an evil truth. Where are the breaches?
lwhi 9 hours ago [-]
But don't you understand? The aim wasn't to prevent the breaches that would inevitably happen on day one; it was to prevent the breaches that would happen after that fact. Without mobilising everyone and getting people to patch through an event, we'd be in a far worse position.
The greatest trick that Devil performed was convincing people that he didn't exist, right?
eecks 5 hours ago [-]
> There is no special caste of people who alone have permission to propose ideas.
I love this
aaron695 8 hours ago [-]
[dead]
letmevoteplease 13 hours ago [-]
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.
malfist 13 hours ago [-]
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
decidu0us9034 10 hours ago [-]
Okay finally some sense. I felt like I was going insane seeing the freakout over this. From people who would care but a fraction if there weren't some AI angle.
TekMol 7 hours ago [-]
There is a strong indicator that this is true:
There is no news about hacked websites due to this vulnerability.
If anyone could ask Claude for an exploit, one would expect a lot of PHP sites to be hacked just for the fun of it, right? Like putting a message on some popular website or something.
silentbob7 7 hours ago [-]
I'm not sure why there are personal attacks on this blogger, his reputation and when the domain was registered.
The question remains: is vanilla PHP with its default configuration easily exploitable? What are the prerequisites, and what configuration deviations are required compared to default config in the anime girl video?
Nemo_bis 7 hours ago [-]
I'm tempted to agree but at the same time we never (?) had news of confirmed data breaches due to log4shell exploits either, so perhaps people are just good at staying quiet when they get attacked.
> Despite the high volume of exploit attempts following the discovery of the Log4Shell vulnerability, reports of major breaches were relatively few. One of the first significant attacks targeted the Belgian Ministry of Defense. Reported on December 12th, just three days after the vulnerability became widely known, the Ministry did not disclose specific details but confirmed the Log4J vulnerability as the attack vector.
Log4shell did not get that bad because it was only the less used version 2 that was effected.
The standard way hackers go about today is data theft and extortion. I think we would have heard about it if was a big problem.
People should off cause keep their servers up to date no matter what. The total panic that was yesterday with people posting all kinds of random AI slop was pathetic.
NohatCoder 2 hours ago [-]
This is such a bad take.
1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.
2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.
3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.
4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.
richardbarosky 16 hours ago [-]
What kind of pisses me off was that there were kind of two sides of the continuum.
You've got the detailed technical writeup on one end 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.
People mistake OpenAI and Anthropic for AI companies, but they are in fact primarily in the business of marketing, and business is good.
ameliaquining 15 hours ago [-]
Every business is in the business of marketing, that's a meaningless distinction.
15 hours ago [-]
taikahessu 14 hours ago [-]
There's no ai in mrketng.
rklaehn 10 hours ago [-]
I think this is way overthinking it. It's PHP. Even 2, 3 years ago before usable LLMs, if somebody had told me there is a remote execution vulnerability in php I would have found it completely plausible.
commandersaki 15 hours ago [-]
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.
zer00eyz 15 hours ago [-]
> 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.
sheepscreek 3 hours ago [-]
Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot[1]
I don't know about easy, but plenty of exploits in the wild. Easy is relative, you know.
There are entire states pushing for, and corporations built on exploiting 0 day vulnerabilities[2]. They will spend millions to hack an entire platform so they can somehow infiltrate 1 customer that they care about. Some high value target. There's a good chance that any innocent looking business has some high value (in the eyes of intelligence community) customers.
The attack vectors they use are sophisticated, gaining access to multiple systems, much like how OpenAI agents got through to HuggingFace servers[3].
So knowing what we know now, it's naive to think people are calling wolf, they are not. They just happen to know something most don't.
Many apps (eg chrome) frequently fix bugs that are actively exploited in the wild yet have no public weaponized chain (sometimes for months).
The fact that there is no fully public weaponized chain does not mean it does not exist or that this bug is not as scary. It only means that it is not as trivial to exploit as log4shell/shellshock/etc.
According to cloudflare [1], it is being exploited in the wild.
It's like y2k. Yeah, there isn't much of a problem currently. We're patching before it becomes a problem. That's not Bot Who Cried Wolf*, that's responsible security. You don't have to wait for a YouTube tutorial on how to do it before it's something to urgently patch.
*My phone autocorrected to that and I'm keeping it.
hdgvhicv 8 hours ago [-]
The panic yesterday was “shut down now until the patch comes out as it’s already being exploited”
Where are the mass successful exploits? Why is this different to any other patch?
necovek 10 hours ago [-]
Can you explain how you got from "attempts to exploit it" to "exploited in the wild"?
JereCinkan 10 hours ago [-]
"Luckily, the window didn't break, which means the thief never existed"
JensenTorp 9 hours ago [-]
Where are the hacked websites? That is the litmus test. I'm looking around and I see... nothing?
SyneRyder 9 hours ago [-]
[flagged]
sam_lowry_ 8 hours ago [-]
I have more karma, and I wonder where are the hacked websites as well.
SyneRyder 7 hours ago [-]
That's cool, I can answer this more kindly then.
If you're looking for obvious site defacements, something loudly compromised... that's usually not the game here. What is more likely is persistent covert shell access, hiding underneath. Accessible only to those who know the way in, doesn't draw attention to itself so it can persist for a long time before being used... a bit like the 11 month old account you've referenced here, that gets used to comment on this thread.
Sites with shell access become useful as part of botnets, for DDoS attacks. Setting up VPNs to provide lateral movement across to other websites. Why blow your cover by announcing your presence? A lot more damage is done in stealth.
I'm not in cybersecurity, but if you hunt around you'll find enough info about sites getting caught up in this.
exfalso 7 hours ago [-]
Because clearly when you hack and rootkit a box, the first thing you do is announce it to the public
xmcqdpt2 6 hours ago [-]
The exploit requires OOM, no? Half-decent observability should detect it easily.
duxup 2 hours ago [-]
>now people are being deluded by their LLMs telling them they have an exploit when they don't
I’ve found that if I’m looking into security issues that if you ask an LLM about a “security” issue… it will find one regardless if you have one or not. Like some over eager security consultant desperate to justify their job / collect more billable hours.
This is especially true if you have a bunch of server logs and ect.
mushufasa 4 hours ago [-]
surprised I haven't already seen a "git gud" comment.
Honestly it really shouldn't matter if most attackers can't find the exploit; it only takes one bad actor to wreak havoc. And I have seen already several sec YouTubers post live exploit walkthroughs so....
He says it isn't an easy exploit but never explains why it isn't an easy exploit?!
bob1029 10 hours ago [-]
> It's been 10 hours since this vulnerability has been posted, and half the software world is looking at it, and lord knows 100,000 people have got their "superintelligence" on the case.
This is the most compelling argument presented. If this PHP vulnerability were actually so bad, we'd be probably be seeing some kind of widespread impact by now. If every potential target requires a second coincidental, target-specific vulnerability I think we should probably call off the search party.
The alternative way to describe this situation is "defense in depth". We've located a very thick part of the ship hull that we could technically drill through if we had enough time and money to do so, but this would not scale up in any meaningful way. What you can do to a vessel in dry dock vs on the open seas are two wildly different universes. Vulnerabilities located under pristine lab conditions or within the context window of a clanker do not bring me much concern.
yamanahlawat 13 hours ago [-]
>> 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...
machiaweliczny 6 hours ago [-]
I guess motivated state actors might still find a way to cause issues
chinathrow 10 hours ago [-]
Not easy, but there are some. That's enough.
13 hours ago [-]
16 hours ago [-]
Tadpole9181 16 hours ago [-]
> So why was everyone so scared?
I think this section misses the mark.
The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer.
Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked".
So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do?
We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?"
So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires.
This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad.
thomasfromcdnjs 16 hours ago [-]
Yeah, I suggested to take down the app someone between seeing the Gina (core) comment (saying php.ini etc changes won't do anything) and after seeing the Cloudflare CTO tweet.
fwlr 14 hours ago [-]
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.
malfist 13 hours ago [-]
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.
fwlr 13 hours ago [-]
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
Celeo 16 hours ago [-]
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.
lgl 16 hours ago [-]
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.
tommica 10 hours ago [-]
I fell for the fear mongering, which annoys me.
It was some good drama, and honestly I didn't even know LLM was involved so heavily in it. But damn annoying that people blindly believed LLMs and I blindly believed those people.
15 hours ago [-]
lwhi 9 hours ago [-]
I'm waking up in the UK and thinking about the incident in the cold light of a new day, and things actually seem far worse to me.
What about our routers? What about Home Assistant? What about IoT?
Vulnerabilities are going to surround us, many of which will never ever be patched.
We may well be fucked.
venzaspa 6 hours ago [-]
That has been the reality for your whole digital existence and will continue long into the future. We can only do the best we can.
lwhi 6 hours ago [-]
True, but I imagine there will eventually be a tipping point.
shevy-java 7 hours ago [-]
Finally the web-services I needed are back, but boy
was this annoying. I lost some time since things got
pushed back - all because PHP was not written with
security in mind. Yes, features matter too, ease of
use, functionality but .... I don't know. I think you
need to also put security on the same level of
scrutiny; taking control over servers is a huge glaring
issue. That simply should not be possible.
tamimio 15 hours ago [-]
>script kiddie
Get on time, pa, they are called LLM kiddie now
0xbadcafebee 15 hours ago [-]
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).
SoftTalker 13 hours ago [-]
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.
abootstrapper 12 hours ago [-]
Reminds me of how Y2K was a "nothing burger," because of the effort that was put into making that so.
lincon127 9 hours ago [-]
Makes sense
lifeisloving 11 hours ago [-]
I just like to imagine the japanese PM being woken up in the middle of the night with an assistant holding a laptop, they open it and they watch the anime girl dancing around with that techno song in the background and start panicking.
Vibecoded on purpose without any of my influence, just to prove a point that a local Qwen3.8 model that's post trained on DeepSeek's reasoning traces makes this exploit and the necessary Heap Feng Shui totally feasible.
bshalom 9 hours ago [-]
"The exploit video had an anime girl in it"
lifeisloving 12 hours ago [-]
The dancing anime girl was the best part of all this lk.
gkanai 11 hours ago [-]
The original video from where the dancing girl was taken from (she's a vtuber, not in an anime) has 148 million views.
148 mil views is crazy. It goes hard with that techno and glitch effect on that PoC.
cindyllm 11 hours ago [-]
[dead]
nalekberov 7 hours ago [-]
Fear-mongering as a Service.
ajross 16 hours ago [-]
It's a digression, but FTA:
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
theamk 15 hours ago [-]
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)
lelanthran 3 hours ago [-]
> 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.
theamk 2 hours ago [-]
No, they used a language where the preferred way to share memory is raw pointers. That is the problem.
Every language has a preferred way to deal with things. In C, it's raw pointers, which are very error prone. Other languages have something better. For example, if you were to implement custom allocator in C#, would you return raw pointer? Or maybe base array + offset pair? Of course not, you'd choose a Span or Memory, and those are not prone to buffer overruns.
ajross 1 hours ago [-]
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.
Edit to address the specific example: OpenSSL would never have been written in .NET in the first place, being very performance/hardware sensitive (there's a bunch of platform assembly in TLS implementations) and by its nature designed to be needed by all/almost-all software on a system. The argument everyone would reach for here would be Rust. But in Rust, the same logic that led to the custom allocator would probably produce an unsafe-based equivalent (which is true for almost all heavily optimized rust, sort of a dirty secret).
phyzome 15 hours ago [-]
Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?
insanitybit 15 hours ago [-]
It was.
tptacek 16 hours ago [-]
Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.
(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)
ajross 1 hours ago [-]
Well, yeah. But client vulnerabilities are likewise annoying to get working, being vastly more amenable to defense in depth techniques like sandboxing and firewalls and permissions strategies, yada yada. Which is why there are no client holes in the author's list of "break the world" problems. The most impactful attacks against clients are targetted zero-days. Which are bad! But not as bad as e.g. Log4Shell[1].
[1] My favorite example in this kind of argument just because it's so obviously understood and non-technical. All the pedantry in the world wouldn't have fixed that, it was the combination of a bunch of correctly implemented and useful features.
insanitybit 15 hours ago [-]
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.
redox99 15 hours ago [-]
Huh? Heartbleed is literaly memory safety (buffer over read)
edf13 7 hours ago [-]
[dead]
elmer2 17 hours ago [-]
[flagged]
cookiengineer 16 hours ago [-]
[removed]
lukev 16 hours ago [-]
If anything, claiming that this vulnerability has been known and unpatched for 22 years supports the author's point: clearly it's not that easy to actually use.
edoceo 16 hours ago [-]
WAS not easy, now it's much easier.
stuffoverflow 15 hours ago [-]
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.
asddubs 16 hours ago [-]
Do you have any links to a working PoC that appeared before the details were released? I'm seeing a lot of conflicting info, and I'm not really sure what to think. People saying they were seeing people trying to exploit this hours ahead of the patch release on their servers, yet no one who seemingly actually got pwned by it (were people just misreading their logs?)
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.
How about trying to verify the claims with your own brain? It seems you missed the main point of the article.
abofh 13 hours ago [-]
When they confuse the CA issue and the PHP issue in the opening paragraph, I have a hard time trusting their analysis
Dylan16807 13 hours ago [-]
"I know, I know. It's all you're hearing about. That, and the number 4."
Doesn't look like confusion to me.
imwally 13 hours ago [-]
[dead]
noduerme 15 hours ago [-]
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.
minitech 14 hours ago [-]
> 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.
noduerme 13 hours ago [-]
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.
minitech 13 hours ago [-]
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.
xmcqdpt2 6 hours ago [-]
You can read and write to other processes memory addresses on Linux using /proc/mem,
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 ;)
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.
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...
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.
Both of them are well known in cybersecurity but are very different people with very different reputations.
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? Actual experts, like in most industries, are not the most visible.
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 everywhere 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 think the problem that "coordinated disclosure" has too many people and companies with conflicts of interest.
For example, this PHP "coordinated disclosure", you have:
Then governments probably have various "pro alerts" subscriptions so they get all in a panic because the company sending out the alerts starts ringing the alarm bells.Meanwhile the rest of the world with good-old LAMP (Linux Apache Mysql PHP) installations ? Meh ... a mere afterthought to the money-making opportunities. Some posts on HN suggest there was a 2 month delay between discovery and "coordinated disclosure" ?
Historically you might have written this off as an un-necessarily cynical view. But sadly I think it is a valid reflection of the world we live in today.
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.
> What we demonstrated > Pre-authentication RCE on WordPress, Drupal and Joomla
[0] https://www.wiz.io/blog/php2shell-php-rce
The RCE exploit is application dependent: it requires exploitable PHP code already deployed in the server. However, that exploitable code path is widely deployed by the most popular PHP software: WP, Drupal, Joomla, etc, so in practice most PHP deployments are vulnerable to the RCE attack.
Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.
Great, so show us a working exploit.
Buy 5$ on deepseek and have it write a script to grind out the right offsets to use for the most popular docker images.
I got it working just now; shell on any docker image i pull.
GG this dumb ass blog-post and thread.
1. An attacker identifies a publicly accessible website running vulnerable PHP.
2. They send specially crafted HTTP requests to the website.
3. The requests trigger vulnerabilities in PHP's internal memory handling.
4. If exploitation succeeds, the attacker can execute arbitrary code on the server under the privileges of the affected PHP process.
Either that, or I wasn't fully awake when I wrote it.
https://calif.io/php2shell/
https://www.wiz.io/blog/php2shell-php-rce
https://openai.com/index/coordinated-disclosure-of-critical-...
> Using Gemini 4 Argon, the team at Wiz has shown why frontier AI is a game-changer for cyber defense. For over a decade, these critical vulnerabilities remained unaddressed because vulnerability discovery and exploitation were incredibly complex.
- Raluca Ada Popa, Head of Gemini Security, Google DeepMind
"Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports."
https://thephp.foundation/blog/2026/10/21/todays-php-securit...
be me
click link
typical ai-designed website
I wouldn't be so sure. Many vulnerabilities have been "fixed" by blocking the particular ingress path of the demo exploit, and then it turns out that there were plenty more ways to exploit the bug, they just picked the easiest one.
Poster and comic story by Michal Zalewski (@lcamtuf) of Calif."
DSHR's Blog
I'm David Rosenthal, and this is a place to discuss the work I'm doing in Digital Preservation.
Tuesday, June 30, 2026
Coprophagia Is Bad For You
https://blog.dshr.org/2026/06/coprophagia-is-bad-for-you.htm...
I'm actually curious if a lot of shit got hacked because so far it doesn't seem so. Though it seems like it should have? We always see these catastrophic vulnerabilities showing up but when are the ones where it is actually just widespread publicly dumping databases everywhere and at a point where someone non technical even registers it.
The latest POC video for the php2shell exploit features a dancing anime girl. How would you create a video like this?
You would need to hire the team that made the original video (which as of this comment has 148 million views)
https://www.youtube.com/watch?v=Ci_zad39Uhw
More seriously, though, I read it as bad because of the potential. All versions of PHP going back a full two decades were affected, all users of PHP are affected regardless of which features they use, and it’s still unclear if there’s an effective mitigation. So the blast radius if anyone does/did have a working exploit would have been enormous.
Your average site is fine at 99.9% uptime.
"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.
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
> 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.
Trying to understand what the message of the post is all about, I flipped the whole thing around in my head - and the message is basically "you don't need to upgrade your servers". Which is something someone with a working exploit would say. Or it's just noise on the Internet.
> You should patch your servers anyway. There is a real vulnerability here, but exploiting it is significantly harder than people are making it out to be.
The take-home message is about human herding behavior being reinforced by LLM use:
> 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. You've got this bizarre case of "Decision Schelling Points" where a method of solving a problem is extremely overrepresented, because it's what Claude does out of the box.
---
Having Claude re-inforce to people the severity - who do not have the security background to make a call - is a feature of herd behavior.
The risk is all that mattered.
The risk, unless the original reports have been lies, is very real.
Posting this AI complaint-blog because with hours of hindsight nobody released a seflreplicating variant, is the wrong lesson at the wrong time for the wrong reasons.
I guarantee you there well be a better time to post this complaint about AI-driven herd behavior. But it was not today about this.
Why attacking him personally?
Try telling people they are wrong often enough it happens a lot. ad hominem.
Virtue signalling is really coming more of a problem these days, specially in the security sphere.
Indeed. And those who knows how to implement this, might also be the ones with capabilities to deploy it on a large scale (via bot nets or whatever).
What about state actors, suddenly getting a possibility to plant backdoors in millions of websites, etc.
You don't have to be too imaginative to see the "economics" of this.
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
* 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.
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.
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")
"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
PHP does need to invest more in the built-in web server, though. Last time I checked, they still recommend against using it in production.
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. Insisting on FastCGI limits integration with more modern web servers and HTTP-speaking middleware.
As there is always the chance, basically unfair to go that far.
As Linus says: talk is cheap; show me the code
Even if there aren't any that work OOTB today, there may be tomorrow. Or in a week. They may improve over time. They may combine other vectors. They will probably not exist on Github but somewhere on the dark web as a .zip you pay for in Monero.
They will combine shodan with fingerprinting and other ways to find "older PHP versions". There will be brute force versions, that just try every home router for insecure NextCloud. And so on.
This is real. This is dangerous. This will be exploited. Because I am sure even after all the noise, (hundreds) of thousands of PHP servers won't be updated for weeks. Many running on a forgotten corner of the web, on homeservers, on a VPS that no-one has access to anymore, in a CI, in a company on the old desktop underneath Jim's desk, on a raspberry-pi everyone totally forgot about.
Again, obvs you should patch your servers, but the point that this is not an easy exploit stands.
Do note that commonly a blackhat, or state operative will not chuck their code on github, but either try to sell it, or try to use it to quietly get footholds on strategic places.
Why are you speculating?
Because the PHP devs and the researchers all explicitly stated that they have PoCs that can exploit it. Are they lying? Exaggerating? Spreading FUD?
I am speculating as to why the ones who have the most information tell us something very different than a "random blogger who tried repos on github".
The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.
I wouldn't downplay this.
They may be rare today but they have historically been very common.
> To the point where they had to ban java applets from the web.
Those are not RCEs, they were sandbox violations. Sandboxing untrusted code is hard and really only javascript engines have pulled it off. Java and Dotnet gave up, and that's fine.
PHP's security failures are not from trying something ambitious. They're from generating web content on a server. These are not comparable.
I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.
Merely declaring a transitive dependency didn't mean that the code was executing nor did it mean that user input was actually being logged through those libraries.
Log4j v2 (the vulnerable version) just wasn't that common at the time. Most everyone had moved on to Logback, and Log4j v1 (not vulnerable) was still more popular than v2.
Some software written in PHP has a long history like that.
PHP itself mostly dont. Tbh runtime itself has fairly stellar track record on security considering it written in C.
Year CVE Vulnerability Exploitation prerequisites
2004 CVE-2004-1019 Memory corruption in unserialize() Application processes untrusted serialized data
2006 CVE-2006-4812 Integer overflow in PHP's memory allocator through unserialize() Untrusted serialized data
2007 CVE-2007-0906 Buffer overflows in bundled PHP modules and string handling Application passes attacker-controlled data
2007 CVE-2007-1286 Integer overflow in unserialize() reference counting Untrusted serialized data
2010 CVE-2010-2225 Use-after-free in SplObjectStorage deserialization Untrusted serialized data
2012 CVE-2012-1823 PHP-CGI argument injection Vulnerable CGI deployment
2014 CVE-2014-8142 Use-after-free in PHP's unserialize() implementation Untrusted serialized data
2015 CVE-2015-0231 Use-after-free in PHP's object deserialization Untrusted serialized data
2015 CVE-2015-2787 Another use-after-free in unserialize() Untrusted serialized data
2016 CVE-2016-10160 Memory corruption in PHP's PHAR extension Application processes crafted PHAR archive
2019 CVE-2019-11043 Buffer underflow in PHP-FPM Particular web-server configuration
2024 CVE-2024-4577 PHP-CGI argument injection on Windows Particular Windows CGI configuration
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.
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.
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.
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.
A high severity CVE can have zero impact on your system because the vulnerable code path is unreachable, and a pair of low severity CVEs in your system components/libraries can compound and create a critical vulnerability in your system.
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.
- The exploit video had an anime girl in it
If you compare it with production languages, PHP looks pretty weak.
8f your comparison excludes all the vulnerabilities they come with, sure.
In practice no one using Node is using it without npm. Same for every other language that has insane transitive dependencies for any non-trivial project.
PHP is no more vulnerable than those languages.
In theory, perhaps not. In practice, much more vulnerable.
PHP applications might do suspicious things, by choice. But the runtime itself is fine. Certainly, there are less vulnerabilities in recent years in the PHP runtime than in, say, V8.
As others have said, there are probably other ways to reproduce it, but it requires a lot of prior knowledge of the app environment, or at least a good guess.
https://gist.github.com/mashiox/462e15b45a4c891b3a843e11b1d2...
> 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)
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.
you new here?
All I know of Laughing Man in relation to exploits is from a small niche MMORPG called Toontown Online ( https://youtu.be/sGED1WcJhOM ).
https://en.wikipedia.org/wiki/Ui_Shigure
[1] https://news.ycombinator.com/item?id=50194070
honest to god the insane 1-to-1 "show us the code!1" responses we keep seeing here make me wonder if the state-level actor is trying their hardest to keep people from patching.
it's painfully clear this is KEV and remotely exploitable on damn near every PHP install -- it's a big deal
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.
On the other hand, Chainguard did release their patches before the agreed upon time, proving they can't be trusted if you're working on coordinated patch releases. That was an absolute mess.
I sure hope thats not true.
All signs indicate that writing a self-replicating exploit that'd flood the internet without warning is possible. All we know is that nobody did.
A lot of websites - especially the ones who made the call to go down first like government / healthcare - do not have the luxury of taking any risk.
Writing this blog post with the "hindsight" of no exploit going viral for several hours after the patches is - let me be frank - complete bullshit; and i dont want this person anywhere near an important system.
If by next _year_ nobody has proven a successful consistent hack, then we can start to doubt the videos. If there is, then all of this has been warranted.
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.
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.
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.
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.
tl;dr writing exploits still requires expertise, even when you're being aided by an LLM
We've had red team exercises against our systems multiple times, and the victory always goes to someone who exploits not one thing in isolation, but a sequence of multiple they go around prodding for. It doesn't matter if this exploit goes 0 to 100%, as long as it works half way, I still want to hear of it.
Parts of the exploit chain that was laid out in the blog posts that claim an RCE were bugs that have previously been reported. Dealing with them in the past in the severity you outline would have possibly prevented the exploit chain.
However, it's specifically the ability to complete this to an RCE what makes or breaks the headlines here.
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.
I think this group has a good reason for not wanting PHP installations to get patched.
And what do you do then? Walk around the block? Flip a coin?
What you don't do is patch in a panic every patch that is out there, people are not doing this in most instances already.
So the question here is the difference between the two, and what is it based on.
Sure maybe not on a vanilla install but most people don't install Php, they use a pre-made container or a platform using Php under the hood.
Yesterday I simply wasn't confident in the security anymore and the data in my database is important enough to go offline for a few hours.
I think the main point is mostly the same regardless of that though. 3 days ago or 20 days ago it’s a very recently created site.
Chainguard broke the embargo being convinced they have the evidence of this being widely exploited already yesterday. Where is it?
1: Wiz finds the exploit , begins responsible patching procedure
2: Chainguard,etc gets to know about it, adds some monitoring on top of their patches.
3: OpenAI being happy for the upcoming publicitiy starts an automated run to _count_ vulnerable instances for _marketing_ purposes.
4: Chainguard interprets it as wild exploitation and pulls the trigger early.
> I wouldn't be surprised
yeah i am not surprised you're not surprised. you seem to have already made up your mind. that said, every single guess you have made here is completely incorrect and not based in facts at all.
literally you have no idea what you're talking about! but don't let that stop you from having an opinion
Please keep in mind that Brandolini's law exists, and so does a whole arsenal of stuff like the Gish Gallop.
Also, extraordinary claims require extraordinary evidence, and here, the extraordinary comes from that blogpost's claim, as the developers saying "yes the software we made is actually broken" is not extraordinary.
I'm more curious why the top post in this thread is solely attacking the guy's character and not refuting any of his claims.
> An empty blog by a person that may or may not exist with no contact info.
I'd hate to upset all the 'this guy is Keyser Söze' internet detectives, but you've described 90% of posters here (including yourself).
I read the blogpost and was left waning on the post actually making strong claims. "The biggest starred PoCs on Github are not viable exploits" does little satisfyingly justify "This vulnerability is not a big deal". The kind of malicious actors who would exploit this vulnerability at scale have no incentive to make their own versions public and without the author showing some serious expertise I see little reason to trust them at their word.
>I'd hate to upset all the 'this guy is Keyser Söze' internet detectives, but you've described 90% of posters here (including yourself).
Exactly, it however does not really apply to the actors warning of the exploit, from what I can tell there is at least some track record there.
The reason it's so bad is because the multipart/form-parsing by the accounts I've read happens- or begins before the PHP code is actually run, ie it's in the initial runtime stage of a request.
There is no higher authority on "this is actually fucked" other than the people that actually make that very sausage.
Patching it is painful. It needs to be done regardless.
If it’s easy to exploit then it should be easy to find a POC
Not too dissimilar to anti-vaxx stuff or that whole other space of these kinds of dysfunctions.
You always need some kind of hook that is correct.
The claims:
* The existing exploits don't work. * Reasoning chains producing an exploit have cheated the test.
If the claims are wrong then rebutting them is easy:
* Ask an LLM to produce a real exploit. * Test it.
the user "zkldi" is who submitted it to hn also. seems like a real person to me.
[0] https://eliastaylor.com/software-tinderbox/
Or rather, maybe we do, but we might differ when it comes to topics where claims as big as these are made.
https://www.twitch.tv/zkldi/about
https://github.com/zkldi?page=2&tab=repositories
https://wiki.archlinux.org/title/User_talk:Zkldi
https://tachi.ac/
edit: unless there is AI that fakes being human since 2021 and has its own Twitch channel in order to post a blog post to Hacker News.
> I'm a 21 year old programmer from the UK. In my free time, I play ITG and create rhythm game adjacent stuff.
Is this a good source for "actually, the people are wrong and you shouldn't worry. This is overblown"?
Should that be guiding people's decisions on how to treat this very real and confirmed by the devs and third parties vulnerability?
But again this is very very simple to refute by actually linking a working PoC.
The statement was that it's not a real (primarily as in credible, relevant. Actually real also an aspect but not the primary one) person.
There could technically be a human behind it, just like Jia Tan could've been a human. But for judging the input, that is irrelevant and misleading.
The biggest problem reality is facing is that people's consensus operates on "having every voice heard", which is good in a small village, but terrible in a globalized internet.
And thus, if we want to keep "every voice needs to be heard", we need to reclassify "voice" and "real" not just on "has cells".
That's the mental shorthand I operate on, which I should have resolved down fully to make it work with "normal" people's brains. Regrettably.
Should be easy enough to verify the central claim that you need to be able to read the password file through some other means to use this exploit.
A human being, presumably. But he could be a dog or a diffusion model and I wouldn't care, because arguments stand on their own. There is no special caste of people who alone have permission to propose ideas.
You advocate critical thinking. Excellent. Can you critically evaluate "Elias Taylor"'s argument?
Besides, he's got a point. The initial PoC that kept popping up on Mastodon (the ones he linked in the post as well) simply didn't work. One of them even posted an updated exploit later that still didn't work, but supposedly meant the vulnerability went from CVSS 10 to CVSS 4.
So that's a silver lining I guess.
Whoever gets pwned due to this might get naturally out-selected. The system works!!11 Thank you darwin.
The greatest trick that Devil performed was convincing people that he didn't exist, right?
I love this
Calif: "the available exploitation paths depend on the PHP version and SAPI but are always exploitable under default configurations" ... "This results in RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 5.4.0."[2]
PHP Foundation: "full remote code execution was demonstrated with default settings."[3]
Unless all of these organizations are lying, the exploit can work against a default PHP installation running a Hello World script.
[1] https://www.wiz.io/blog/php2shell-php-rce
[2] https://calif.io/php2shell/
[3] https://thephp.foundation/blog/2026/10/21/todays-php-securit...
With previous showstopper security bugs, once you knew the vulnerability existed the exploit was immediately obvious.
There is no news about hacked websites due to this vulnerability.
If anyone could ask Claude for an exploit, one would expect a lot of PHP sites to be hacked just for the fun of it, right? Like putting a message on some popular website or something.
> Despite the high volume of exploit attempts following the discovery of the Log4Shell vulnerability, reports of major breaches were relatively few. One of the first significant attacks targeted the Belgian Ministry of Defense. Reported on December 12th, just three days after the vulnerability became widely known, the Ministry did not disclose specific details but confirmed the Log4J vulnerability as the attack vector.
https://arxiv.org/html/2501.17760v1#S4
The standard way hackers go about today is data theft and extortion. I think we would have heard about it if was a big problem.
People should off cause keep their servers up to date no matter what. The total panic that was yesterday with people posting all kinds of random AI slop was pathetic.
1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.
2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.
3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.
4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.
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/
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.
There are entire states pushing for, and corporations built on exploiting 0 day vulnerabilities[2]. They will spend millions to hack an entire platform so they can somehow infiltrate 1 customer that they care about. Some high value target. There's a good chance that any innocent looking business has some high value (in the eyes of intelligence community) customers.
The attack vectors they use are sophisticated, gaining access to multiple systems, much like how OpenAI agents got through to HuggingFace servers[3].
So knowing what we know now, it's naive to think people are calling wolf, they are not. They just happen to know something most don't.
[1] https://aws.amazon.com/blogs/security/amazon-threat-intellig...
[2] https://citizenlab.ca/wp-content/uploads/2025/12/Report135-t...
[3] https://openai.com/index/hugging-face-incident-and-the-road-...
Many apps (eg chrome) frequently fix bugs that are actively exploited in the wild yet have no public weaponized chain (sometimes for months).
The fact that there is no fully public weaponized chain does not mean it does not exist or that this bug is not as scary. It only means that it is not as trivial to exploit as log4shell/shellshock/etc.
According to cloudflare [1], it is being exploited in the wild.
[1] https://x.com/eastdakota/status/2113079352682570051
*My phone autocorrected to that and I'm keeping it.
Where are the mass successful exploits? Why is this different to any other patch?
If you're looking for obvious site defacements, something loudly compromised... that's usually not the game here. What is more likely is persistent covert shell access, hiding underneath. Accessible only to those who know the way in, doesn't draw attention to itself so it can persist for a long time before being used... a bit like the 11 month old account you've referenced here, that gets used to comment on this thread.
Sites with shell access become useful as part of botnets, for DDoS attacks. Setting up VPNs to provide lateral movement across to other websites. Why blow your cover by announcing your presence? A lot more damage is done in stealth.
I'm not in cybersecurity, but if you hunt around you'll find enough info about sites getting caught up in this.
I’ve found that if I’m looking into security issues that if you ask an LLM about a “security” issue… it will find one regardless if you have one or not. Like some over eager security consultant desperate to justify their job / collect more billable hours.
This is especially true if you have a bunch of server logs and ect.
Honestly it really shouldn't matter if most attackers can't find the exploit; it only takes one bad actor to wreak havoc. And I have seen already several sec YouTubers post live exploit walkthroughs so....
This is the most compelling argument presented. If this PHP vulnerability were actually so bad, we'd be probably be seeing some kind of widespread impact by now. If every potential target requires a second coincidental, target-specific vulnerability I think we should probably call off the search party.
The alternative way to describe this situation is "defense in depth". We've located a very thick part of the ship hull that we could technically drill through if we had enough time and money to do so, but this would not scale up in any meaningful way. What you can do to a vessel in dry dock vs on the open seas are two wildly different universes. Vulnerabilities located under pristine lab conditions or within the context window of a clanker do not bring me much concern.
I suppose majority of the them now...
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.
0: credit to Xenosystems for this excellent phrase
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.
It was some good drama, and honestly I didn't even know LLM was involved so heavily in it. But damn annoying that people blindly believed LLMs and I blindly believed those people.
What about our routers? What about Home Assistant? What about IoT?
Vulnerabilities are going to surround us, many of which will never ever be patched.
We may well be fucked.
Get on time, pa, they are called LLM kiddie now
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).
https://news.ycombinator.com/item?id=50195017
Vibecoded on purpose without any of my influence, just to prove a point that a local Qwen3.8 model that's post trained on DeepSeek's reasoning traces makes this exploit and the necessary Heap Feng Shui totally feasible.
https://www.youtube.com/watch?v=Ci_zad39Uhw
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)
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.
Every language has a preferred way to deal with things. In C, it's raw pointers, which are very error prone. Other languages have something better. For example, if you were to implement custom allocator in C#, would you return raw pointer? Or maybe base array + offset pair? Of course not, you'd choose a Span or Memory, and those are not prone to buffer overruns.
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.
Edit to address the specific example: OpenSSL would never have been written in .NET in the first place, being very performance/hardware sensitive (there's a bunch of platform assembly in TLS implementations) and by its nature designed to be needed by all/almost-all software on a system. The argument everyone would reach for here would be Rust. But in Rust, the same logic that led to the custom allocator would probably produce an unsafe-based equivalent (which is true for almost all heavily optimized rust, sort of a dirty secret).
(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.)
[1] My favorite example in this kind of argument just because it's so obviously understood and non-technical. All the pedantry in the world wouldn't have fixed that, it was the combination of a bunch of correctly implemented and useful features.
One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.
I largely agree with the author and it is a common annoyance in cyber security discussions where people make strong claims but have nothing to back it up with.
https://www.ft.com/content/245778d9-597b-492d-b5b6-a2967c77e...
[1] https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-...
Doesn't look like confusion to me.
I'm no expert on UAF exploits. I guess one thing I'm wondering is whether the pointer to "freed" memory in this case is still pointing to memory reserved by the system for a PHP process, or if it's some address that's truly free and could be picked up by another process.
This isn’t a thing; virtual memory (https://en.wikipedia.org/wiki/Virtual_memory) is very old, and Linux has never not used it. It takes a separate vulnerability (a “local privilege escalation”) to do what you’re getting at. (However, those are plentiful, and arbitrary malicious code with PHP process privileges is often already catastrophic for a web service.)
That said,
> OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself
No, nowhere does the article imply that at all.
And yeah, obviously it's still dangerous to have arbitrary code running with PHP's privileges.
Just one thing: With mod_php, those httpd processes are spun up on demand. After that the memory is released to the system, right? There's no master Apache webserver process holding all those addresses.
Just for clarity, I took the OP's point to be that the only way this could be used to escalate privileges would be if there were existing scripts on the server with credentials that PHP itself could be made to exec() ...but... if you know a process is going to be spun down and no longer holds a pointer to the memory you're writing to, couldn't you theoretically write something that might be picked up by the next process? Or is that always formatted by the next process' vm?
Appreciate your patience, I'm not a low level coder.
> Or is that always formatted by the next process' vm?
So yes, that’s sort of how it is.
https://renenyffenegger.ch/notes/Linux/memory/read-write-ano...
You need the same access as you would for connecting gdb, so generally need to be running in the same uid, or be root.