PHP 8.2.35

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.

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?

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.

See PHP foundation blog post on their timeline

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.

The PHP team knew about it since September 21st.

Amazingly, AWS Linux has not been patched yet.

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.

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

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

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

*rolls 3"

"Your IPO gets delayed another month"

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

> 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

When I’ve worked at small places, a security patch is bumping some versions and restating some servers.

I worked at a massive Rails shop for a decade and a big security bump meant mobilizing a team, coordinating updating dozens or hundreds of apps, all while maintaining platform stability and staying within SLAs. It’s a nightmare.

    wpe-user@MYENVIRONMENT.ssh.wpengine.net:~$ 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

11:12 UTC: “ERROR: AddressSanitizer: attempting double-free" from php 8.4.25”

11:44 UTC: “confirmed working on 8.5.10 too”

Thats before the 8.5.12 issue.

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.

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

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!

Edit: Linode just updated its mirror.

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

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.

This push for centralisation without the infrastructure to back it up has always been the most frustrating aspect of Docker Inc over the past >10 years I've worked on container runtimes.

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

Debian on the desktop is the best computer decision I ever made

https://github.com/php/php-src/tags

Though quite possibly I'm missing something ;)

---------------

edit: as I was typing the index was updated. So, as far as I can tell only just now (18:20 UTC) was it available for updating!

https://buildd.debian.org/status/package.php?p=php8.2&suite=...

Hehe. That's funny.

I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')

Also, sandboxing makes automatic exploitation harder. There is no FS persistence, so some checks simply do not pass.

I got downvoted heavily by other HNers for merely offering a solution to protect people’s legacy PHP servers. They said it should be deleted and “not worth working on”. The solution was free and open source but these downvoters commented as if it was worse than having your server PWNED. I still don’t understand why.

Why is word circulating that you can just sign up for Cloudflare and be 100% protected from this? They are burying the leed and trying to get new customers, and it's working.

It feels like many times PRs could just be that.

(Not even joking, if you're going to go hog go whole-hog.)

I would recommend running this binary as a user that has no access to any files, it can just proxy traffic through a port. I will put that in the README.

It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!

Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.

https://github.com/Qbix/proxy

UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.

That 70% of the internet still uses it is shocking to me. These organizations deserve to get burned badly. Let this incident be a warning to all of them!

Plus, wordpress updating isn't going to help you upgrade php.

They actually aren't. Most of the claimed cases of "recompilation" are just an emulator packaged into the same binary as the game so you can't tell it's an emulator, or are for projects that already had their source code available (in which case "porting" to WASM is trivial because all of the hard work is done by the people who write your-language-to-WASM compilers, and you just need to do a little bit of work to adjust your toolchain to use it). Everyone just takes slopshit at face value and shares clickbait without actually checking any of the work done. It's infuriating how empowering this software is for liars, honestly.