Today's PHP security release, and how we're strengthening security

You may never hear me say this again because I am a gruff cynic who is not sure that hanging out here is good for his psyche, but thank goodness for HN.

While I have been chasing around today, trying to resolve this on different servers, it turns out a three line nginx mitigation (blocking multipart uploads) I wrote in the wee small hours GMT has been quietly protecting a vulnerable machine I could not shut down (from attacks powered by every single mainstream agentic AI tool — Anthropic, OpenAI, Qwen cloud, Baidu, seemingly also AWS, Meta)

Including an hour before the PHP patch actually shipped.

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, and I thank everyone who pointed out that second mitigation in particular.

> Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos

Any info on whether Mythos missed this?

We should really move to a different security model on the internet.

For example, when I buy something from a webshop, why does that webshop need my personal information? Why can't I give it a token, which it can then use to send my package, because only the postal system knows the address coupled to the token, etc.

And we should also ban user tracking for advertising purposes, obviously.

> 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 [anime dancing] marketing video? I'd have expected much better.

Related:

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)

> Calif, one of the security firms that had reported the issues mistakenly published a video.

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

I think the PHP security team and the whole PHP team could have been more communicative and keep releasing information, adapting to the news, suspected exploits and mitigations.

If a video is released showcasing the exploit and following mitigation recommendation, PHP should clarify what it is and if the mitigations are recommended or not. From the pre-announcement: > We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.

If no info is released by them, no other party should have released anything. If info is released or leaked from partners or involved parties, you should notify and explain what's going on.

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

I get that it was a complicated situation, and I think PHP is the "less wrong" party involved, but I think this constructive and external criticism could help in the future. It has been an interesting day (GMT+2 here) and a rollercoaster of monitoring and mitigating without any reliable source.

> 2024, PHP underwent its first external security audit

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

Some code example for the exploits https://github.com/david-alvarez-rosa/php-rce

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

I was asking myself today; how to ensure that you don't miss a cve? I mean you'll sooner or later stumble across it if you're monitoring your communities but I thought that maybe there exists some kind of central solution, like a service were you could subscribe for your tech stack and get notified?

Very fitting LL definition:

https://bsky.app/profile/luciferslexicon.bsky.social/post/3m...

It's interesting that even 4chan was taken down for over 24hours now. Responsible people there.

> In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organize this audit ...

Well that's your problem right there! There are trillion dollar companies profiting off the back of open source projects without supporting the projects adequately. Why should they be scraping for funding for basic table stakes like audits?

Maybe a new one? https://fedi.katze.sh/@elise/117479383739450605

PHP is unsafe by default. Yep. Living up to its reputation.

Step 1: Ensure that docker images are available when the embargo is released. We're 2 hours in, and they still aren't available.

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

What is the penalty of breaking the embargo? Not shipping patches anymore beforehand?

Off topic, but TIL that .foundation is a TLD!

Related:

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

So instead of using a memory safe language or harden the C code they hope LLMs will find bugs in their code? Neither do they mention how their way to patch Exceptions into C makes It very difficult for Fuzzers to find those bugs? Good luck this statement should tell everyone to migrate away from that horrible language and runtime.

Sounds like a lot went wrong, the 2024 issue not being patched and then multiple parties leaking stuff before the scheduled release date.

Very disappointed by Hetzner Ubuntu mirrors not getting updated in time. Had to manually override to get the patch.

As long as PHP is written in C, it will be insecure.

It sounds cliche but yes, they should rewrite PHP in rust or other memory safe language.

"PHP" and "strengthening security" in the same headline is wild.

Having managed applications/servers using PHP in the past. I am so glad to be done with that dumpster fire of an ecosystem.

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

The guy who posted the CVE IDs early: https://news.ycombinator.com/item?id=50183326 (dead comment)

Hah. Wiz Calif-oAI.

serious question

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)

>On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked.

This was partly me. I take responsibility for posting it on HN. I am truly sorry for the disruption this has likely caused.

My contact had informed me there was no embargo, and told me her contact had told her the same. It transpired this morning that was a lie.

>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. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.

On the plus side, at least I'm not Chainguard. Yikes.

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]

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

The old joke:

The guide to PHP security:

Use something else.

The end.