@baldur I read the link and it sounded reasonable, but could someone with PHP chops (that's not me) state if the RCE on latest Drupal etc claimed here is accurate?

> We combined these vulnerabilities into a single exploit script, php2shell, and demonstrated that it could execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest), using their latest container images at the time of testing.

> These platforms illustrate the impact, but the vulnerabilities are in PHP itself. Exploitation does not depend on a flaw in the application’s code: even a simple “Hello World” application running on an affected PHP version can be vulnerable."

https://www.wiz.io/blog/php2shell-php-rce

“It’s a poor worksman who blames his tools” has always been complete nonsense. No-one complains about imperfect tools faster and louder than a master. A master will yank a cheap or damaged tool out of your hand and yell at you for not blaming it yet

Cheap, lousy tools come from middle managers who don’t know how to do your job. Blame the hell out of poor tools and those who demand you use them

@zzt Funny you should ask that question: a couple of decades ago I worked out that a mono 300dpi laser printer can print about 1.2Mb of data as a bitmap on a sheet of A4. Call it 0.8Mb with error correction … but then quadruple that if you go to 600dpi. So an HD 3.5" floppy disk per sheet of paper, or about 1Gb of data per ream of paper. Not human-eyeball-readable though. And you'd need to verify each printed page via a scanner immediately lest toner streaking or cartridge fade bork your backup.

RE: https://norfolk.social/@rachel/117484055631103353

This sums up rather a lot of what's wrong with the whole industry. Cyber security expert who had never heard of the software that underlies 70% of all websites...

Ah the over confidence of white men in this industry...

But my observation was primarily that many of the claims I've seen surface over the past day or so seem quite dubious in hindsight and seems to have led to a herd effect of sorts.

This would seem to be a good example of how software is full of trade-offs where every choice is bad (starting with "using PHP", he jokes)

The bug seems to be hard to exploit but not fixing would give well resourced actors an incentive to find ways to use it

But the fix is also huge and results in a patch that's impossible to review, and so might well introduce a bunch of exploitable bugs on its own.

Clearly patching is the lesser of two evils, but clearly neither option is outright "good"

People continue to have a tendency to imagine that I wrote something I didn't and get angry about claims I didn't make. 🤷‍♂️

internet taken offline by huge pulse of smugness from static site operators

case in point: https://rumple.github.io/blog/2026/10/20/asking-llm-for-confidence.html

something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.

this feels like a major feature upgrade.

which is weird in the circumstances.

the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")

instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?

that doesn't smell right at all.

and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?

call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.

If this had been a woman, she would not have concluded this fiasco with an inspiring LinkedIn post about "not always getting it right".

I hope that this causes Chainguard to be kept away from any security related embargoes until trust has been properly restored.

idk it sucks to see analysis like "yeah of course backporting 12kloc patches is hard which is why it's useful to think of other solutions that don't involve 12kloc patches" written off as moral purity testing

"I am concerned this huge patch is a symptom of a lack of design coherence and will just hide further bugs" is not morality policing

"a security patch that is impractical to review is a category error" is not "feeling icky"

If the original is as hard to exploit as some of the experts have been saying, it's entirely possible that the fix for yesterday's PHP bug might cause more active exploits than the original bug, because the fix is on the order of, what, 12k lines of code? A patch of that size, touching so many parts of the codebase is quite likely to introduce a ton of bugs on its own

you can't "just have a really good test suite" your way out of this. security issues are caused by violation of properties you never even thought of, by non-obvious and often indirect interactions of things nobody realised were connected. your tests will not catch this

multiple things can be true at the same time. it is true that un- or underpaid people having to deal with complex emergencies under tremendous pressure utterly sucks. it is also sucks that that pressure is a strong incentive to deploy under-reviewed code

RE: https://toot.cafe/@baldur/117484059424957991

The reason why the way many have been talking—describing “AI”-written exploits popping up require heroic defence—smells like bullshit is that, so far, all of the exploits seem to require pre-existing second vulnerabilities so bad that any site with them would have been hacked months ago already.

That can change any time, which is why you should patch PHP ASAP, but many of the responses smack of madness of crowds

But it really also does look like anybody describing waves of exploits targeting their site yesterday or heroic work by their "agents" to safeguard their servers may be operating on the reality-deficient side of the bullshit scale.

It looks like the PHP Armageddon bug may have been a bit overstated in that exploits require severe-level pre-existing vulnerabilities

If I'm to be completely honest, though, "has pre-existing severe code-level vulnerability" describes a lot of the PHP sites I've seen in the wild.

RE: https://mastodon.social/@Edent/117483785620327786

“There isn't an easy exploit for this PHP vulnerability · Elias Taylor”

https://eliastaylor.com/noexploit/

> One really amusing thing in common with most of these "PoC"s is that they lean on "LFI", or local-file-inclusion, to make the vulnerability. In non-php terms, their exploit chain requires the server to already have a severe code-level vulnerability.

“Sean Allen on X: "🚨 Going out of business sale 🚨”

https://x.com/seanallen_dev/status/2112167799132979389

> iOS dev course sales plummeted due to AI. It costs a lot of money to host my courses online and with sales at basically $0, I've cancelled that hosting.

More evidence of the complete destruction of the developer training industry. (Via my feed reader. And, ick. Are all the X mirrors really all gone?)