> 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...
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.
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.
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.
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... )
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.
> 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.
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.
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?
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 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.
> 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.
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.
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
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.
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.
> 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...
Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:
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.
If you need Docker to run PHP software you're beyond any help already.
Yeah, I really enjoyed messing with php.ini back in the day! Setting it juuuust right for every different project on my dear pet.
Same goes for
I guess they were planning an update for today, for a moment the 8.2.35 threw me, but .35 is patched on 8.2, unpatched on 8.3 :)
FML. Can't get in to update our servers because of MFA and our director, who gets the codes, isn't in
Great example of performative enterprise security practice that contributes to degraded security posture, I suppose. Best of luck.
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.
This is where tooling like 1Password or Apple Keychain that lets you "share" MFA comes into play.
It doesn't allow sharing SMS, email or proprietary app based MFA.
Have lived this when a seeming healthy mid-30s man dropped dead. Nightmare.
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
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.
If you're optimistic you call it the "vacation or lottery" factor - if Bob wins the lottery tonight, will our shit still work tomorrow?
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.
We call it the HB3 (Hit By Bus Binder). Aka keep a document containing what to do if someone of your team gets hit by a bus.
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.
where do you work? >:)
Let's hope he didn't go skydiving. Seriously, you need to improve your processes.
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... )
Use the exploit to gain access, then upgrade
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.
Yes, it's embarrassing for Docker. Makes me wish I still had the classic LAMP stack.
A PR was posted within a minute or two of PHP's source code update. Then within a minute of the PR's CI job completing, it was merged, and the build took a while but is now complete: https://github.com/docker-library/php/actions/runs/396158697...
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.
It would however be reasonable to expect a maintainer to be available to start the CI faster than 30 minutes after the PR was created.
This is just the first step. See here for the full process: https://github.com/docker-library/faq#an-images-source-chang...
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.
Ah, indeed... I thought the GA push was the final step but there's another manual process between that and updating the Docker Hub image tags: https://github.com/docker-library/official-images/pull/22541
It should definitely have a 'high impact' workflow that bypasses some of those manual steps.
Docker have been carrying a broken python build for months.
they are wanting people to pay for the hardened version.
Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.
How about the Ondrej PPA repos for Ubuntu?
They're updated for all versions
The PR with the update is here: https://github.com/docker-library/php/pull/1694
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.
one of the more entertaining PRs I've seen
Enough spam comments to create a huge blacklist of misbehaving github users.
Might have to wait for the github outage to be resolved first :D https://www.githubstatus.com/
Still no release for Ubuntu... They are already half an hour late. Debian got the patch almost immediately...
if it makes you feel any better, the official dockerhub images aren't ready yet either.
They had almost a full day to prepare for this...
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.
(It's pretty trivial to build your own)
I wasn't aware of that. So I guess it's generally better to just use plain debian images and just install the required packages with apt.
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.
> 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.
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.
welp, I guess I should have done my research into what "docker official images" actually means.
Debian has had the patch for days, as have other main distros, and tested and prepared the release. That's why it was instant.
Unclear why Ubuntu is lagging.
Ubuntu probably started working on a rust based replacement instead: rphp.
curl -fsSL https://packages.sury.org/php/README.txt | bash
This adds Ondřej Surý's PPA to your system so you can upgrade the packages.
Just make sure to have the ca-certificates fixes already...
The builds are there: https://launchpad.net/ubuntu/+source/php8.5/8.5.9-0ubuntu2.1
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.
even the security.ubuntu.com mirror doesn't have it yet
Now they have finally shipped it.
Why do people still use Ubuntu?
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)
Why are they so slow. My Archlinux is already updated, but I still have to wait because of this.
PPA packages on LaunchPad being built here: https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
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?
No, it’s not a solution, it’s only one example proof of concept on how to exploit the vulnerability, there are more.
I blocked multipart uploads in addition to adjusting post_max_size, etc
blog that was helpful to me: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...
While the patches are being merged for the official docker images, perfect time for a github outage! https://downdetector.com/status/github/
apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now
You can on ubuntu change to use ondrej/php and update now
Add Sury's repo and update from there: https://packages.sury.org/php/README.txt
If you're tired of having to upgrade Wordpress, point your agent at this tutorial:
https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...
…or just enable automatic updates.
The problem with that is your site might get replaced by a rant by the CEO ...
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.
Available for Trixie :) (https://lists.debian.org/debian-security-announce/2026/msg00...)
Gentoo has it updated.
Apparently about 40% of PHP apps are still on PHP 7 and 5...
I see Debian has packages.
5.6.40-104+0~20261021.134+debian12~1.gbp7401dd
7.4.33-31+0~20261021.121+debian12~1.gbpe9c428
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.
That's going to give a lot of people a moment of reflection about whether or not they want to continue using PHP.
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.
I would think most people that are stuck on EOL PHP probably don't have a choice
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.
Anyone know if Microsoft updates azure web-app built-in php runtimes fairly quickly in this sort of scenario?
A bit too early for the announced coordinated release, no?
Their earlier comment said
> 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
Good point, at least now Debian has shipped the patched packages.
Two minutes before the announced 1400UTC? Or have I forgotten how to math?
More like >10min early. It's close, but given today’s speed of agents..
Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?
There are backports already.
Debian has a new build of 7.4 at least.
Not out on Ubuntu 20.04 yet, but sometimes they are a little slower. Hopefully should be posted later today.
PHP 7 hasn’t received an update since 2022 when it went EOL.
EDIT: looks like there are backports 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.
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.
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
Indeed this is undoubtedly happening as we speak to untold millions of forgotten sites.
So many scanners scan for various wordpress sites, if they save their results then they can more-or-less immediately build huge botnets.
What should be done? Can beneficent governments race to hack and patch servers?
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
> the rest will just get one new miner fighting for resources
Hehe. That's funny.
I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')
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.
Doing a...
... every now and then until that 8.3.35 turns into 8.3.36.
So far, no dice.
where is patch for alpine?
They bundled the fixes with a regular bugfix release, looks like.
Yeah, there was a new patch release in the works already. They just added this fix and got it out the door. Changelog: https://www.php.net/ChangeLog-8.php#8.5.12
Earlier submission with more comments: https://news.ycombinator.com/item?id=50180873
apt update
apt upgrade
debian package WHEN
Debian package 20 minutes before your post: https://lists.debian.org/debian-security-announce/2026/msg00...
Does anyone use PHP anymore? I assumed it was abandonware
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.
"Four diffs and seven lines ago..."
Are you fucking serious?
Ever heard of WordPress?
or Wikipedia.
Is WordPress still a thing? Why hasn't it been rewritten in Rust by Claude?
I see the downvotes and I don't really disagree with you.
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.