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?

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!

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

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.

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.

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.

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.

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.

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.

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.

Some have free licenses, many don't.

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

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

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.

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

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

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.

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.

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

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.

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.