Hacker News

HN was my source of truth for mitigating this

YES!!!!

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!

> from attacks powered by every single mainstream agentic AI

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.

Agreed. It made my ancient old man face tear pores by smiling when I saw people organizing in the comments to throw sandbags against the wall while waiting to be rescued.

I'd like to express my dissatisfaction that the "big guys" are basically getting free security over getting earlier disclosure.

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

It is bizarre to me that servers are considered something to be “lost” in this day and age. They should as borderline ephemeral as us.

Is it just me, or is it the truly brave that decide to deploy and protect PHP instances? Especially if WordPress or Drupal are involve?

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).

[flagged]

mistakenly?

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.

This is EXACTLY how marketing/pr firms actually coordinate no matter what they SAY.

This is not the dancing anime girl video, is it?

This is your brain on anime waifus.

What kind of political / economic system would make user privacy a priority? I'm guessing not finance capital neoliberalism...

Perhaps Chainguard will be the last to receive the next bug report.

I’d say getting called out like this is a consequence.

That sounds oddly threatening, especially given that chainguard is in the right here. Embargoes are stupid in 2026 and make no sense. The rumor of this issue was enough for it to be independently discovered by several white hats and almost certainly many threat actors.

What are these "rules" you speak of? There's usually nothing binding in these agreements. It's just groups either trying to do the right thing by end users or trying not to look like assholes, get a better payout, or some combination thereof.

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.

> But no, complete silence from PHP news or any PHP community member.

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.

If mitigation is known, it should be posted as soon as it is found. Not "wait patiently for packages to update and hope to not get hacked".

No meaningful info was released. A lot of incorrect info was speculated on.

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.

> Are there structurally much safer ecosystems out there?

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 wonder if that isn't a side effect of how its structured...

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.

Rust and go don't have a C backbone like PHP does. So they are inherently safer to these kinds of vulnerabilities.

Yes. They're operated by big tech and called C# or Java.

They (is it the CEO?) commented on it earlier here: https://news.ycombinator.com/item?id=50176735

In their place I would worry that this was the last time anyone shared an embargoed build with them.

I dunno, the post is awfully critical of Chainguard for leaking a fixed binary 6 hours early, but it was the research firm "partner" that "mistakenly" posted the dancing anime POC video over 24 hours early that created the mass panic (not to mention spawning millions of agents crawling the php codebase and trying to brute force a POC and probably using more energy than a lot of countries in the process).

There were signs that others broke the embargo too. Public (this one video everyone is talking about), but maybe also non-public. There were some rumors going around which part of PHP was affected. That was enough for some people to figure out the vulnerability.

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<.

I kinda get Chainguard's position here. They were part of the embargo, saw exploits hitting in the wild already and decided to release rather than hold things back.

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.

This single-handedly assures that I will never, ever do business with Chainguard or any member of its C-suite executive team.

if their comment in true (linked in sibling comments), then it's really not damning. typically an embargo is ended when someone leaks early or it's being exploited in the wild.

so, if they saw evidence of exploits in the wild, it is not unusual at all to release the fix.

Brain rot is making us incompetent, dangerously impatient, or a mixture of both.

Not sure if this [1] comment is from them?

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] https://news.ycombinator.com/item?id=50176735

Big companies usually use some sort of vulnerability response management software which is connected to your CMDB, ideally containing SBOMs of everything you use, and subscribed to various providers of CVEs. Those tools then map the CVEs to your SBOMs and you'll get alerts, security incidents and so on.

Several tech stacks have this built in or available.

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 was thinking about this as well today. And while I'm sure there are many cybersec companies that send out alerts, I trust this forum the most.

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.

I don't think there's any robust method. I lurk HN, subscribe to security lists, run our code through scanning tools regularly. All options suck, all options have gaps, and all options mean you have to stay on the hamster wheel.

I’m curious about this too, although I would somewhat hesitate to rely on that, except as a contributing point of information.

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.

Lots of licensed solutions have this (typically SAST or DAST tooling like Snyk, etc...). Given your build manifest/SBOM they cross-reference CVEs for vulnerabilities during/after build time.

Some have free licenses, many don't.

I may be misunderstanding this but think the hard part about building a threat intel feed like this is just trusting that the underlying integration would surface something you care about... especially if you want to DIY it. You can scrape HN, GitHub advisories, NIST, whatever you want... but you may give yourself a false sense of security after seeing the "all clear" checkbox each morning

I hope that someone has some sort of a reasonable approach here / I would love to help work on something open source if not

GH Dependabot.

Any tool to scan dependencies takes various inputs like repos, container stores or already built SBOM and gives you warnings. It doesn't much matter if you have actual code and repos as long as you know how to point it at some. The fremium ones like snyk would love to send you an email report on growing CVE counts on your last run but only until hell freezes over..

Turn on automatic updates.

And nothing of value was lost.

SomethingAwful too

https://www.openwall.com/lists/oss-security/2026/10/21/23

I can empathize with them, this is actually quite difficult when you're an open source project.

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.

The PHP Foundation should manage it, the Docker ""Official" Images" approach clearly just doesn't work properly for responding to vulnerability patches.

FWIW, Docker images are a nice-to-have, but OCI containers are not how most PHP users get their PHP.

For all the long-tail users, PHP is a distro package. That route needed the most work instead, and it got it.

I find it incredibly naive that they’d hope it would not leak after weeks/months of embargo.

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.

today I learned that building your image from scratch is fundamental in cases like this. Luckily I came prepared thanks to Claude Code suggestion.

Aren't those run by docker? php foundation cannot be responsible

Yep, all our efforts are now focused on working around that. It's pretty neat!

Never using docker hub ever again

I know of a php exploited about 4 hours before their release time 1400 UTC, using the session bug in an exploit that was passed around. I'm really not very much in the loop about cyber security things.

I saw two on twitter, they were both pretty far away.

It might make other projects reconsider sharing advanced patches with Chainguard.

Same here, I suppose they didn't bother triggering a cron job early? They did patch managed servers and the like according to https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-....

It's one of the biggest runtimes on the internet; the C code will be some of the safest out there. Rewriting to a memory safe(r) language is a huge bet, even today. Nobody's stopping anyone from forking and creating alternative runtimes.

This is what I thought as well. How is this still so popular if it has such fundemental flaws? With the increasing power of LLM, more vulnerabilities will definitely surface sooner or later.

Please identify a non-toy language that has never had a vulnerability.

It's pretty popular in Go: https://frankenphp.dev/

As long as programmers trust 3rd-party-provided content-length input, it will be insecure. At this point, I'm not sure why we even use content-length anymore since you're going to need to size your buffers based on the actual content.

There should be more interpreters or runtimes. Regardless of the language they are written in. Indeed a rustPHP, maybe a JPHP, cPHP, etc etc. There is zend, but AFAIK that's still using the "official" PHP under the hood. And there is or was hiphop. Not sure how that is going, though.

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.

And, i don't understand why we are still using PHP. Agents can use Rust or go directly and we get benefit of performance...

I'm generally bullish on migrating C projects to Rust, but that will only reduce a particular class of vulnerabilities. There will still be other vulnerabilities which remain discoverable by LLMs, and for those, the problem of accelerated exploit creation will remain.

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.

Given the exploits are literally out there, 0.

You forgot to say "Asking for a friend"

What do you mean by stage these conditions?

0. Seriously.

No... Uncoordinated disclosure meant that attackers were suddenly armed with detailed information about an already-hyped severe vuln hours before the majority of downstream consumers had the means to patch their systems.

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.

You need to pay to get access to chainguard images.