Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:
# docker pull matomo:latest
latest: Pulling from library/matomo
Digest: sha256:6e63589d31ec653f78e029084d21488640fdbbd9a42c96c872098f42c8678a02
Status: Image is up to date for matomo:latest
docker.io/library/matomo:latest
# docker run --rm matomo:latest php --version
PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.26, Copyright (c) Zend Technologies
with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies
The PHP build is from today, which is doubly misleading. 8.4.27 is the patched release, not 8.4.26. I wonder how many people will pull this image thinking they're good to go online again.
> out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
I'm pretty sure this class of problem would exist in GC'd environments too unless they're configured to abort on OOM, in which case you'd still be dealing with denial-of-service.
In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 27 minutes past due.
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.
What would happen if the director suddenly gets sick or decide not to come to work anymore? A lot of people assume that humans are reliable, they are not.
My team rotates 1 sacrificial member every week to be on call with prod k8s access. It limits who can just push things to prod at any given time while making sure everyone on the team has experience. If someone is out sick or on vacation we do time trading, it works out for everyone.
Exactly: limiting access is fine, lack of contingencies is not.
Some systems and services still only allow for one owner though (I'm not going to name names), which can be a big problem when MFA is mandated. From what the poster I responded to said, I'd be very surprised if that were the case for them though - just slightly daft policy.
One of my first boss called it the bus factor, not sure where the term comes from. What's the minimum number that need to get hit by a bus before it's impossible to keep things running. He used to say "you always have some bus factor, but it should never be one unless you're alone, otherwise you deserve whatever crap is going to rain on you someday".
I've found that to be incredibly true in my career.
With AI agents, I've been using sites/services that are bot friendly and don't require MFA.
Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )
I'm starting to suspect that they actually got the notice the same time we did, because if they got the patches there should be no reason it wasn't already built and ready to go (unless they're scared that "our build servers are public and everyone will know" so they literally held everything off until the release which seems so counterproductive as to be ... well, open-source silliness).
If you mean docker official images, it's just the "community" maintaining it, eg "some dudes". By no means should you consider it a mechanism to get timely security updates, I've seen horrible lag on that before.
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.
There are different approaches and it all comes down to who you trust. I don't think there's universal answer. If you have money, find image provider who's serious about security and hopefully they'll provide patches images quickly. Otherwise using Debian packages is a good default I think.
Honestly I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories.
And if you're using a docker package it's often JUST BECAUSE the host Debian/Ubuntu server is out of date for things you need, and Docker's the easiest way to "patch" that.
> I'm not a maintainer and can not merge this. Please wait until a maintainer has come around to look into this.
> This is merged, but I cannot find the image?
> After this PR has been merged, more steps are to be taken, including an upstream merge on docker-library/official-images and subsequent image builds. For a full description of the timeline, please refer to docker-library/faq#an-images-source-changed-in-git-now-what.
Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?
The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?
> We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
There are rare occasions when circumstances are more important than preserving an "EOL" designation. This appears to be one of those times where "official" centralized patches really should be made available for at least PHP5.6 and PHP7.4, and perhaps even 5.5 and all of 7.x. They're not covering themselves in glory by refusing.
Yeah, I have a legacy site that is popular and doesn't make money with some outdated version of PHP that will not update. Maybe I need to install OpenClaw on it.
But yeah, with AI agents, I don't really understand the purpose anymore. Legacy WordPress or laravel sites?
Yes and no, you have two setup, you're on LTS, it will be backported (done as I write than on Debian), not on LTS and you already have hundreds of unsafe stuff running anyway so it's just one more to the pile.
If those place at using a LTS release of their OSes they will be patched quickly (Debian already has). If they're not, they're already screwed by a lot more than just PHP I guess.
PHP runs literally half the web. Half the web will not apply this patch in any reasonable amount of time (a huge portion will never). This is going to be absolutely catastrophic.
The union of hosters which will not update to this patch, and users who have not updated to the past 283762 CVE is literally the same circle. I think that maybe a couple new not infected machines will get infected with a cryptominer - the rest will just get one new miner fighting for resources
They should probably invent some sort of Crypto Miner Communication Protocol (CMPC) that will make the process easier for all miners out there. Let's hope most are not bad actor crypto miners who ignore the protocol though, we should strive for more good actor crypto miners.
So if I wanted to build a botnet, then it would be very easy ;).
Infiltrate vulnerable PHP sites. Install backdoor(s). Secure root access. Patch PHP to lock out script kiddies. Let it sit dormant until you need to launch attack
You're right, you should just leave your PHP totally unprotected.
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.
Yes. Take your PHP service offline for the next year, until you can find a way to migrate it off your host and rebuild the PHP yourself on your environment. That'll help.
No, the entire world abandoned it when you realized it wasn't the perfect language. The rest of us are just role playing today basically. It's a bit of a lark, kind of like civil war reenactment.
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...
they are wanting people to pay for the hardened version.
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.
Some systems and services still only allow for one owner though (I'm not going to name names), which can be a big problem when MFA is mandated. From what the poster I responded to said, I'd be very surprised if that were the case for them though - just slightly daft policy.
I've found that to be incredibly true in my career.
And if the answer is no, well, then Bob just got Hotel California'd and can check out but can never leave.
Help Bob; help yourself.
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )
https://launchpad.net/ubuntu/+source/php8.3/8.3.6-0ubuntu0.2...
https://launchpad.net/ubuntu/+source/php8.1/8.1.2-1ubuntu2.2...
but nothing shipped yet by their mirrors, unlike debian.
This adds Ondřej Surý's PPA to your system so you can upgrade the packages.
They gave away CDs 20 years ago for free. Cooool.
Fedora is best for desktop.
Debian for servers that never need updates (but I even use Fedora for server now adays)
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)
Honestly I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories.
Because Debian uses older relases and a lot of custom patches. One example: Nodejs still doesn't have Typescript support in the Debian packages.
Distribution packages vs. official build from source has both pros and cons.
Unclear why Ubuntu is lagging.
Looks like we need to be patient:
> Why is this not merged yet?
> I'm not a maintainer and can not merge this. Please wait until a maintainer has come around to look into this.
> This is merged, but I cannot find the image?
> After this PR has been merged, more steps are to be taken, including an upstream merge on docker-library/official-images and subsequent image builds. For a full description of the timeline, please refer to docker-library/faq#an-images-source-changed-in-git-now-what.
The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?
blog that was helpful to me: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...
https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...
> We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
https://www.php.net/archive/2026.php#2026-10-20-1
apt upgrade
EDIT: looks like there are backports though
But yeah, with AI agents, I don't really understand the purpose anymore. Legacy WordPress or laravel sites?
5.6.40-104+0~20261021.134+debian12~1.gbp7401dd
7.4.33-31+0~20261021.121+debian12~1.gbpe9c428
So far, no dice.
Hehe. That's funny.
I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')
Infiltrate vulnerable PHP sites. Install backdoor(s). Secure root access. Patch PHP to lock out script kiddies. Let it sit dormant until you need to launch attack
(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.
This hurts because my resume has laravel and WordPress on it. I built sooo many sites/apps on it.
With AI agents, I just can't imagine using PHP anymore unless I'm patching legacy stuff.
I loved laravel too... WordPress, love hate.
Ever heard of WordPress?