> 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.
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 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!"
Your comment is funny. But obviously, "mistakenly" refers to the mistake of believing the embargo being broken, and then, very intentionally and not mistakenly, publishing a stupid video.
The PHP Foundation should manage it, the Docker ""Official" Images" approach clearly just doesn't work properly for responding to vulnerability patches.
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.
Making a cloud CI/build/release system whose behavior can't be reproduced locally requires some kind of brain damage. I can't believe people tolerate this.
The problems you describe in your first post are only problems when you can't reproduce your build process locally. With a local build you can always do it in private for free.
The problems you bring up here are eminently solvable too. Yes you can build for multiple architectures and versions with cross builds, containers, VMs, or just by 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 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.
Those are all challenges that surely need to be overcome!
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.
I'd say that for someone like PHP, in this era of AI-driven vulnerability/patch race, having a private CI/CD pipeline is a necessity.
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.
The images everyone is waiting for are built by Docker though? So now if you're Docker you have to have a private CI/CD pipeline with all library projects?
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.
I don't know about PHP, but at work our artifacts are signed, and you certainly cannot have the signing certificate on your laptop.
It's stored in some secure server, and only accessible from some allowlisted build nodes, for specific builds (release branch, ...).
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.
Setting up all that for single man project might be a hassle but for any sofware with actual dev team I wouldn't call it hard to do.
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.
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.
Keep in mind that some of the organizations are presumably patching ancient versions of PHP like 5.6. I am sure this is a process which takes considerable time, especially as upstream PHP has washed their hands of such old versions and the downstreams are effectively on their own.
(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.)
> (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.
PHP foundation also doesn't "Run" the apt or rpm packages, yet they certainly coordinated with debian, and other big distros to push the updates out timely.
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.
There's over 3 million downloads per month for the official PHP image. That may certainly not be "most PHP users". But still is a a lot of users.
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'm quite certain that your exact sentiment is why the images weren't updated immediately:
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.
> 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.
This is incredibly damming of Chainguard. I struggle to see justification for this, even with the chaos approaching the coordinated release.
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<.
Sure, but what if there is disagreement? Or some people are unreachable? There wasn't any time to schedule a meeting, hear all arguments, think about it, meet again for a vote, ...
I'm still not saying that it was right to break the embargo first, but it's not as simple as it might seem.
>Chainguard unilaterally broke the embargo and published built images containing the fix.
>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.
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.
If the sites are taking no action they will be vulnerable no matter when the patch is released. For the people who do take action before chainguard's release the safe option was to just turn off your server (and let any big competitor site stay up and take your traffic since they got the patch ahead of time). People taking this option will be offline until a fix is available for them to use. They are not in danger of being hacked.
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 will nitpick on that, if it was just released as a patch, there wouldn't be a hype to begin with, just point update to apply.
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.
> The PHP security team closely monitored and inspected appearing PoCs after the leak but did not identify any functional exploits at the time of release/public disclosure
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?
> The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice.
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.
Given how security moguls are handling that, we should go back to "just release it, consequences be damned". Coz that gets normal people better chance of actually fixing it
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.
> 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.
The point of the embargo was to prevent all rumors? But it did not hold.
Releasing a statement that a critical security bug exists with no more information, does the opposite of preventing rumors. I think one of the most surefire ways of generating rumors is to say "something big will happen tomorrow, please don't speculate about it".
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?
> 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".
Before you talk about the situation perhaps you should read up on the basics of it. Even the Wikipedia page will do. I'll wait.
> “[…] 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.
You don't see any difference between the maintainers of PHP telling the whole world, "try to find a bug in PHP in 24h", and one random guy on the internet telling another random guy on the internet to try to find a bug in Nginx, Apache or IIS? Surely making all interested security researchers with time on their hands focus on one thing with a specific deadline has no effect on the probability of finding a bug in that thing?
> then it doesn’t make finding the bug more likely for any independent researcher
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.
Pretty good. I'm not ashamed to say that I argue because it's fun, and because I'm right (unlike you). I'm also not so desperate to have the last word that I'll post a comment entirely without substance (like you did, and probably will do again in reply to this).
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.
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.
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.
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.
Normies think bigoted people and edgelords must be stupid. Most edgelords I know fall on either side of the bell curve, including on 4chan. If it's simply because the society shuns any uncomfortable truth as bigoted.
Garbage collection is also an option. Lots of backends on the JVM!
(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.)
My point is that large Rust projects end up using hundreds of transitive dependencies that indirectly touch user input, and certainly some of them have vulnerabilities (memory safety isn't the only vulnerability class - it's just low-hanging fruit for LLMs), and any could become malicious.
Log4Shell wasn't a supply chain attack, though; it was a genuine bug in a widely used library that had become a de facto standard, even in an ecosystem that tends towards relatively smaller and shallower dependency trees. So that comparison doesn't seem apt.
> 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.
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).
if there's a use case for re/decompiling, it's this one. with at least one strong alternative implementation, there would be less incentive on the attacking side to go all out on either PHP implementation.
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.
The "blameless" in "blameless post-mortem" isn't meant to absolve anyone of gross negligence. Even airline pilots can get fired after an NTSB investigation - the gold standard of blameless fact-finding - if it finds evidence of negligence.
264 comments
[ 2.1 ms ] story [ 115 ms ] threadThis 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 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
We need _real_ official Docker images of 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.
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 you can build for multiple architectures and versions with cross builds, containers, VMs, or just by 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 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.
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.
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.
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.
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
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.
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.
This is incredibly damming of Chainguard. I struggle to see justification for this, even with the chaos approaching the coordinated release.
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'm still not saying that it was right to break the embargo first, but it's not as simple as it might seem.
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)
https://news.ycombinator.com/item?id=50172041
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 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.
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'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.
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?
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.
> 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.
> 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".
Before you talk about the situation perhaps you should read up on the basics of it. Even the Wikipedia page will do. I'll wait.
> “[…] 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.
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.
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.
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.
The guide to PHP security:
Use something else.
The end.
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)
> 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?
(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.)
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).
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.
Also, blameless post-mortems exist for a reason.
Paul Dianno is here if you need them.