While I have been chasing around today, trying to resolve this on different servers, it turns out a three line nginx mitigation (blocking multipart uploads) I wrote in the wee small hours GMT has been quietly protecting a vulnerable machine I could not shut down (from attacks powered by every single mainstream agentic AI tool — Anthropic, OpenAI, Qwen cloud, Baidu, seemingly also AWS, Meta)
Including an hour before the PHP patch actually shipped.
So without the HN discussion I wouldn't have found enough people pointing at possible mitigations and I would have lost a server to this, and I thank everyone who pointed out that second mitigation in particular.
I absolutely loved being here today.
So many brilliant minds screaming and hating together, trying to survive the tide.
There aren’t many places like this left on the commercial internet, especially in this brave new AI-driven world.
I felt a great disturbance in the Force. But in a good way.
Together, we are strong. May the Force be with us all!
Is it so bad? Have you measured the number of attacks?
> So without the HN discussion I wouldn't have found enough people pointing at possible mitigations and I would have lost a server to this
I run a tiny server. I like this server a lot. I only patched an hour after the Debian package was ready and didn't think about it again. Do you mean to imply there's a real chance my little server has been compromised?
[Edit:] My server is quite public too. It hosts four SLDs and many subdomains and receives both human and bot traffic. Only one or two subdomains use PHP, but a reasonable attacker surely tries all of them.
It is not a torrent, no. Dozens up to hundreds, rather than hundreds to thousands.
But they would very likely have succeeded, right? It's a fairly turnkey vulnerability.
> I run a tiny server. I like this server a lot. I only patched an hour after the Debian package was ready and didn't think about it again. Do you mean to imply there's a real chance my little server has been compromised?
Can't say one way or another. Have a look at your log file for POST requests in quick succession for things like
/_next
/_next/server
/app
/actions
/api
/dashboard
All my "obviously PHP app" domains got visited. None of my bespoke app domains (which are not obviously PHP). Though over time, the bespoke domains do get a whole bunch of boring probes for WP vulnerabilities etc., like all websites get.
35.247.197.7 - - [21/Oct/2026:16:41:11 +0000] "POST /_next/server HTTP/2.0" 404 153 "-" "Mozilla/5.0 (compatible; YouBot/1.0; +https://you.com/bot)" "-" [REDACTED] 0.002 "0.001"
Surely it doesn't take a very sophisticated attacker to clean up after themselves at least a little bit?
If your attacker is someone known to you, some kind of persistent threat, then maybe they would? But most of this stuff is typically kind of worm-like; attack one box, use it to attack another, move on.
With this particular server I am in two minds about whether it is likely I have any persistent type hackers, but I must say what it looks like is automated attacks. AI script kiddies, almost. These same boxes attract all the typical PHP app probes (WP2shell etc.)
And FWIW what it actually mostly looked like was hits from some sort of cloud-based AI search API; they suddenly stopped at the same time as if someone else had pulled a plug. So maybe someone running an agentic search API decided not to be part of the probes.
I'd agree with that sentiment, most of those scripts are the laziest they can be.
But I can't help but wonder if there's survivor bias going on there.
There's a vast number of operators who won't even look at their site when its performance craters due to a scrum of crypto miners all competing for resources. Why waste time on sophisticated attacks trying to fly under the radar of competent admins who will detect you by your egress traffic anyway?
This is PHP world; it may be a share nothing architecture, but it's full of long-running VMs and very long-running apps.
You lost its privacy
Just saying "hey blocking multipart uploads can mitigate most of attacks early would save people so much trouble. Of course not every CVE will have workaround but many do and whole secrecy about releasing it is only to benefit of few big tech companies and nobody else
Unless your position that any statement whatsoever made in the second person that isn't a compliment is then an attack?
San Francisco is a magical place where "you are doing X wrong" without slathering on six paragraphs of fake kindness constitutes some kind of personal attack
You can make your substantive points without that, both in San Francisco and elsewhere.
He is, in fact, not mitigating the attack, and he is, in fact, by calling his non-workaround a mitigation, encouraging people to do ineffective things instead of patching. These facts remain true in the real world regardless of what you call a personal attack.
And yes, San Francisco has become top of the world for indirect fake kindness that transforms plain factual statements about the world into social offenses.
"The sun is bright. Don't look at it " -- RUDE!
"You might want to consider that the sun might be considered bright to some people and that you might be more comfortable looking at this other cool thing instead. But no pressure" -- gruff, barely tolerable
You have a long history of throwing sharp elbows around on this site. You did it just yesterday on an unrelated topic: https://news.ycombinator.com/item?id=50167498.
We've asked you many times to stop. If you would please review the rules at and fix this, we'd appreciate it.
https://news.ycombinator.com/item?id=45089286 (Sept 2025)
https://news.ycombinator.com/item?id=44729387 (July 2025)
https://news.ycombinator.com/item?id=24254142 (Aug 2020)
https://news.ycombinator.com/item?id=22029640 (Jan 2020)
https://news.ycombinator.com/item?id=21104133 (Sept 2019)
https://news.ycombinator.com/item?id=17976632 (Sept 2018)
https://news.ycombinator.com/item?id=17976625 (Sept 2018)
https://news.ycombinator.com/item?id=17791892 (Aug 2018)
https://news.ycombinator.com/item?id=17492560 (July 2018)
1) you're being rude, just stop it and get a grip
2) actually, this particular mitigation is very clearly stopping all the unusual patterns of POST request attempts I can see (it's not usually a busy server)
3) I know it is not the only mitigation that is necessary
4) … so it isn't the only mitigation I have applied
5) I am not working under a false sense of security, and I know it is temporary
6) I am not an idiot, and I am working on patching this machine, but this particular server has a unique and complicated configuration and needs a bespoke build
7) I have been prioritising much more serious risks for other people, all day, for no pay
8) again, to reiterate, you're rude.
Also I have survived on too much coffee and probably too many chocolate biscuits. So actually, sorry, on reflection :-) What a day.
I appreciate how your excessive-biscuit status has yet to be determined :)
I finished moving the remainder of my stuff off of PHP and WordPress last year and haven't missed it at all. Backwards compatibility was typically pretty bad.
It seemed like maintaining existing working PHP code was always a cycle of: upgrade to newer PHP, that version has breaking changes, fix that code or update to a new WordPress (plus all of the plugins that would inevitably need updating too).
But this isn't about PHP code, really — this is about C code (with less-than-ideal exception handler patterns). This problem is more Heartbleed than WP vulnerability.
I quite like modern PHP, I don't really think it's necessarily any less secure (exception handler weirdness notwithstanding), and more to the point, I don't think not using it is any kind of automatic improvement in web app security. It's not like server-side JavaScript is intrinsically better.
I am certainly doing some thinking today; I switched off a couple of web servers so I didn't have to think about them while I was working on other stuff, and actually I think they might not get switched back on. But it's not so much that they are running PHP as that they were kind of neglected and it's always worth reconsidering what you need to keep around.
I think I have reached a point where low value stuff is not worth subsidising just for fun.
(I have also reached the point where in future I won't be using distro packages for PHP)
And with the security fixes only landing on the relatively recent PHP versions, it means vulnerabilities force you into the PHP upgrade churn.
Yeah — the solution on a single machine is either containers or very careful use of different FPM environments, which has tripped me up more than once.
I think most of my inconsequential stuff is simply going to get moved to commercial hosting; my biggest problem right now is an entrenched application that has custom compilation of a PHP build before 8.1.
My shit on Wolfi, managed by ChainGuard, a “security company”, didn’t have a patch live hours later.
The funny thing is, people running Wordpress have dealt with 0 day bullshit so often that it’s basically a Tuesday for them, not even a big deal. So hilariously Wordpress folks have plenty of options here simply because it’s been a nasty attack vector for so long and these people are so used to dealing with horrific vulns like this that patching it is actually pretty trivial
But since one of the main ways this vulnerability can be triggered (by causing out of memory) involves multipart POSTs, I have found it useful to stop multipart POSTs ever reaching the vulnerable application, which you can do in an Nginx proxy.
It is only buying me time, but unfortunately time is what I need, since my application must keep running, but cannot be run on any supported release.
For example, when I buy something from a webshop, why does that webshop need my personal information? Why can't I give it a token, which it can then use to send my package, because only the postal system knows the address coupled to the token, etc.
And we should also ban user tracking for advertising purposes, obviously.
> You’ll never punish a North Korean hacker
You don't need to, you can fine the whole country.
How often do we hear "It's the cost of doing business"?
theoretically, yes
The simple version: Alibaba/Express and Amazon buys or kills most online competition etc, the remaining behemoths split the different markets and manage all the delivery. Only them know your personal info and every smaller shops need to go through them. Kinda the same way most of the world need to get with Apple/Google for things happening on mobile phone.
That situation could be completed in 5 years I wouldn't be surprised.
The crazy alternative: we all cooperate to have a common protocol to handle personal info, banks and shipment companies all agree to have standardized public APIs that are robust enough to last and be used more than six months. I don't think my grand children would see that happen.
You can register to reroute address A to address B, give out the address A to e-shops and then the post will deliver the packages to address B, which stays private. The catch is that address A needs to also be yours, it cannot be something arbitrary.
At least AFAIK.
This is the primary economic model of the internet, unfortunately, and thus the reason for all the data collection you described.
Just like how Apple Pay is less friction for online purchases than entering my credit card info is. Take that a step further where Apple can supply personal information JIT for shipping.
Yeah, the workflows need manual overrides for things like different billing vs shipping addresses, etc. But the happy path can be streamlined.
Social Security Numbers could have been replaced, fully or in part, as secure tokens decades ago.
I wouldn't have to worry about it being my time to lose my personal data in a major security breach. I already have lost personal info enough fighting for humane healthcare solutions in old age.
But if we argue intelligently for these solutions that have been tainted by bitcoin and "crypto" we are crypto-bros. We are tech-bros. Even if we grew up dreaming of cypherpunk technology protecting men and women's privacy and body rights, it doesn't matter anymore.
It's a slippery slope, these cruel anti-tech and anti-other jokes, and for me, my IQ on the political outcomes mattered more than my IQ on math problems.
One of the biggest metrics businesses track is repeat purchases. They don't want to give up that info because it tells them if their product is good enough to retain customers.
So the token must have some means of connecting purchases for a user across time (at least per merchant) or businesses will never adopt.
The only difference I could think of is that it also ties your identity with purchase habits. I could be missing something, but it is possible that OP lives in any of the other countries where the address+name+email combo isn't public information.
So everything developed in an ad-hoc manner. E-commerce web sites just asked for the information they need (and the information they didn't need), those who were comfortable using those websites used them, and the paranoid probably held out for much longer (and rejecting the idea of centralized auth loudly).
Most attempts by private companies to establish some de-facto identity/auth/login service mostly failed (well, the couple Big Tech companies got somewhat close, but none of them got close enough to be able to get other sites to use them exclusively)
Besides, even if there was some protocol to handle the payments and shipping without sending the info to the seller, you'd have to trust the payment processors and the postoffice to be secure. It's basically a choice between whether you want to put all your eggs in one big basket or spread them around somewhat.
It would completely destroy the data brokers and targeted ad industry but the world would be a better place as a result. Also not going to happen but I can dream.
We'll probably never convince end-users to "vote with their feet" and use Privacy-focused products. But we can absolutely, through legislation or just precedent, raise the Risk profile until it's better to leave the ad revenue on the table and run a private service.
I’m not so sure. The iPhone is the most popular in the USA despite the cost premium.
Turns out that money never was a good proxy for the public good, or even the ‘good’ of paying users. The goal has never been maximizing UX, the goal always was squeezing profits.
End-users not voting with their feet is misrepresenting the issue, it’s a symptom of end-users being actively lied to during campaigns (I think the euphemism for that is “lobby groups”).
Why? Because politicians care about being re-elected and their approval rates, and finance has proved to be an unnaturally large factor in that equation.
I've worked at plenty of companies that have no interest in tracking their customers but still need to be able to pin IDs to credit cards, etc. to have any hope of stopping mountains of fraud.
This is all new and rapidly evolving technology but giving apps / agents / others just the information they need to know while having a credibly neutral, private, and trustless database mediating is a true cypherpunk vision of how the internet should work and it's being built by people with the right ethos and principles to be as reliable, well engineered, and long lasting as the internet itself.
It is perfectly reasonable for the delivery service to be trusted. After all, they're going to take the physical package, so the business must trust them, and need to know where to deliver it, so the individual must trust them. An individual can request a token for the business and the delivery service can validate it, without the address ever being given to the business.
None of this requires a blockchain to make it slower and inexplicably public.
This is the most surprising part to me. It sounds like Calif saw the leaks, interpreted that as embargo being broken, and then raced to publish their [anime dancing] marketing video? I'd have expected much better.
This reads like some guy tripped and fell on top of his mouse and in so doing, accidentally turned on screen recording, performed the exploit a few times, got the anime girl asset and soundtrack, dropped all of them into Premiere, added the weird effects, rendered the video, and published the video to Twitter. "Ow. What did I fall on? Oh noooo, I broke the embargo!"
Heck of a mistake.
some people are just lacking coordination
The video was posted 44 seconds before that time: https://x.com/lcfr_hax/status/2112906567662399830
This can't possibly be interpreted as some major violation of the embargo, so what are people talking about?
> Chainguard unilaterally broke the embargo and published built images ...
Won't be the last time this happens. If there is no consequence of breaking the rules, people will keep doing that.
The point of the embargo was to prevent all rumors? But it did not hold.
Anyway, GPs point is that even if nobody leaked anything, and the only thing publicly known was the existence of the bugs, people would anyway have been able to find them independently. So what is the purpose of waiting 24h before releasing the patches?
I can say with high confidence that Nginx, Apache and IIS have a critical security vulnerability hidden somewhere in their codebase right now.
Please provide the prompt that uncovers it. Apparently knowing about the existence of bugs is enough nowadays right?
I’ll wait.
Chainguard had a vague inkling that there was something in PHP and literally typed “find bad vulnerabilities in PHP” to a frontier model and independently discovered these.
What happens when you type the same into any other language is an exercise for the reader.
2. Even if it hadn't, some occurrence of any given event has to be the first
3. Who claimed no other targets are vulnerable in the same way?
> Exercise for the reader. Well, if you are so confident, go do it. Share your results. I bet you won’t find a thing.
https://en.wikipedia.org/wiki/Flydubai_Flight_1073
Since you haven't seen any commenter here on HN go out and rent a 737 and personally demonstrate it to you, it should be totally impossible right?
Let me tell you this: - I never said VR & ED was impossible. I never said that a passenger flying a 747 was impossible either. - I said, a rumour of something so generic as “a bug exists somewhere”, does absolutely nothing for the ability to pull something off. Not before, and not now.
However, that is exactly what you wrote. Then, in your previous comment, you are changing what you said and now you’re fighting a straw man.
Goodbye dude, I’m not spending more cycles on this. Go find some bugs lol.
> you are changing what you said and now you’re fighting a straw man.
Not really. I think the issue is just reading comprehension on your part. Go back and read my original comment again and see if you understand it better this time. You made a ridiculous argument, which I responded to, how is that a strawman?
> Go find some bugs lol
I still don't understand what your deal is? Why do you think I'd be interested in that? It seems like a pretty basic concept that a person can know of a thing being possible without being personally interested in doing it?
> Me: AI models can solve open math problems
> You: Well then go do that and come back with a proof of [insert whatever conjecture]. I'll wait.
What you're saying is "I don't believe it's possible to do thing X unless you personally demonstrate it to me, despite the fact it's verifiably been done before by others".
I'm not claiming I personally will find any critical security vulnerabilities in "Nginx, Apache and IIS". But you seem to be claiming that nobody in the world ever will?
> “[…] even if nobody leaked anything, and the only thing publicly known was the existence of the bugs, people would anyway have been able to find them independently.”
I never said it’s impossible for LLMs to assist or drive VR and exploit development. It’s just utter nonsense that “knowing that a bug exists” does anything meaningful for finding it independently, unless that bug contains signal.
Which it only does if an embargo is broken, which was the case here.
Yes, saying there’s a big bug increases exposure, but also makes people prepared to patch. So it’s a trade-off.
No, when there’s no info provided regarding what the bug is, then it doesn’t make finding the bug more likely for any independent researcher.
Yes, increased exposure does increase the overall likelihood. Duh.
However, all this was not the case, the point here is: someone broke the embargo, and that messed the disclosure up, and that caused this mess.
Go find another straw man to practice mental gymnastics on. I’m not your guy.
See, I think the issue is that you misread my original comment, because this is an entirely wrong interpretation of it. Obviously I'm not saying that for any one given researcher who's already chosen to focus on PHP, that changes anything.
I suppose all your whining about strawmen and mental gymnastics is just you being unwilling to accept that (a) you misread my comment and (b) your reasoning in your reply was entirely illogical.
You know you can just stop replying if you want right? No need to tell me about it.
Chainguard was definitely not in the right here.
Finding an exploit and publishing is is not against the law. In some cases, publishing immediately is the responsible thing to do. For example, when it's actively being exploited in the wild, and waiting just puts people at risk that don't have any recourse to protect themselves, since they don't know they're at risk. There can be nuance to that as well, but in general, as soon as it's being exploited, anything that makes it harder for end users to a) know there is an exploit, or b) tell if they're susceptible to it (e.g. through a POC) is just taking away people's ability to take the action they deem appropriate.
PHP 8.2.35 - https://news.ycombinator.com/item?id=50180873 - Oct 2026 (439 comments)
PHP2Shell: AI uncovers critical RCE in PHP - https://news.ycombinator.com/item?id=50180836 - Oct 2026 (146 comments)
PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619) - https://news.ycombinator.com/item?id=50176077 - Oct 2026 (61 comments)
Security advisory: Critical remote code execution vulnerabilities, update now - https://news.ycombinator.com/item?id=50172041 - Oct 2026 (631 comments)
Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming - https://news.ycombinator.com/item?id=50167754 - Oct 2026 (60 comments)
If a video is released showcasing the exploit and following mitigation recommendation, PHP should clarify what it is and if the mitigations are recommended or not. From the pre-announcement: > We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
If no info is released by them, no other party should have released anything. If info is released or leaked from partners or involved parties, you should notify and explain what's going on.
But no, complete silence from PHP news or any PHP community member.
I get that it was a complicated situation, and I think PHP is the "less wrong" party involved, but I think this constructive and external criticism could help in the future. It has been an interesting day (GMT+2 here) and a rollercoaster of monitoring and mitigating without any reliable source.
Not entirely correct as they clearly announced that they were going to release a fix at a specific date and time; the mitigation doing the rounds was not adequate and if the PHP people republished it, it would lull people into a false sense of security. Overcommunication is also bad, especially if the official platform or the individual members are being watched by tens of thousands of people hungry for news or updates.
They knew (since august, arguably since 2024), they had a fix ready, everything was in place. Except for the untimely / accidental early leaks.
But yes, the preannounce was the right move and the leaks were unfortunate, complicating things. But if cloudflare, bunny and other actors start mitigating in their WAF, I think something has gone wrong and, either you act by releasing earlier or calm the waters saying "the exploits are wrong" as per stated in their post, they thought it was the case.
Everyone in such a ragtag team would have an overlapping day job where the same crisis management needs to happen.
I have a lot of sympathy for php team - it would be a lot of work to respond to every conspiracy theory on twitter, while trying to get everything ready, in the middle of the night no less.
A lot of speculated info was right: the mitigations were mostly right, the video showing exploitation was real and the release of a fixed image was real.
I think if you do a pre-announce, and you say that you could release it earlier or release new information and you don't, and there are reasons to inform your users, then even if it's the middle of the night for you, you should.
As they stated, they are a small team and they have changed their structure, and they are learning and improving. I think if something like this happens, info is vital for us, the administrators of PHP servers
I would disagree. The mitigation blocked such a small portion of the exploit, i dont think its right to call it "mostly right".
> PHP security team, operating on consensus, struggled to choose
What an unfortunate waste of a security audit. (and consensus is an obvious flaw in decision making)
> PHP runs a large share of the web... Yet security work on PHP itself still depends on a small group ...
Another unfortunate big structural issue that's unlikely to change.
Are there structurally much safer ecosystems out there?
When a corporation sponsors the language, such as Java, Go, .Net, there's an inherent economic component which acts as a forcing function.
PHP being a foundation sounds nice. But consensus wasn't strong enough to affect the key outcomes.
making php is the core of (checks notes) php foundation
or is the management full of completely not technical people who use it to boost their CVs?
Several attributes make a safer ecosystem. An important one is diversity - technical diversity.
For an interpreted language, the runtime is important. Python has several runtimes, as does Ruby. Javascript also has several, from the few browsers, to node, deno and bun. PHP has for all practical purposes, only one. So if there's a security incident in PHP, it affects almost all users. But when e.g. JRuby has a vulnerability, it will affect only a fraction of the installed ruby applications.
For compiled languages, the tooling, libraries and runtimes is where diversity is important. With e.g. rust, the vast majority of CVEs come from libraries (crates). But since there often are several crates for a single concept, diversity helps mitigate here too.
I know you added a caveat and all, but no, PHP has a number of alternative runtimes just like the other languages you mentioned: https://github.com/gakowalski/alternative-interpreters#alter...
But again with all the ones you mentioned, they have a "core" runtime that the vast majority of production apps use, so if NodeJS has a vulnerability it would be just as big.
The interesting one will be whether "boring" ports - like recently Typescript's TSC from Typescript to Go and now to Rust - will be safer for being the same code and logic, converted to another "safer" language (by transpilers or LLMs).
(Of course there's Log4shell, but that could've happened to a Rust-based stack too, and might be more likely to, considering the proliferation of deeply-nested dependency trees full of tiny libraries in that ecosystem.)
Also, blameless post-mortems exist for a reason.
They've known about this RCE for two years.
Paul Dianno is here if you need them.
This is incredibly damming of Chainguard. I struggle to see justification for this, even with the chaos approaching the coordinated release.
In their place I would worry that this was the last time anyone shared an embargoed build with them.
Very irresponsible behaviour in my opinion; and if it's a decision made unilaterally by their CEO, probably a breach of their SOC 2 certification. What's next? "$X isn't patching this CVE fast enough, here's a binary blob of our fix, don't worry, we're making this free!"
What was Wiz/OpenAI supposed to do? PHP was already aware of the issue.
They released some binaries, built for their own docker image based on their own Linux distro. Other people couldn't use Chainguard's "fix" to patch their own systems. The only people who seem to have benefited from the stunt are the hackers who used AI to reverse-engineer the binaries and write exploits.
That was a giant fuck-you to the rest of the PHP ecosystem, nothing more.
[citation needed]
By which i mean, this seems untrue. If you mean the anime video, that is not a leak of a PoC.
That can be for marketing purposes or by mistake. Not sure how to deal with that.
Dont trust us with information lol.
https://www.chainguard.dev/athena
https://www.chainguard.dev/unchained/this-shit-is-hard-build...
Song is Petite Meller - High Forever (Marlon Hoffstadt Remix). Which is annoyingly catchy
thanks.
This industry is full of immature children who cannot keep their mouths shut for 24 hours. They have no clue what massive coordination this requires.
They're apparently not trustworthy, and behave as children.
>As a result of the leak and pre-announcement around 20:00 UTC, Calif, one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities.
You can see the same demo video on their site: https://calif.io/php2shell/#php-5-4-0-rce
Calif more than Chainguard, but still Chainguard too.
Calif was obviously twitching to claim credit for their findings, and what I find troubling is this eagerness was more important to them than giving users a chance to update their systems.
Even if they ended up waiting only a day post release I would still say it seems a bit too soon. Maybe a week after. Not everyone’s system have aggressive patching schedules and PHP is soo heavily used.
All parties have that duty, but it's better if they do that at the same time.
... That's why you have an embargo.
It's maybe not professional to release an omg panic video, but not even remotely the same thing as what chainguard did.
I dont know why the timing of the bug is surprising to you.
They took it down but someone (Kirill Firsov: https://x.com/k_firsov/status/2112641845926989944) added the anime stuff and reposted it. Totally irresponsible.
Edit: okay he didn't add the anime, but he reposted it.
I want to go back to talks by bored defcon guys or gals calmly stating how they obtained private keys of a globally trusted CA with just a bit of math. Which, mind you, ate the other part of the teams time.
Now I know how much I hustled today likely due to that atrocity of a video. I think I will take a vacation day and sit in a forest near a river on friday.
Embargos make sense if no one is exploiting it yet, but if its out in the wild, the best path forward is releaseing as soon as possible.
"Cloudflare successfully deployed multiple mitigations for all its customers while the vulnerability was leaked before the official release date and we observed attack traffic targeting our customers."
If that's not an in-the-wild exploit, it literally couldn't have been further away than one or two more iterations.
From Cloudflare’s perspective, there is no downside to saying what they observed, and deploying defenses.
We may never know if this was actually being successfully exploited prior to patch availability.
If you own a website and see what kind of requests are denied by your Edge/Cloud provider, you can easily gather details and deduce which tools and specific features are broken.
With deontology, you prepare the rules and wait for the embargo to be lifted and don't overdo it on fear marketing. Of course if things are getting sideway and people starts leaking details, that's another story.
Was there even an incident co-ordinator here? Was any of the parties talking to each other?
so, if they saw evidence of exploits in the wild, it is not unusual at all to release the fix.
There is a MASSIVE difference between a small number of people exploiting in the wild, and a few hours after a release a bazillion script kiddies doing so. The move to release and break an embargo was childish, absurd, self-serving, and lacking in all common sense. Not to mention, breaking trust.
I agree with those in this thread who say, never going to do business with them. Ever.
I highly doubt their paying customers feel the same way
I would let Chainguard deal with the patches post official release like all other unreliable parties.
As a customer, I'd immediately assume no one in the security community would trust them again, and seek someone else to give my money to. Why pay a) an untrustworthy company who b) now is not trusted by anyone and c) won't ever be able to early release again anyhow? And if anything, are left out of important conversations.
Way to burn bridges. You only get to be an asshat once.
I have seen no evidence to back up this claim. Quite the contrary actually.
TIL observing an exploit in the wild, after the details leaked during the embargo and pushing a fix for your customer is "being an asshat".
My advice to their customers is to leave, Chainguard will be the last to know about exploits in future.
Because if there are already publicly available exploits seen, it makes no more sense to keep holding patches back just so that OpenAI etc. can get a nice press release
1. There was a leak of the pre-announcement
2. Calif sees leak, goes and releases dancing anime girl video before pulling it, goes viral
3. Chainguard sees dancing anime video, doesn't recognize Calif, and thinks the exploit is in the wild
[Edit 3a]: Or alternatively, Calif's leaked video causes the PoC to be found by others by providing enough of a lead
4. Chainguard releases updated binaries thinking it doesn't matter, causing the real exploit to then be found early
5. Which then causes PHP Foundation to basically have a meltdown
Personally I blame Calif for the unprofessional video which absolutely completely looks like some script kiddie and for being too detailed [edit 2: assuming Calif produced it and the anime wasn't a prank edit]. In this case it wasn't just unprofessional fun but may have literally messed up the responsible disclosure.
I'm not sure about this part. I saw https://jackalsyn.com/posts/php-up-2026.html going around a bit over 12 hours ago, before the chainguard images went out, and plenty of other chatter of exploitation happening in the wild.
Still not great though.
But it's also possible, that some attackers got non-public inside information.
If the embargo is already broken in a meaningful way, it suddenly becomes much less clear if it is still in place after all. Emphasis on >less clear<.
Well that's your problem right there! There are trillion dollar companies profiting off the back of open source projects without supporting the projects adequately. Why should they be scraping for funding for basic table stakes like audits?
For my rust applications, I use "cargo audit" which checks all dependencies against the CVEs. For my typescript and javascript applications, deno audit and/or yarn npm audit.
For the rest of the stack `debsecan` does exactly what you want on Ubuntu: report CVEs for installed software.
I'm not overly keen on the tooling: as far as I can tell the whole industry is prone to flagging false positives as "vulnerabilities" rather than "potential vulnerabilities" and it's a bit too easy to turn those reports into a tick-box "you must update now because the tool says so". But they also do flag true vulnerabilities. And they pay for teams of security researchers to find and fix issues, not least because that's good marketing.
Some have free licenses, many don't.
Sometimes build time is too slow (e.g., a repo that doesn't receive updates every day or so).
Maybe it would be worth it to have an agent that knows your stack, reads the top threads on hn all day long and messages you when it thinks there is something serious going on that could impact you.
PHP2SHELL, in particular, made me expand my weekly security review to include my external network resources.
The natural conclusion for this seems to be realtime monitoring CVE and pre-CVE vulnerability indications in exposed stacks.
I hope that someone has some sort of a reasonable approach here / I would love to help work on something open source if not
Examples of the type of alternate questions to ask in 2026 may include:
- Does my software/system have a robust architecture where a failure of one component (e.g. RCE in a PHP process) has a minor impact, rather than a catastrophic impact? For example, a minor impact might be just the opportunity for an attacker to chain a PHP RCE with kernel LPE for some common syscall, rather than mass loss of every user's data to the attacker. I raised some PHP web application specific ideas in another thread at [1] but the answer to this question is product-agnostic and should consider microservices architecture vs. monolithic web application with access to everything, and use case/requirements development that considers matters such as users wanting to isolate their own access. For example, allowing bank users read only login for bank accounts vs. separate login for making transfers. Or implementing business process changes such as delayed commit for sensitive user actions--e.g. force delay a bank transfer by 24h and notify the user via various means giving them a chance to undo the transfer before they no longer can.
- How can I keep up-to-date with the latest software/system security architecture trends? What is the equivalent of [2] for learning about architecture patterns to potentially use for a simple eCommerce site, HR/finance web application, etc in 2026? For components of a web application such as interpreter, database server, etc--what options exist for each and how good is the project's choice of software languages, dependencies, etc to offer the strongest security protections in 2026? When was the last time I checked if someone had written an interpreter for PHP, Python, etc in Rust, SPARK, or whatever, or written an interpreter with much more comprehensive unit testing included?
- How quickly can my users or I detect security incidents / deviations of system behaviour from typical state? For example, [3] was discussed on HN today as once such detection mechanism where canary tokens are deliberately littered throughout a system or dataset. The security incident may have already happened, but early detection forces an attacker to burn their vulnerability chain quickly on their most highly prized target and not be able to use it against a mass of targets over a long duration of time.
[1] https://news.ycombinator.com/item?id=50184239
But, certainly do your own threat assessment and develop and implement whatever plan works for you.
You have your source code public, so you can't commit/push because then you've leaked info.
Your build pipeline is also likely public, so you can't just build from another source code... source.
You can create a private repo, but now you also need to build a private build system.
You don't get the same generous build resources for private repos, so you either:
a) simplify the build to just the essentials
b) pay
Unless you have significant funding, you'll probably go for a).
Now you have to maintain two systems, also with some differences between them.
Plus you need a way to get the build artifacts from the private system to the public one, typically at a fixed point in time.
Any failure/delay (e.g. less powerful build on private repo, errors because you exercise it rarely) causes people to get upset that you didn't respect the announced time.
Maybe you're also using things like image attestation, another can of worms.
But they had _two months_ to figure out how to overcome them. For them to not have figured out a solution and have pre-built images ready to push as soon as the embargo lifted is ridiculous.
Now of course, there are ways around that if required, but they are, by design, manual, cumbersome and slow. I could not create a release build locally in a few minutes. A few hours maybe if the whole organisation dedicated itself to it.
I'd worry more about the fact that essentially publishing binary-first means that it ever gets compromised that makes it easier for attacker to smuggle exploit using "this is security update" pretext.
But let's go with that scenario, now you have all sorts of problems, from practical to security, like:
- accidentally/maliciously building the wrong thing? there's a patch, people agreed to it, but the wrong commit is built
- building for multiple architectures/versions?
- signing keys on someone's laptop?
- worse, image push/write keys on someone's laptop?
And so on.
The problems you bring up here are eminently solvable too. Yes there are many solutions for building for multiple architectures and versions. Cross builds, containers, VMs, or just having more than one computer locally. You can address building the wrong thing with reproducible builds, but for a one off patch like this it's not the most likely problem and relying on a trusted maintainer temporarily during an emergency is better than waiting for a glacially slow cloud build while exploits spread. Pushing builds to the cloud is inherently a cloud step, so it's fine to leave keys for that in the cloud, but there should be a process for publishing local builds and it should be essentially instant when the build is already done.
You should always have a local build process that replicates CI. There is no excuse.
PHP is written in C, I'd be surprised if similar problems didn't lurk in other places.
Maybe they will construct the private pipeline after this crisis. Millions of websites are probably now waiting for all the downstream Docker images to be built and pushed.
It would be great, but it's also something to manage. Just keeping it working with all the changes that happen across all projects would be something.
But the top 1 percent by usage/downloads, I can imagine, and PHP probably qualifies into that top slice.
For all the long-tail users, PHP is a distro package. That route needed the most work instead, and it got it.
I'm quite certain that your exact sentiment is why the images weren't updated immediately: I'm afraid PHP foundation doesn't see docker images as a particularly important distribution system.
I wouldn't be that certain.
I think it's likely that the vast majority of PHP Docker image downloads are for local development, for one thing.
But nevertheless, it would not come close to the number of websites running PHP from the Ubuntu Server packages. It is absolutely right that the effort was focussed on the distribution route. Because PHP is not "expert" hosting territory; it is still more often whole cloud VMs running the distro packages.
Being given advance notice of an upcoming security fix is an immense privilege, organisations should turn around quickly when given such information, they shouldn’t be given more than a couple of days to update IMHO, it’s not like the rest of the world can wait.
(It is often much cheaper for an enterprise to just get a long term support contract than to properly upgrade to a modern PHP stack.)
I've experienced similar to this. I know I shouldn't be, but I still get amazed every time I hear that some small company is still using an old DOS machine running core software based on dBase that nobody has any clue on how works and the developer has since moved on to a higher plane. One person told me that they sweat every time the power goes out longer than the attached UPS can run holding their breath that the machine powers back up.
5.6 is unsupported. There should be not getting special treatment just because they have massive tech debt
We need _real_ official Docker images of PHP.
Now I don't know what happened here. Maybe PHP foundation reached out to docker but got no help, maybe they simply forgot about docker as distributor of their software.
Okay, but how close did they get? Were they close enough that a determined actor could've (perhaps using an LLM) managed to get to a functioning exploit?
A nice article on the topic: https://blog.tux.org.il/php-security-october-2026.php
https://bsky.app/profile/luciferslexicon.bsky.social/post/3m...
PHP2Shell: AI uncovers critical RCE in PHP
https://news.ycombinator.com/item?id=50180836
Patch the Planet: global response coordination as agents uncover critical vulnerabilities
https://news.ycombinator.com/item?id=50181175
Upcoming critical PHP security release (CVE-2026-109618 / -109619)
AI has humbled most software devs, myself included, but at least with a low LOC count, a small number of dependencies and good separation of concerns, rectifying the issues is trivial. Can be done for the entire project in a couple of days.
For my own projects, each module has a clear attack surface and comfortably fits in the context window.
The scenario you want to avoid now is multiple modules interacting together in a complex way where each module is secure independently, but their shared responsibilities (improper separation of concerns) creates a gap which can be exploited. This was one of the key points from the recent Anthropic security article which stood out to me. The reason it's so dangerous is because it's difficult to get the AI to reliably analyze complex interactions between different modules as there can be many permutations. The boundaries are much simpler, more auditable and easier to patch if the module has clear responsibilities.
Any info on whether Mythos missed this?
PHP was great for learning the basics of web development 25 years ago. The world has moved on a lot since then.
Are you serious? This is PHP we are talking about, it has a notorious history of security holes and overall design mistakes.
This is the real story. You ship one of them (the breaking change) with —fuck-my-shit-up or something as a compile time option to switch to the other fix.
for legacy systems, how difficult would it be for an attacker assisted by "AI" to stage the conditions
on a scale of 1 (easiest) to 10 (hardest)
This was partly me. I take responsibility for posting it on HN. I am truly sorry for the disruption this has likely caused.
My contact had informed me there was no embargo, and told me her contact had told her the same. It transpired this morning that was a lie.
>On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.
On the plus side, at least I'm not Chainguard. Yikes.
>This disregarded weeks of work by many parties toward a coordinated disclosure.
Good. Coordinated disclosure meant that people couldn't protect themselves. That's not a good thing. It meant sites were forced to shut down instead of simply updating.
Maybe your calculus could hold if Chainguard's registry were the primary distribution mechanism for PHP in use worldwide (such that the benefit of an updated image would at least be widespread compared to the sitting ducks relying on the other repositories), but it isn't.
I'm just gonna assume patch was ready for a while and the wait time was just letting big players to update their own stuff before it is available for the public, and at that point it is just making the rest of the internet second class citizens not "worthy" enough to get the update quicker.
Trying to say that uncordinated disclosure is bad because people might get hacked yesterday instead of today just is not a convincing argument to me. I prefer the solution that results in the minimum amount of downtime for sites and sites provide value to society.
They didn’t get to unilaterally decide that the embargo was inconvenient and publish early.
It sounds cliche but yes, they should rewrite PHP in rust or other memory safe language.
And for non-malicious content, you can drop file above the upload max limit before user wastes time sending the file.
Because now a vulnerability in PHP affects practically 100% of the users. But with more diversity, it would affect only a part. And if one runtime proves insecure more often than another one, organizations have a choice to move to an interpreter that better fits their security needs.
I'm really not sure how you mitigate this issue, other than serving static HTML and reducing the attack surface to cut out dependencies like PHP.
I bet that takes a week at most.
There's no need for that many web languages, programming language is not a relevant factor anymore and even it was nobody can seriously argue that writing PHP "makes their heart sing" or some shit.
Last time I checked, PHP was pretty solid programming language. Nothing wrong with heart singing.