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.
The "official" PHP Docker images turned out to be a shit show tody. Seems like many maintainers fell for it and published updates that aren't really updates.
I'm currently waiting for a new docker image for another project, and their maintainer noticed the old PHP versions in the freshly built images and is still waiting or working on releasing a new container build.
"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!
Fully agree. Moved to FrankenPHP's static build (which was ready very quickly) to get away from it. Don't intend to ever use the "official" images again.
I'm wondering if it's not just better to use plain Debian base images.
FROM debian:...
RUN apt install php ...
This will take longer on a cold build cache, and pins the PHP version to the current Debian version. But Debian once again proved very reliable to patch in time.
I had to build and deploy my own Nextcloud images earlier today. :( Not a big deal because docker, just obnoxious that this got released into the wild and was being actively exploited before patches were available everywhere.
> 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.
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
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.
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.
> SMS may take some tricks (again, iMessage can be useful here).
How would iMessage help? Every SMS MFA implementation I've seen only works with phone numbers. If you mean "have a phone in the office hooked up to MFA and sign into iMessage with that phone's Apple account on multiple colleagues' devices", I've tried that. It technically works, but is flaky (Apple's reasons for forwarding-or-not greenbubble SMSes are opaque, and much less reliable than iMessages, though I'm told that improved recently due making things give up on Continuity and fall back to WAN more often). It also slams into the reality that most people want to use the Apple device that's getting the SMS codes with their personal Apple account, which causes friction.
If you need that capability, it's probably both more reliable and cheaper to use a web-controllable phone number (Google Voice & competitors).
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.
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.
I was fire-wardening at a carol service about 15 years ago (think ~850 year old gothic stone church with thousands of candles spread around on every available flat surface - looked amazing, potentially catastrophic).
I was sat near the back with a bucket of sand under my seat, and a guy sat in the middle of the row just across the aisle from me, who would have been around 40 or so, had a heart attack and died.
No warning, no history, just gone, and leaving a fairly young family behind. It was honestly shocking.
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... )
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 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).
> 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.
This issue with the "official" Docker images is the reason why (when I was still at SUSE) we switched to pushing releases ourselves to our own project and then eventually to our own registry.
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.
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.
last I looked, automatic updates for wordpress meant letting the web server write to the document root, which may be on the same level of negligence as not updating quickly.
Plus, wordpress updating isn't going to help you upgrade php.
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.
Yes and in general lots of users being on unsupported releases should also cause som reflection why that is. E.g. maybe support periods are too short or there are too many breaking changes with new releases.
It looksl ike they released official patches at least for 7.4 though:
> 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.
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.
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?
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.
Those websites can easily run in a php5 container, whilst the host os is up to date.
Websites depending on an older framework like Zend Framework or libraries like Doctrine 1 do not have a clear upgrade path and are stuck at php5 or have to basically start from scratch. php5 to the latest php8 is just a jump too big.
> 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.
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.
