PHP 8.2.35
github.com
Related ongoing thread: Today's PHP security release, and how we're strengthening security - https://news.ycombinator.com/item?id=50182987
github.com
https://www.wiz.io/blog/php2shell-php-rce
https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)
https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
Edit: was looking Wiz post when citation was from OpenAI
The launchpad server is throwing 503 errors all over the place, so that's probably the reason for the delay. Sury's own repo has the fixes all right.
I’d press go too - if something this big was known to some but not all…
We’ll all get through together
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.
The slop announcements are getting more annoying than the slop.
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.
August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team.
September 21, 2026: PHP acknowledges the reports and begins developing a coordinated fix.
AI is gonna make our stuff pretty robust, eventually. The transition phase might hurt a bit.
¯ \ _ ( ツ ) _ / ¯
PHP will always be the slop before AI.
The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details. Specifically once the POC came online. Would have been significantly more useful than these polished blogs.
Perhaps I'm missing something here, but the costs (dev/sre time, missed sales, potential data leaks and hacks) of the way that this was handled is significant.
[1] https://github.com/php/php-src/security/advisories/GHSA-6wmf...
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.
The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".
Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.
this is basically the same as releasing a working exploit.
Say I release a fix. I'm some rando but I go out to the world and say I fixed an issue with php. Use my version instead! Not telling you what I fixed, it's a secret, just trust me.
It will take, with LLM help, attackers a couple hours, tops, to reverse engineer my fix into active exploitation. Meanwhile, I'm some rando so no one's even heard of me, people who do hear don't automatically trust me to install my fix, so very few people have my fix. Meanwhile, the exploit is out there thanks to me and people are getting their sites hacked thanks to me.
That seems like a problem, no?
>I'm some rando so no one's even heard of me
Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.
There was an official patch within a few hours. It probably would have been a lot longer.
And that was the screwup case. If today had gone correctly the official patch would have been out by the time the bug was public.
If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.
Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.
If you are warning people to turn off their servers. You might as well give them a patch at the same time.
1. The time it took to develop the patch doesn't matter. Nobody leaked anything during that period. It just needed to not be a huge length of time.
2. The time between the warning and the patch release is overall a good thing. In this case the secrecy failed halfway through and we only got a fraction of the benefit, but it was still better than "surprise and good luck with the imminent exploits, hope you weren't asleep!". If the secrecy hadn't failed it would have been much better.
3. There needs to be an official patch before releasing the details. Some random untrusted person publishing a patch has all the downsides of releasing the exploit but people can't safely install it fast.
Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.
Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!
Post AI, Its efficiency pre announcing the exploit to bad actors until the official disclosure.
You can just watch the diff log of every open source project with a small local model, and look for anything that touches buffers, function pointers, or shell integration.
It could be an hour between release of a fix before the exploit starts attacking servers.
Guess what also could happen within an hour? A coordinated Internet wide panic that shuts down all vulnerable servers.
---
We actually have a recent example. OpenAI hack.
An undisclosed vulnerability fix to a image formal lib; packages into debian 12 running in a docker, used by imagemagic, used by discourse running OpenAIs user forum.
Most users, who don't know the answer to your questions, rely on the distro to figure this out (and often pay good money for it).
No one needs to use their work, or indeed PHP at all.
But that's why the PHP security team exists.
But the PHP team is the one that got the security disclosure.
If I had details on a RCE like this I'd report it but if I got no response for a WEEK I'd be trying other venues.
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
We don’t know when it went from a “memory safety issue” to “php2shell/RCE”.
Calif’s report is a little light on timelines, but reading between the lines, it seems they took a while to turn this into an actually exploitable vulnerability.
Finally, at least pre-LLM (and maybe a bit outdated now), responsible security disclosure norms is that you usually do wait for vendor (up to 90d) if there’s no signs of active exploitation. Even if it’s a RCE. Actually, especially if it’s a RCE.
The last thing you wanna do is go pinging random non-security PHP contributors or maintainers and have it leak with zero patch. That is truly the worst outcome.
Yes, this is bad, but also, it’s apparently been bad for decades; and it could’ve been much worse.
In the link from the comment to which you replied, buried deep below the comic strips and all that, there is this explanation which seems to confirm your guess:
> Right. We should explain from the start. My first step of finding if any long-lost siblings of Stefan's 2004 bug were still lingering in the codebase was to look for ways to exceed the memory_limit that allows us to throw a controllable fatal. I asked my LLM companion for help.
> The first useful finding was a way to bypass the smaller post_max_size barrier that normally prevents a request from delivering enough memory pressure to reach memory_limit. PHP compares post_max_size with the declared Content-Length before automatic POST parsing begins, but it does not enforce the same limit against the bytes it actually consumes. Apache can therefore pass a chunked HTTP/1.1 or lengthless HTTP/2 multipart request with no meaningful declared length. A configured input-decompression filter creates the same mismatch between the compressed length and the decoded stream.
> The second useful finding was a way to exhaust memory_limit with a multipart request that remains below post_max_size. An RFC1867 file-upload part with filename="" contains no file data, and PHP does not count it toward max_file_uploads. PHP still creates all six corresponding $_FILES entries: name, full_path, type, tmp_name, error, and size.
That said, PHP team handled this poorly. How does letting everyone know so they can "prepare" help anyone at all. It just creates panic.
If you have a bad process, fix the process.
General industry practise (or at least google) is to wait 90 days of being ignored before trying something else. And google got hugely criticized in the beginning for only waiting 90 days. You are suggesting this person should only wait a week before going full disclosure? They would be crucified if they did that.
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.
They literally employ full-time Vulnerability Researchers doing nothing but 0-day discovery and PoC creation 24/7 to add to their horde. Plus contracting with the MIC for their full-time VRs for the occasional project.
and yet they attacked and lost ALL their bases around the Gulf and today are in what can best be described as a Pyrric Stalemate.
Also, Vulnerability Researchers working for the NSA are not located in the Gulf, and the NSA was not involved in that situation.
I fail to see how it's relevant whatsoever. The U.S. is not a monolith.
Read the original text, it makes it seem that the NSA has some next level capabilities in hacking and discovering or requesting zero days from vendors. Something which seem absurd given the intelligence failure that we see in the Persian gulf.
> Also, Vulnerability Researchers working for the NSA are not located in the Gulf, and the NSA was not involved in that situation.
May be difficult to believe but Iranians also have computers. If you want to believe the NSA has incredible multiple zero days and Iran has been at worst in the top 3 of enemy nations, how did they not know about the missiles and drone programs ? How could they not know ALL or SOME of their locations ?
> I fail to see how it's relevant whatsoever. The U.S. is not a monolith.
Meaning ?
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?
Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates.
> nowadays even the rumour
I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant.
That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate.
> then many people will be in no rush to upgrade, and will get pwned.
The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
See PHP foundation blog post on their timeline
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.
"we the people deserve to know about vulns on day 0"
oh yeah? and what happens when a 0 day is released?
it's the same ignorance over and over.
Amazingly, AWS Linux has not been patched yet.
The PHP team knew about it since September 21st.
Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
It's like slop for infosec markters
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
Today's PHP security release, and how we're strengthening security - https://news.ycombinator.com/item?id=50182987 - Oct 2026 (114 comments)
PHP2Shell: AI uncovers critical RCE in PHP - https://news.ycombinator.com/item?id=50180836 - Oct 2026 (146 comments)
PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619) - https://news.ycombinator.com/item?id=50176077 - Oct 2026 (61 comments)
Security advisory: Critical remote code execution vulnerabilities, update now - https://news.ycombinator.com/item?id=50172041 - Oct 2026 (631 comments)
Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming - https://news.ycombinator.com/item?id=50167754 - Oct 2026 (60 comments)
The average phpBB or Wordpress, even if it's behind cloudflare, probably has a direct IPv4 that's not disabled.
This is a storm, but hopefully quick to blow over with a panic frency of apt update or docker build.
The immediate exposure is faar worse here though, since its by design internet facing code.
A college enabled logging on their server as soon as they saw the news, and got dozens of attempted requests against index.php.
If 97% of programs use 2x more compute, the total amount of compute used in the world will be nearly unaffected.
Come to think of it, I believe it would actually be a good idea to lobby for exactly that. Memory safety issues have been a plague in IT for far too long.
Not in general no, but it is for PHP. If you cared about a 2x overhead why are you using a language with 10x overhead (conservatively)?
*rolls 3"
"Your IPO gets delayed another month"
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 52 minutes past due. (posting comment again, because the other thread i posted in was marked as dupe.)
Edit: Seems like GitHub has issues with merging PRs: https://github.com/docker-library/official-images/pull/22541
https://github.com/docker-library/official-images/pull/22544
Maybe the guy that has to click OK is asleep?
https://github.com/docker-library/faq#an-images-source-chang...
https://hub.docker.com/_/php/tags
EDIT: 25min later, nope.
https://hub.docker.com/layers/library/php/8.5.12-fpm/images/...
Newest: 5.6.40-104 which has the CVE fixes.
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
Well off to a good start here.
Exceptions aren't great for that either, but languages that feature them at least have the tooling and support features to make them work. C has no destructors or anything to handle exception unwinding cleanly. Scheme has call/cc, but scheme has a big runtime and garbage collector to deal with the fallout.
Let the branch predictor do its job and implement error checking properly, I say. If performance matters so much that you worry about pipeline flushes and icache thrashing, surely you wouldn't be using PHP anyway.
setjmp, longjmp and gets are 3 function I would absolutely ban in any C codebase I would be responsible for. Maybe strncpy too. and strtok. C is fun.
There's no automatic cleanup of anything, no built-in way to even register things for manual cleanup, and it doesn't even consistently save/restore the values of your local variables. A local variable that was mutated between the setjmp and longjmp may end up with the old value or the new value depending on where the compiler decided to store it. The documentation does mention this and says that you need to use the volatile keyword to avoid it, but in typical C fashion there's nothing to enforce this, it's just up to the programmer to remember it.
It is extremely uncommon in C codebases because it is extremely dangerous. It makes hazards like pointer arithmetic and manually-terminated strings look like a walk in the park by comparison.
longjmp is very uncommon, I don't recall seeing any high-quality C codebase using it, and if you want exceptions, you should pick a different language because longjmp doesn't really give you comparable semantics. It's basically saying "ok, computer, f--k my s--t up".
The fact that OOM conditions are an enduring source of exploitable vulnerabilities in PHP really should give everyone a pause. Like, that's not a thing in any sane project.
Lua does. (though it does have the option to use C++ exceptions or MSVC stack unwinding instead)
> Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
But there were two vulns - only the second required the two requests.
How does that work? Exec(ve) without fork? That should still clean up the PHP state.
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
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.
> This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Glorious. Today of all days it would genuinely give me pause for caution.
edit: yeah, really not feeling that: https://github.com/php/php-src/compare/php-8.2.34..php-8.2.3...
Hopefully just a mistake? But looks like a botched release at the least
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
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!
From what I can see, this causes a crash only, and isn't weaponisable. It's a use-after-free, but the reclaim window is zero by construction.
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.
It's going to be pretty bad if we all panic to get the latest PHP up, and all confidently roll out our updated websites, just for them to still be vulnerable to something serious anyhow.
We are damned if we don’t and (often times) damned if we do
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.
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...
# 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
$ docker pull wordpress:fpm && docker image inspect wordpress:fpm --format '{{.Created}}' && docker run --rm wordpress:fpm php --version
fpm: Pulling from library/wordpress
Digest: sha256:c6d271a445510a3e08cfcc487750ac014f4464165ad6df6356da04680be8e907
Status: Image is up to date for wordpress:fpm
docker.io/library/wordpress:fpm
2026-10-21T01:27:06.695704995Z
PHP 8.3.35 (cli) (built: Oct 21 2026 00:33:17) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.35, Copyright (c) Zend Technologies
with Zend OPcache v8.3.35, Copyright (c), by Zend Technologies
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.
FROM debian:...
RUN apt install php ...
"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!
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.
Proprietary apps are a pita.
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).
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
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.
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.
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 realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
Edit: Linode just updated its mirror.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
What everyone is looking for.
I assume it just got pushed?
if (ZEND_HAS_OOM()) {
goto oom_nodeset;
}
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
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.
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.
It should definitely have a 'high impact' workflow that bypasses some of those manual steps.
they are wanting people to pay for the hardened version.
> Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.
They'll of course install a backdoor and patch the exploit so others can't come in. They won't deface the website, so there won't be signs.
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.
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.
awake2death or something
It seemed to be helpful for others too so I packaged it up, should work on most Nginx / Certbot servers. hopefully its useful: https://github.com/Indemnity83/popcorn
`[00:06:03.209] pecl install -f amqp igbinary redis imagick` :sad_face:
Disclosure: I'm a PHP core team member and also contributed some code to PIE.
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
Maybe just CYA.
I'm 90% sure CGI can't be exploited this way in default configuration with ASLR and 99% sure if PHP is configured with memory_limit=-1
That said, don't be an idiot and switch to CGI instead of patching. I'm like one of three guys running PHP in CGI mode and I'm vaguely satisfied I have the most resistant configuration.
The reason, BTW, I run PHP in CGI mode is so I can (moral equivalent of) suexec to a locked-down sandboxed environment that limits exploit blast radius. I could do the same with fcgi daemon, but the suexec is stateless, and roundcube doesn't need the performance.
In general, anything stateful or long-lived is just one more thing that can go wrong. One reason why the trend of turning everything into a persistent daemon drives me nuts.
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.
This is false. The Docker Official Images team (i.e. the folks with write access to the docker-library/* organization) are Docker employees.
Unclear why Ubuntu is lagging.
This adds Ondřej Surý's PPA to your system so you can upgrade the packages.
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.
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)
Debian on the desktop is the best computer decision I ever made
Ubuntu literally stole debian, added own wallpaper and started selling it as its own distro.
I thought the real lesson was "assume your web server is compromised if you use php, and try to make sure php doesn't touch anything too critical"
At that point I would not need a backend.
5.6.40-104+0~20261021.134+debian12~1.gbp7401dd
7.4.33-31+0~20261021.121+debian12~1.gbpe9c428
But yeah, with AI agents, I don't really understand the purpose anymore. Legacy WordPress or laravel sites?
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.
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.
https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-...
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
Hehe. That's funny.
I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')
This is very entertaining writing on that subject:
https://nesbitt.io/2026/06/26/incident-report-cve-2026-lgtm....
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...
Some web-services are back up again here in central Europe, but some are not, which is very annoying. Kind of surprising to see how much PHP is actually used. Hate it or love it, PHP really is very important still - lots of the web depends on it.
https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...
Now are available in the php-src github
and not the github mirror?
I've also published the built images from them to GitHub Registry, but of course it's best to inspect any public repo/docker image before using them blindly.
What I meant was: don't trust prebuilt images from a stranger, including mine. I've provided them just as a convenience, the Dockerfiles and patches can be easily looked-through, and building them yourself is the safer option if you need these docker images.
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!
It says pecl.php.net recovered but downloading source for extensions ends up with 504 most of the time.
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
https://docs.nvidia.com/datacenter/tesla/driver-installation...
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.
I would not recommend using PHP. The PHP team keeps breaking backward compatibility and trying to introduce new features instead of focusing on fixing bugs and hardening the compiler.
I have not seen confirmation Cloudflare is doing anything except playing whack a mole with certain request patterns. PHP Core Devs have been clear you need to upgrade. If this is true, it's disgustingly opportunistic that Cloudflare is using this critical security time to lie to people that they are safe.
Anyone from Cloudflare want to speak to this?
These were rolled out before the exploit became public.
I would wouldn't describe that as damning.
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.
The old way of doing things like putting old unpatched stuff behind firewalls is pretty much a dead pattern today.
Note I want it to work with the backports too, not just the latest version.
> 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 already functional exploit scripts on GitHub, you can target any Wordpress site right now.
> PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Earlier versions are not fixed by PHP official and need vendor patching where available
EDIT: looks like there are backports though
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
By simply searching for websites that used local includes to load other pages, you could get RCE.
At this point, running webapps in JS workers/sandboxes sounds like a good idea. Vendors take care of patching.
Also, sandboxing makes automatic exploitation harder. There is no FS persistence, so some checks simply do not pass.
made it in time hopefully
The thing that's annoyed me the most is the speculation and misinformation, filling in the gaps. Folks looked into the php-src and figured out one of the vulnerabilities, starting saying you should disable certain php settings and then core PHP developers on obscure mailing lists hinting this isn't enough.
Given how inexpensive it is for agents to scan popular OSS projects, disclosure needs to be more discrete and you cannot publish fixes to OSS before disclosure. People will be and are watching for this kind of thing already.
docker pull wordpress:fpm && docker image inspect wordpress:fpm --format '{{.Created}}' && docker run --rm wordpress:fpm php --version
So far, no dice.
apt upgrade
Maybe Hetzner know a company that can help out with extra computer resource...? /s
Useless. My fault for paying peanuts
1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.
2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.
3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.
4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.
5. Lower max_input_nesting_level and post_max_size, per the advisory.
6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
The fact is you had no idea how useful or dangerous your advice was. PHP maintainers said to shut it down, how many people followed your advice instead? Did it work or just leave them vulnerable? Do you know?
Because you're heavily implying that the people who knew about the details of the vulnerability were panicking and thank god we had you with an LLM
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!
PHP is a memory-safe language. This vulnerability is a memory safety bug in the VM, which does happen from time to time. It happens with V8 (JS), Java, C#.
The language itself was one big hack when it was created. It has improved somewhat but just like with C++ you can still use the C syntax that's at the core of it all.
This isn't the last we'll hear of PHP vulnerabilities because the exploits exist on multiple levels. Not just the language (runtime) but the solutions using it too.
PHP is a memory safe language, just as memory safe as Java, C# and JS. The runtime itself has very few vulnerabilities and bugs, and is quite mature. There’s no “drop down into C” type thing in PHP, where you can just write unsafe code whenever you want. The closest thing is extensions, which operate on the runtime itself.
In the past 10 years, the PHP runtime has had little to no exploitable vulnerabilities. The V8 runtime has had much more. Mostly because their implementation is much more complex.
The PHP language was hacky in the very early days, but for over a decade now it’s been mature and professional. It’s basically just dotnet.
This incident got a lot of publicity, but what about the thousands of plugins out there full of hacks and sloppy programming?
Certain applications, like Wordpress, are notorious for vulnerabilities. But these happen at the application level. PHP, as a language, is memory safe and largely secure.
Think of it this way. V8 has had numerous RCE vulnerabilities in the runtime. But also, react router has had RCE vulnerabilities. But react router was due to poor application design, much like Wordpress, where actors could trigger arbitrary code on the backend from manipulating requests. That’s very similar to how most wordpresss vulnerabilities work.
Yeah it sucks, but the alternative could be worse.
https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...
Plus, wordpress updating isn't going to help you upgrade php.
1. Hey LLM, turn this binary into source code.
2. Hey LLM, see any glaring security issues with this source code?
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.
Ever heard of WordPress?
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.