Hacker News

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

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!

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.

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

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.

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

Doesn’t seem to work against docker php:8.5.11-apache

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.

TIL PHP has a security team.

I presume that leaving an "anyone can run any command on over 40% of the web servers in the world" hole in PHP for 14 years means the entire team has been relieved of their responsibilities.

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.

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

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.

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.

GH Dependabot.

Turn on automatic updates.

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

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

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

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

SomethingAwful too

[flagged]

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

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.

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.

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.

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.

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.

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

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 saw two on twitter, they were both pretty far away.

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.

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

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

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.