I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
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.
>OpenAI and these security companies sat on this for 2 months
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.
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.
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.
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.
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.
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out.
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?
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
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.
Maybe the NSA ‘requested’ some time to use the exploit on some high value targets.
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.
> Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
If I understood the timeline correctly, there was an announcement made somewhere that an RCE would be announce w/ a patch, and the internet just scanned the entire codebase, they really fumbled this for the sake of having a PR post for OpenAI.
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.
Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
This isn't a terribly uncommon method of 'discovery'. In maths and sciences there have been tons of papers that have highlighted something new but were never really connected to anything else and then largely forgotten. Later they are picked up by someone else and connected to a much bigger whole.
One of the most common PHP based applications out there, therefore a good comms channel (via their forums and any mailing lists, both public and for people who have managed instances with them or are otherwise paying for support contracts) to make sure people are aware of the need to update. That would make the company one worth keeping in the loop, if only in one direction, I would have thought?
Fair point. I thought that had died down, though for some years I've not had reason to keep particularly informed about the state of WP so I could be missing a lot of hot gossip.
This is obviously bad, but in my 20 years of hosting with PHP, I've never had to take the steps of taking down servers preemptively. It's not good, but honestly, and I think the way this was handled could leave a lot to be desired, I think this might be the "worst" we've had with PHP, and it took a while to get here.
FWIW this is the most mainstream vulnerability in the new era where everyone has access to AI agents that have the potential capability to find and widely exploit the vulnerability far faster than the past timeframes for disclosure and patching.
It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
Not even $700 a month? Seriously, there must be thousands of highly profitable companies depending on this guy’s maintenance. Once this is all sorted, please hassle your employers to give something back to him!
Yeah this, I always see so much hate towards businesses for finding tax loopholes or not donating etc but people forget that businesses are made of individuals with their own often conflicting subgoals, but overall has to try to maximize profit so they will never voluntarily pay more tax than legal minimum or be philanthropic if they do not have to or do not benefit explicitly.
I think there's a lot to learn from the last twenty four hour's events. An absolute nuclear bomb of an exploit affecting every version of PHP back to 2012 (which nobody should be using of course, but I've worked in plenty of environments that are not up to date).
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.
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.)
So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.
And I'm maintaining a box on 18.04 over here, and lo and behold its Pro subscription isn't showing up as active, so I couldn't get the update even if they do release it.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
Some have, but others are still showing "needs evaluation", and still no update for 20.04. I've just turned off php for now, as we only used it in a couple of places and won't be missed for a day or two.
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
Since I have to go through a bunch of php repos today at work I ended up releasing a CLI tool that automates that process by listing out the steps you need to take to stay away from the vulnerability.
Here's the link incase it helps anyone https://github.com/Amsozzer1/php2shell-repo-audit
Dude, today of all days is not when I'm going to trust some random CLI tool that was vibed out. I'm not saying your work isn't helpful, but it would probably be a lot better to just release your prompts you used to build this and let others build it on their own.
I wouldn't listen to him. This is very helpful to people that might be managing dozens or hundreds of servers and need a way to quickly figure out things. It's literally open source and we can point our agent to it and have it examine the source code for anything that looks suspicious first. No need to sit here for a couple hours trying to go back and forth and create something that you already took the time to do. Thanks for the work!
>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.
Debian always seems to be the grown-ups. I'm a Linux novice so I couldn't get Nvidia drivers working on it but that's the only reason it's not running on my desktops.
Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
"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
What I've been feeling lately is that security vulnerabilities will inevitably keep being discovered, and I worry whether humans can ever patch all of them.
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)
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.
I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
It was your response. Of course you prefer your response.
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
Why don't you do something useful and rewrite it so it's not claude output any more, but says the same thing in a way that you're satisfied with?
Then your own comment would not be such low effort and useless human slop.
Do you agree or disagree with the comment's claims? Did YOU verify anything? Let's all hear you fact check and proofread and reword what it said so it matches your standards, instead of just listening to you bitch and complain without offering any useful information.
Or do you not actually know anything about PHP administration, programming, and security, so you're only capable of information-free drive-by anti-ai posts, without any other useful content or corrections?
People have been saying this for the past 16 years, but the reality is once a system is in production over time it becomes increasingly risky to replace it. Because over the life of a piece of software you make tons of small fixes, resolve bugs, adding customer-specific functionality, etc. that you'd completely overlook when planning our requirements for a rewrite. Which is a big problem when other systems are dependent on the software operating a specific way i.e. APIs, web services, and so forth. Not to mention the economics of a rewrite also has to make sense. Nobody is going to spend 2-3 years recreating what they already had and get no additional functionality out of it. Certain software basically has to get so bad that literally anything replacing it is better than what came before for replacing it to be the right approach.
For anyone who can't patch their PHP for some reason, here is a proxy that eliminates the threat for you -- it's open source, you can add it to your servers:
https://github.com/Qbix/proxy -- open source MIT licensed, I made github actions compile it as a Cosmopolitan binary so it can work across many operating systems (thanks Justine)
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
It's free, MIT open source. It was the best I could do. Run it under a Linux user with no permissions to access anything. All it's supposed to do is proxy requests. Don't give it access to any files.
You know, normally I'd be okay with these comments, but in this case you're actively hurting a lot of people by this bullshit. Many people need something other than patching PHP.
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
The one we're in right now, where we're waiting for vendors to rebuild the packages (I'm ass-blasted that the delay to 14:00 UTC wasn't for the vendors to build packages but seems to be a PR stunt?).
You're right – need to fix the Cosmopolitan build in GitHub actions. On it!
UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.
Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI:
https://www.php2shell.com/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)
https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)
I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
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...
>OpenAI and these security companies sat on this for 2 months
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.
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.
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.
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
and they also have plenty of exposure to their motherships burning money on LLMs
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.
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.
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
So anybody can just push out a new release of PHP?
Sort of by definition of open-source, yes. It's just that nobody downstream is likely to accept Joe Public's random fork of PHP.
What would you have a security team for then?
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out.
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?
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
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.
Maybe the NSA ‘requested’ some time to use the exploit on some high value targets.
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.
> Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
If I understood the timeline correctly, there was an announcement made somewhere that an RCE would be announce w/ a patch, and the internet just scanned the entire codebase, they really fumbled this for the sake of having a PR post for OpenAI.
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.
One security firm included "session.upload_progress.enabled", "session.use_strict_mode", and "php-fpm" in the SEO tags for their initial disclosure that a vulnerability existed after the HN post came up. I imagine this was a good hint. https://web.archive.org/web/20261021005246/https://sansec.io... https://x.com/its5q/status/2112700519261032497
The somewhere was a loser on this very website https://daubois.dev/blog/cve-2026-109618-php2shell-rumors/
This post reads like pure slop to me
They haven't even been able to release the patch on time. Ubuntu still hasn't it
Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
Sury is up for all versions too
Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
Anyone using a non-default version from the semi-official PPA by Ondrej Sury is still waiting for an update.
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.
at 15:00 UTC, spot checking, Debian 13 has a fix, Ubuntu 26.04 and Fedora do not.
I had an email from usn recently
Wiz is owned by Google and Argon gets the main credits. So difficult to tell these days. But AI is obviously useful here.
Edit: was looking Wiz post when citation was from OpenAI
Of course it's useful, but you can't absolutely not leak something as big as this.
I heard this was leaked several days early and that’s why folks seem to be on the back foot.
I’d press go too - if something this big was known to some but not all…
We’ll all get through together
surprising it took nearly a month to acknowledge the bug
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.
Took them almost 7 years even. According to the Calif write-up it was already reported in 2019 (https://bugs.php.net/bug.php?id=78876) and 2024 (https://ostif.org/php-audit-complete/).
Lol wait so OpenAI's LLM to discover this vulnerability most likely just looked it up in an old forum post?
This isn't a terribly uncommon method of 'discovery'. In maths and sciences there have been tons of papers that have highlighted something new but were never really connected to anything else and then largely forgotten. Later they are picked up by someone else and connected to a much bigger whole.
It's only one piece in the full exploit chain.
That's what my agent did to find a UAF. It just took a public one from calif off the internet and found it still flagged asan.
No way to prevent this, says only language where this regularly happens
LOL
PHP will always be the slop before AI.
Why is WordPress out of that list? Isn't it the single major PHP installation in the whole Internet across hosted and self-hosted instances?
Well, WP is just a program written in PHP.
One of the most common PHP based applications out there, therefore a good comms channel (via their forums and any mailing lists, both public and for people who have managed instances with them or are otherwise paying for support contracts) to make sure people are aware of the need to update. That would make the company one worth keeping in the loop, if only in one direction, I would have thought?
Well, it would help if WP were actually controlled by one entity, but currently it's dominated by factions and infighting.
Fair point. I thought that had died down, though for some years I've not had reason to keep particularly informed about the state of WP so I could be missing a lot of hot gossip.
They have hosted instances as well though. Not sure their market share though.
Because the CEO of Wordpress has gone insane, basically.
Automattic is on the list, tho.
WordPress is down right now. A bit late for patching though ...
I agree, WordPress should be like the first thing they point out. I'd imagine most WordPress users don't even know it runs on PHP
Wiz Khalif AI
Yet it was leaked and I can't see a single "Here's this piece of code you can run to validate the fix actually works"
It's like slop for infosec markters
> https://www.php2shell.com/
Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
Thank you, Wiz Khalifa.
This is obviously bad, but in my 20 years of hosting with PHP, I've never had to take the steps of taking down servers preemptively. It's not good, but honestly, and I think the way this was handled could leave a lot to be desired, I think this might be the "worst" we've had with PHP, and it took a while to get here.
FWIW this is the most mainstream vulnerability in the new era where everyone has access to AI agents that have the potential capability to find and widely exploit the vulnerability far faster than the past timeframes for disclosure and patching.
Advisories with the details are public:
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
>PHP uses longjmp()
Well off to a good start here.
did I skim this correctly that with the mitigation shared this does not (yet) impact fpm-usage and classic CGI (vs. mod_php) is not impacted either?
No, every platform affected.
> Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
https://www.php.net/archive/2026.php#2026-10-21-5
Click the associated tag:
> 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
Same on the older few. I'm not sure I understand it though, seems strange you can have a tag for a commit that's only present in a fork?
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
main (or master) is just another branch to git.
Ondrej might appreciate some monetary love on a day like today.
https://www.patreon.com/cw/oerdnj
There is a one time option on his github as well for those who don't want to do subscriptions.
Not even $700 a month? Seriously, there must be thousands of highly profitable companies depending on this guy’s maintenance. Once this is all sorted, please hassle your employers to give something back to him!
Someone tell Ondřej to sell some self-published "guide to PHP" for $200 and we can easily expense that.
Yeah this, I always see so much hate towards businesses for finding tax loopholes or not donating etc but people forget that businesses are made of individuals with their own often conflicting subgoals, but overall has to try to maximize profit so they will never voluntarily pay more tax than legal minimum or be philanthropic if they do not have to or do not benefit explicitly.
I think there's a lot to learn from the last twenty four hour's events. An absolute nuclear bomb of an exploit affecting every version of PHP back to 2012 (which nobody should be using of course, but I've worked in plenty of environments that are not up to date).
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.
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.)
Yeah, I was very surprised to wake up just now and find docker still vulnerable.
So-- if PHP's sourcecode was unavailable (closed source), would this ever have been found? Probably not. Maybe it is safer to be closed source.
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
I installed the updates 18 minutes ago, they're live.
Definitely not available yet, launchpad says last builds are from 2026-10-12
use packages.sury.org instead
follow https://packages.sury.org/php/README.txt
Ondrej has already said "deb.sury.org will carry packages as they are built".
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
You can see them building here, it looks like most should be ready within the next few minutes:
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.
And I'm maintaining a box on 18.04 over here, and lo and behold its Pro subscription isn't showing up as active, so I couldn't get the update even if they do release it.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
Same, I'm spamming the apt update and so far nothing on 22.04 or 24.04 lts
I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
They had plenty of time to prepare for the release, what a shit show
Why is the official source (php.net) marked as [dupe] https://news.ycombinator.com/item?id=50180943
and not the github mirror?
https://ubuntu.com/security/CVE-2026-109618#status fixes have been back ported in Ubuntu LTS versions just now.
Some have, but others are still showing "needs evaluation", and still no update for 20.04. I've just turned off php for now, as we only used it in a couple of places and won't be missed for a day or two.
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
Now I need to get the cute name for a vm vulnerability that attacks offline servers ...
awake2death or something
Sury released backports for older versions, as always hes incredibly reliable.
If open source has these vulnerabilities, imagine proprietary ones.
Since I have to go through a bunch of php repos today at work I ended up releasing a CLI tool that automates that process by listing out the steps you need to take to stay away from the vulnerability. Here's the link incase it helps anyone https://github.com/Amsozzer1/php2shell-repo-audit
Dude, today of all days is not when I'm going to trust some random CLI tool that was vibed out. I'm not saying your work isn't helpful, but it would probably be a lot better to just release your prompts you used to build this and let others build it on their own.
I really like the idea of sharing details prompts/specs.
It feels like many times PRs could just be that.
makes sense, will release the docs. thanks!
I wouldn't listen to him. This is very helpful to people that might be managing dozens or hundreds of servers and need a way to quickly figure out things. It's literally open source and we can point our agent to it and have it examine the source code for anything that looks suspicious first. No need to sit here for a couple hours trying to go back and forth and create something that you already took the time to do. Thanks for the work!
Versions: 8.2.35 8.3.36 8.4.27 8.5.12
Now are available in the php-src github
can't find it.
Check the tags:
https://github.com/php/php-src/tags
>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.
Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.
debian trixie just rolled updates.
Can confirm. Just updated to fixed version
Debian always seems to be the grown-ups. I'm a Linux novice so I couldn't get Nvidia drivers working on it but that's the only reason it's not running on my desktops.
when's bookwarm coming?
packages are building:
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
Already, including backports to 7 and 5.
Have we ever seen the "get ready for a security release tomorrow" email before?
https://www.php.net/archive/2026.php#2026-10-20-1
Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
Anyone know when amazon linux 2023 is releasing updates?
Does anybody know when Amazon Linux 2023 will get this release?
Thread here: https://github.com/amazonlinux/amazon-linux-2023/issues/1148
This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.
https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0...
What everyone is looking for.
It says "3 days ago". The tag is 2 days old.
I assume it just got pushed?
Yeah… it was patched in the source 3 days ago. Check the linked GHSA.
This reminds me of the old days when PHP was such a vulnerable language.
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.
Have a search for V8 RCE/CVEs over the past year.
So they've added malloc fail checks and tests for malloc fail throughout.
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
PHP is tracking its own memory usage internally with limits configurable via php.ini.
Time to restart Apache again!
"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
Amusingly enough restarting php after each request seems to block the issue
What I've been feeling lately is that security vulnerabilities will inevitably keep being discovered, and I worry whether humans can ever patch all of them.
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)
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.
This is just Claude output. Did you verify anything or just rehash the links?
HN should ban comments that are just Claude output
https://news.ycombinator.com/newsguidelines.html#:~:text=Don...
I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
It was your response. Of course you prefer your response.
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
It's just Claude output of what I've done; the other URL has the basics.
Why don't you do something useful and rewrite it so it's not claude output any more, but says the same thing in a way that you're satisfied with?
Then your own comment would not be such low effort and useless human slop.
Do you agree or disagree with the comment's claims? Did YOU verify anything? Let's all hear you fact check and proofread and reword what it said so it matches your standards, instead of just listening to you bitch and complain without offering any useful information.
Or do you not actually know anything about PHP administration, programming, and security, so you're only capable of information-free drive-by anti-ai posts, without any other useful content or corrections?
Ball's in your court.
C'mon Ondřej..
it's out?
PHP is done.
People have been saying this for the past 16 years, but the reality is once a system is in production over time it becomes increasingly risky to replace it. Because over the life of a piece of software you make tons of small fixes, resolve bugs, adding customer-specific functionality, etc. that you'd completely overlook when planning our requirements for a rewrite. Which is a big problem when other systems are dependent on the software operating a specific way i.e. APIs, web services, and so forth. Not to mention the economics of a rewrite also has to make sense. Nobody is going to spend 2-3 years recreating what they already had and get no additional functionality out of it. Certain software basically has to get so bad that literally anything replacing it is better than what came before for replacing it to be the right approach.
Just how debian was done after weak keys, OpenSSL was done after heartbleed, or Windows was done after (rolls dice) the print spooler RCE
And how Crowdstrike was done after their fiasco 2 years ago...
always was
always will be
For anyone who can't patch their PHP for some reason, here is a proxy that eliminates the threat for you -- it's open source, you can add it to your servers:
https://news.ycombinator.com/item?id=50181752
https://github.com/Qbix/proxy -- open source MIT licensed, I made github actions compile it as a Cosmopolitan binary so it can work across many operating systems (thanks Justine)
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
Please stop pushing your slop to profit off the situation.
Surely the "structual fix" for a use-after-free is a pile of unreviewed C code! I don't see any problem here.
It's free, MIT open source. It was the best I could do. Run it under a Linux user with no permissions to access anything. All it's supposed to do is proxy requests. Don't give it access to any files.
You know, normally I'd be okay with these comments, but in this case you're actively hurting a lot of people by this bullshit. Many people need something other than patching PHP.
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
https://github.com/Qbix/proxy
In what circumstances would you be unable to patch your PHP, but able to stand this proxy in front of it?
The one we're in right now, where we're waiting for vendors to rebuild the packages (I'm ass-blasted that the delay to 14:00 UTC wasn't for the vendors to build packages but seems to be a PR stunt?).
Apparently they didn't even use the time to prepare the docker images
Hi, your build is failing my friend.
You're right – need to fix the Cosmopolitan build in GitHub actions. On it!
UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.
> Just going to ship a Linux binary for now
Nobody should trust this.