> 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.
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.
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.
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.
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.
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.
> 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.
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.
> 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
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.
I've found that to be incredibly true in my career.
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.
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
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.
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.
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...
> 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
https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...
5.6.40-104+0~20261021.134+debian12~1.gbp7401dd
7.4.33-31+0~20261021.121+debian12~1.gbpe9c428
So far, no dice.
EDIT: looks like there are backports though
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.
Ever heard of WordPress?