PHP 8.2.35 (github.com)

Edit: was looking Wiz post when citation was from OpenAI

I’d press go too - if something this big was known to some but not all…

We’ll all get through together

On the other hand, I don't mind AI companies doing this sort of thing, I'm sure a lot of our internet infrastructure could benefit from these sorts of fixes and changes.

This is a pretty constant theme in the infosec industry. The idea is that you want to do the "responsible" thing and let all the major, multi-billion-dollar companies patch first, so you form a secret club. But then, you share a very juicy, gossip-worthy thing with hundreds of people and ask them to sit on it for weeks. And guess what happens: they don't. Having worked for a big tech company, I've been involved on a couple of processes of this sort, and they all suffered leaks.

And rest assured, we'll learn nothing and try the same thing again next month or next year. Because what's the alternative? If you 0-day everyone, you get more hate mail, not less. It's all of sudden about you, not the vulnerable code. Microsoft or Cloudflare calls you irresponsible when asked for a PR statement, industry bloggers bully you, etc.

these security companies reported it 2 months ago. it took a month for the php security team to acknowledge it and another month for the php team to develop & release the patch.

if you're going to be upset at anyone it should not be the reporters.

>The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details.

publishing the fix = publishing the security details.

Sure, it’s PHP, but plenty of companies or organisations might have some PHP running somewhere; and once you’re in, lateral movement becomes a lot easier.

Whether keeping the update quiet and including it in the next normal release, where there are more trees obscuring the wood that is the security concern, and announcing the bug a short time later once anyone using distro updates or otherwise keeping on top of things have updated, would be safer overall than what has happened today is up for debate. I can think of arguments in both directions.

--------

[1] which does have a slight whiff of AI marketing about it - would a human-found issue, without the option of a big AI company to claim some credit, have been handled differently?

See PHP foundation blog post on their timeline

But they could have accelerated the patch release once the embargo was broken and rumors of a PoC started going around. There was no need to wait 12+h today until the release.

I don’t think this what happened at all, and even less so to specifically call out OpenAI.

The issue was discovered using their model, it was disclosed, and the PHP team took months to address it. Eventually it leaked.

This is a process / people failure that does not involve the people responsible for discovering it.

Amazingly, AWS Linux has not been patched yet.

The PHP team knew about it since September 21st.

Here was a PoC: https://jackalsyn.com/posts/php-up-2026.html

But it was withdrawn; now it says that it (CVE-2026-109618) is not an RCE and not even a CVE, apparently an addref call prevents the use-after-free. CVE-2026-109619 is still a memory safe bug, but they have no RCE for that one

*rolls 3"

"Your IPO gets delayed another month"

https://hub.docker.com/layers/library/php/8.5.12-fpm/images/...

The average phpBB or Wordpress, even if it's behind cloudflare, probably has a direct IPv4 that's not disabled.

We are damned if we don’t and (often times) damned if we do

Meaning this specific bug the parent comment is talking about is not new in just these patched versions from today.

So delaying your updates today would mean you’re exposed to an actively exploited RCE and still exposed to the other memory corruption bug (which may or may not be an easily exploitable RCE) for an entire 2 or 3 days.

And from the sounds of it people are very actively exploiting this so waiting 24+ hours will practically ensure you’re hit.

> Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

https://www.php.net/archive/2026.php#2026-10-21-5

    [email protected]:~$ php -v
    PHP 8.4.26 (cli) (built: Sep 23 2026 06:24:29) (NTS)
    Copyright (c) The PHP Group
    Built by Perforce Zend (www.zend.com)
    Zend Engine v4.4.26, Copyright (c) Zend Technologies
        with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository.

I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.

GitHub uses this metaphor, and, as another commenter already aptly described, it could be nothing more than a fancy name for namespaced branches, on the server side.

On the client side, "forks" are usually different repository clones with different remotes and a "coincidentally" shared history.

But you can also map forked repos to multiple remotes of the same repository for example, instead of folders.

Assuming that forks would live in separate clones/blobs on the server is not really based on anything, so I think the warning is a good middle ground between explaining what forks are and how they handle them, and giving actionable advice.

It's also better suited for PR:

"Fork me on GitHub"

vs

"Branch and push your own clone on GitHub, using our shared blob optimizations".

I think the warning is clear and there's nothing misleading about it, but others have already pointed this out and git can be tricky.

It's so good at providing the right level of abstraction to everyone though, it seems!

Similarly, GitHub invented the term "Pull Request" (aka PR, lol).

Not a git-owned term.

But "merge request" isn't a Git primitive either!

And, with Forks and Pull Requesrs, GitHub made a particular workflow in Git approachable to anyone!

I love GitLab, but people get confused by Merges, myself included, so the GH-enabled workflow of favoring ff-only merges, without merge commits, with quadi-linear history, became the norm and helped Git succceed!

But I also appreciate being able to do all kinds of different workflows.

So PRs were positive-sum PR at the time, I'd say. When they became popular, I was still taught Subversion and CVS at uni, alongside Git as "the new thing". Ar that time, many people considered the older systems simpler, and pondered SVN as the most reasonable middle ground between CVS and the decentralized concept of Git!

"Let's use this packaging some rando on the Internet built" is a strategy that is exactly as good as it seems, but that's the Docker ecosystem for you.

Packagers who actually understand the software put in good work to package that software in small and well maintained packages. Use them instead!

https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...

Edit: Linode just updated its mirror.

It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.

> Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.

Most of docker is like this. Images provided by volunteers, and not related to the project. Using docker images you don't maintain yourself, and at least don't upgrade yourself, is not the best recipe for security.

(It's pretty trivial to build your own)