If you have a PHP site with anything sensitive, you should probably turn it off until you've installed tomorrow's patch. Last month another project that quietly opened a PR with a patch saw exploit attempts less than 10 minutes after becoming public. With this level of severity and popularity, I would expect the PHP vulnerabilities will be re-discovered and put to use overnight.
There is already a POC that can compromise Wordpress going around. Assume threat actors are already exploiting this. Coordinated disclosure was handled incredibly badly.
On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.
Other than not offering Chainguard embargoed information in the future, they could've shipped the patch as soon as this happened.
As a side note, this is a great time to learn which sites are running PHP on the backend, if you didn't already know their stack. I work at DeviantArt, and we've been serving a "down for maintenance" page all morning.
Better be careful about the method of turning it off if you have hard-coded secrets in .php files, which is a real config pattern. It’s easy to end up with an HTTp server that serves the contents of the .php files as text.
Here's a (supposed) video of it in action: https://mastodon.social/@Viss/117475758985207443 Might not be a good idea to watch it if you have epilepsy, there are some annoying editing effects. I really appreciate the dancing anime girls, though!
Based on the breadth of targets presented, this probably doesn't require anything special from the web app. Exciting.
Kinda would've appreciated being able to read the text and not having everything obscured by effects and dancing children, I don't really know what it's trying to tell me
I'm not at all suggesting that the issue isn't serious, but it certainly seems like the usefulness of such an exploit will be significantly reduced if the environment is setup to host the PHP application with some basic security in place - i.e. the PHP process doesn't have write access to anything that can then be executed.
An RCE on your server isn't great, but you're doing something very wrong if the attacker can use the RCE to add executable content that's exposed.
Again - I'm not suggesting the issue isn't serious. I'm saying that there are well established steps to mitigate the damage area in the case such an attack is successful.
This feels kinda like XKCD 1200. Good thing the only thing the attacker has is read and write access to all sensitive user data in the database and all stored user files and the ability to make network requests and to modify the code sent to users' browsers, we would've been really hosed if it had the ability to edit files owned by root in the container!
Depends a bit. For something like a Wordpress blog, a database full of spam blog posts is a hell of a lot easier to clean up than a system with malware in every corner.
and to modify the code sent to users' browsers, we would've been really hosed if it had the ability to edit files owned by root in the container!
You've specifically glossed over a big part of what I said there, and honestly made me question what magic security people think "containers" provide them?
If your application - containerised or not, php or not - has the ability to write to files that are then loaded by the application on subsequent requests (i.e. the old "upload a php script to the user-uploads folder" trick), this RCE isn't your biggest concern.
Sure, having the ability to exfiltrate the Database or wipe it is bad. That's why I said
I'm not at all suggesting that the issue isn't serious
Sure, having the ability to make outgoing network requests is bad. That's why I said
I'm not at all suggesting that the issue isn't serious
The point specifically is that the parent comment shows it writing "pwned" to a text file.
Sure it could have copied some abstract PHP that evals a javascript blob that gets sent to clients and makes all visitors into bitcoins mining ponies.
But if the application is secured properly, the files the application itself can write to, are never executed by the application.
That is the point I was making. Thanks so much for going out of your way to miss it.
but it certainly seems like the usefulness of such an exploit will be significantly reduced if the environment is setup to host the PHP application with some basic security in place - i.e. the PHP process doesn't have write access to anything that can then be executed.
That's irrelevant. You RCE entirely without writable file system access and it's exactly as useful as without. PHP needs to read the files, and with that you will be able to exfiltrate any secret or data your PHP process will have access to which is a lot. You can also open a shell to your database and funnel out data.
Do you also know about every possible application that could be attacked using it? That's the point. If you don't know what the attacker will have access to (i.e. you don't know what the application has access to, because you don't know what the application is), how can you possibly know how useful it is, vs something where they have the ability to do more things?
because it's kind of irrelevant what the application is. the attacker is able to get the full ambient capability the php-executing process has. Including environment secrets. Sure, / is an in-memory ro-only. But the DB connector isn't.
It really doesn't matter, worst case you can still use it as botnet.
It's like saying, all these WordPress vulnerabilities have limited use because most WordPress sites don't deal with sensitive data/you don't generally know what they have access to. What?
Wordpress vulnerabilities are usually amplified because they're not installed by people who know what they're doing, so the specific things I talked about, aren't true.
If you don't know what the attacker will have access to
My comment only addressed the most narrow of cases in which PHP runs. That is PHP has access to its own files (that it needs to run them) and access to credentials to connect to a database (because why else do you run PHP). With this vulnerability to whatever PHP has access, anyone on the internet can have access. It could get significantly worse from there, but I focused on the most minimal set of circumstances.
Same. I eventually figured that there's nothing to look at during the effects except a timer as the stuff runs.
The process looks quite lengthy and in that case, maybe it takes many attempts to run (dozens of seconds for a local exploit may mean millions of attempts) which might be a mitigation, especially if a single PHP process serves few requests. If it's a remote RCE and a CVSS 9.2, there should be limits to the ease of exploitation.
(Still, I'm going to cut my nextcloud instance until I get the PHP update.)
Nice, thanks! I was going to do an awkward “play the video on my laptop and run Shazam on my phone” dance and you saved me from having my wife look at me strange, again. Thank you!
Note that there's apparent misinfo out there talking about a config change which allegedly makes this not exploitable. This is false according to Gina Banyard (PHP core developer): https://phpc.social/@Girgias/117476477429221001
The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.
Yep. This post is claiming it's in the session code, which makes sense. Probably also invalidates my prediction that a human wouldn't have figured out how to exploit it.
Edit: but apparently that post is wrong as the ini flag won't actually fix it.
Partially correct: It was not JIT, but it was exploitable by unauthenticated users.
Partially correct: there are php.ini flags to mitigate but they don't actually close the underlying issue.
Mostly correct: it was found using LLMs, unclear if a human could've found it. Maybe the fact that no one found it in so much time automatically falsifies that.
Some incorrect, non-technical details leaked about the CVEs, so
PHP moved up the announcement a day, then
One of the bug finders, Calif, mistakenly published their PoC video, then deleted it, but
The video gave just enough hints to LLMs to lead to new exploit attempts, though PHP sec team claimed they weren't functional
Finally, Chainguard provided new images with the fix 6 hours early, letting attackers study it while others were scrambling.
TBH, given the sheer scale, I don't see any realistic scenarios where 70% of the world's websites are updated before a single bad guy with an LLM makes an exploit. Responsible disclosure broke down, but I'm not sure how much difference a few hours would make to the long tail of vulnerable sites.
TBH, given the sheer scale, I don't see any realistic scenarios where 70% of the world's websites are updated before a single bad guy with an LLM makes an exploit. Responsible disclosure broke down, but I'm not sure how much difference a few hours would make to the long tail of vulnerable sites.
That's a good point. While I think Calif and Chainguard behaved badly (whether deliberate or not) it's probably time to reconsider the value of "coordinated disclosure" at all, at least when the group of stakeholders is this large..
7:30 AM UTC, and it looks like it’s been independently discovered/leaked some time ago (at least several hours). Holding the release for coordinated disclosure doesn’t seem to have worked at all.
No, a bug has been independently discovered. We don't know if it's the same bug. If it is, the people who discovered it don't understand it completely. PHP core developers are saying that the proposed config change (session.upload_progress.enabled = Off) doesn't resolve the issue and the only fix is to upgrade.
Going around on social media and claiming that it's the same bug as what will be receiving a patch today is dangerous and leaves people with a false sense of security. From what I can tell, the only workaround before you can patch your systems is to turn off PHP.
Ignoring the fact that this post is just terrible prose for a second, it's also wrong. It might be talking about a real bug, but the proposed config change doesn't fix the RCE that's being patched today.
I wonder if this is because someone was using LLMs to verify or originally discover the bug. In a talk by Greg KH I recently watched, he says LLMs demonstrably leak data to others, so projects can get hit with so-called "independently discovered" vulnerabilities in a short amount of time.
Security advisory: Critical remote code execution vulnerabilities, update 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.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php,
php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit
where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
Debian has a non-listed php update 8.4.27-1~deb13u1 from the security updates, but the CVEs themselves can't be found in the issue tracker, so no idea whether it's truly done or not.
A former PHP developer says they’ve looked at the patch and are worried that it’s going to be gappy—not because of a specific gap, but just because the approach requires finding a huge number of potential failures. https://social.noyu.me/@hikari/statuses/01M5FKSAZR531Y1PG1HHBCJ4YJ
It's wild to me that this is the fix. Why take the risk of having to find all those call sites just to keep the longjmp OOM handling working? Surely you'd just get rid of that longjmp and abort on OOM.
Apologies if this should've been folded into the existing thread, but I felt that much of that is already bloated with speculation and such already, whereas this post has the actual technical details behind the CVEs.
OK, someone in a position of trust leaking privileged information is hardly what I would call "officially releasing an exploit" but maybe we have different readings of the terms.
the discoverer reported it to php themselves, it was leaked from there. not sure how much more official you get than project management themselves. unless you mean the poc itself, which was only now just released as the embargo was lifted
If you can point me to a post, source commit, or other artifact connecting a person involved with the PHP foundation and the text or description of the CVE, I can accept that the presence of these security issues was presented officially by PHP.
That they would also release an active exploit, as implied by the comment by @pegasus at the start of this thread beggars belief.
Any idea how much an exploit like this would be worth on the black market? I'm kinda surprised that it got released through official channels first.
(my emphasis)
Again, this might just be us talking past each other. But implying that a well-established software project would officially release a malicious code artifact affecting their users before a fix borders on libel, in my opinion.
Your misunderstanding the original comment. The authors is not saying that an exploit was released by the php devs, they are saying that the bug disclosure was done "right" instead of being sold out to a 0-day vendor.
I wonder if this might still just be different readings of the original comment. I read it that ~pegasus meant he’s surprised that the goodies found it faster than the baddies - I agree it was a bit ambiguously worded, but given the number of people out there actively trying to find and exploit security holes for nefarious ends, it doesn’t seem that bleak to think we’re lucky the white hats got there first this time :-)
Disclaimer: I don't understand the timelines and/or the CVS disclosure process at all
It looks like this became widespread knowledge before PHP was actually able to ship a patch/fix.
Should something of this magnitude not be fed to the PHP security team first so a security release can coincide with the announcement to the wider public? Or was info just get leaked?
PHP was a 'fractal-of-bad design in 2012, see the infamous assay of the same name, and the corollary of that is that no matter what they improve, it's still fractally bad.
The fact that it became as common as it did is fascinating from an evolutionary perspective. It came with a low barrier of entry business model ('LAMP hosting'), and all it's warts didn't affect it's fitness in that landscape.
Well if that 2026 language still has vulnerabilities from 2004, I'm not sure I trust that it's many changes don't equate to collecting every vulnerability imaginable.
I mean, JS is also a deeply unserious language. And I mean that not as "eww script kiddies" but as "designed and implemented in 10 days, and it still shows 30 years later".
If memory serves, that article was (mostly?) about programming language design. A badly designed language might make it easier to write vulnerable code, but that's unrelated to the security of the runtime.
If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C's lack of memory safety, it's very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C's foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it's not C's problem, it's just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn't also running into these issues.
[OP] pushcx | 23 hours ago
If you have a PHP site with anything sensitive, you should probably turn it off until you've installed tomorrow's patch. Last month another project that quietly opened a PR with a patch saw exploit attempts less than 10 minutes after becoming public. With this level of severity and popularity, I would expect the PHP vulnerabilities will be re-discovered and put to use overnight.
david_chisnall | 11 hours ago
There is already a POC that can compromise Wordpress going around. Assume threat actors are already exploiting this. Coordinated disclosure was handled incredibly badly.
ChrisDenton | 6 hours ago
Somebody leaked. I'm not sure what can be done to handle that better other than not trusting them again?
hoistbypetard | 5 hours ago
From the php update:
Other than not offering Chainguard embargoed information in the future, they could've shipped the patch as soon as this happened.
david_chisnall | 6 hours ago
ChrisDenton | 3 hours ago
"As soon as possible" is doing some heavy lifting there. They did move the release forward (it was originally planned for Thursday).
kingmob | 5 hours ago
Two9A | 9 hours ago
As a side note, this is a great time to learn which sites are running PHP on the backend, if you didn't already know their stack. I work at DeviantArt, and we've been serving a "down for maintenance" page all morning.
oceanhaiyang | 7 hours ago
Hmm this makes me wonder about Mediawiki and Ghost!
ggpsv | 7 hours ago
Ghost is a Node.js app.
hsivonen | 8 hours ago
Better be careful about the method of turning it off if you have hard-coded secrets in .php files, which is a real config pattern. It’s easy to end up with an HTTp server that serves the contents of the .php files as text.
zesterer | 6 hours ago
Ah yes, fail-safe design
hoistbypetard | 5 hours ago
When you turn it off, deny access to php files in the server config.
kalkin | 11 hours ago
To hijack the top comment: Do not trust the supposed mitigations which are spread around, they might be completely bogus or a different thing at all.
dsr | 11 hours ago
Also: assume that anything stored on the machine running PHP might be accessible, not just what the PHP app is supposed to be accessing.
dzwdz | 22 hours ago
Here's a (supposed) video of it in action: https://mastodon.social/@Viss/117475758985207443 Might not be a good idea to watch it if you have epilepsy, there are some annoying editing effects. I really appreciate the dancing anime girls, though!
Based on the breadth of targets presented, this probably doesn't require anything special from the web app. Exciting.
mort | 12 hours ago
Kinda would've appreciated being able to read the text and not having everything obscured by effects and dancing children, I don't really know what it's trying to tell me
lemon | 12 hours ago
At the start of the video: right column: a browser open to a WordPress instance pointed at
/wp-content/uploads/pwned.txtshowing a 404.Left column: a terminal running the PoC exploit with this command:
Then, browser is refreshed and shows
pwned. That's the first 15 seconds.This is repeated for MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, WHMCS and a generic Apache server serving
index.php.stephenr | 12 hours ago
I'm not at all suggesting that the issue isn't serious, but it certainly seems like the usefulness of such an exploit will be significantly reduced if the environment is setup to host the PHP application with some basic security in place - i.e. the PHP process doesn't have write access to anything that can then be executed.
An RCE on your server isn't great, but you're doing something very wrong if the attacker can use the RCE to add executable content that's exposed.
Again - I'm not suggesting the issue isn't serious. I'm saying that there are well established steps to mitigate the damage area in the case such an attack is successful.
mort | 11 hours ago
This feels kinda like XKCD 1200. Good thing the only thing the attacker has is read and write access to all sensitive user data in the database and all stored user files and the ability to make network requests and to modify the code sent to users' browsers, we would've been really hosed if it had the ability to edit files owned by root in the container!
LeahNeukirchen | 10 hours ago
As if LPE wasn't a dime a dozen.
Gaelan | 9 hours ago
Depends a bit. For something like a Wordpress blog, a database full of spam blog posts is a hell of a lot easier to clean up than a system with malware in every corner.
stephenr | 8 hours ago
You've specifically glossed over a big part of what I said there, and honestly made me question what magic security people think "containers" provide them?
If your application - containerised or not, php or not - has the ability to write to files that are then loaded by the application on subsequent requests (i.e. the old "upload a php script to the user-uploads folder" trick), this RCE isn't your biggest concern.
Sure, having the ability to exfiltrate the Database or wipe it is bad. That's why I said
Sure, having the ability to make outgoing network requests is bad. That's why I said
The point specifically is that the parent comment shows it writing "pwned" to a text file.
Sure it could have copied some abstract PHP that evals a javascript blob that gets sent to clients and makes all visitors into bitcoins mining ponies.
But if the application is secured properly, the files the application itself can write to, are never executed by the application.
That is the point I was making. Thanks so much for going out of your way to miss it.
mitsuhiko | 11 hours ago
That's irrelevant. You RCE entirely without writable file system access and it's exactly as useful as without. PHP needs to read the files, and with that you will be able to exfiltrate any secret or data your PHP process will have access to which is a lot. You can also open a shell to your database and funnel out data.
stephenr | 7 hours ago
I'm sorry but I can't take anything else you say seriously.
You might as well start telling me the physical threats to my dog without knowing where I live, or that I don't have a dog.
mitsuhiko | 7 hours ago
I don’t know anything about your dog. I do know something about this RCE.
stephenr | 6 hours ago
Do you also know about every possible application that could be attacked using it? That's the point. If you don't know what the attacker will have access to (i.e. you don't know what the application has access to, because you don't know what the application is), how can you possibly know how useful it is, vs something where they have the ability to do more things?
kwas | 6 hours ago
because it's kind of irrelevant what the application is. the attacker is able to get the full ambient capability the php-executing process has. Including environment secrets. Sure, / is an in-memory
ro-only. But the DB connector isn't.untitaker | 5 hours ago
It really doesn't matter, worst case you can still use it as botnet.
It's like saying, all these WordPress vulnerabilities have limited use because most WordPress sites don't deal with sensitive data/you don't generally know what they have access to. What?
stephenr | 4 hours ago
Wordpress vulnerabilities are usually amplified because they're not installed by people who know what they're doing, so the specific things I talked about, aren't true.
mitsuhiko | 6 hours ago
My comment only addressed the most narrow of cases in which PHP runs. That is PHP has access to its own files (that it needs to run them) and access to credentials to connect to a database (because why else do you run PHP). With this vulnerability to whatever PHP has access, anyone on the internet can have access. It could get significantly worse from there, but I focused on the most minimal set of circumstances.
kwas | 11 hours ago
even shelling out to imagemagick is opening up this hole.
adrien | 12 hours ago
Same. I eventually figured that there's nothing to look at during the effects except a timer as the stuff runs.
The process looks quite lengthy and in that case, maybe it takes many attempts to run (dozens of seconds for a local exploit may mean millions of attempts) which might be a mitigation, especially if a single PHP process serves few requests. If it's a remote RCE and a CVSS 9.2, there should be limits to the ease of exploitation.
(Still, I'm going to cut my nextcloud instance until I get the PHP update.)
tonyarkles | 19 hours ago
What a banger of a track too!
quad | 16 hours ago
High Forever (Marlon Hoffstadt Remix). Damn, Edgerunners II soundtrack making the rounds at pace!
tonyarkles | 15 hours ago
Nice, thanks! I was going to do an awkward “play the video on my laptop and run Shazam on my phone” dance and you saved me from having my wife look at me strange, again. Thank you!
kwas | 14 hours ago
nota bene, if you use a Mac it has an built in Shazam. I've put mine in the ControlCenter.
citbl | 11 hours ago
alper | 11 hours ago
thombles | 14 hours ago
I do hope the brave souls who run their personal nextcloud on the open internet are paying attention.
mort | 12 hours ago
Note that there's apparent misinfo out there talking about a config change which allegedly makes this not exploitable. This is false according to Gina Banyard (PHP core developer): https://phpc.social/@Girgias/117476477429221001
legoktm | 22 hours ago
I shut down all my web-facing (non-critical) PHP apps in anticipation.
Some predictions (pure guesses/speculation, I don't have any insider info):
riking | 16 hours ago
Partial details have leaked: it's in the handling of POST requests before any PHP code runs.
fourfourthree | 21 hours ago
It's supposedly vulnerable back to 5.x, so I think that rules out the JIT.
legoktm | 18 hours ago
Yep. This post is claiming it's in the session code, which makes sense. Probably also invalidates my prediction that a human wouldn't have figured out how to exploit it.
Edit: but apparently that post is wrong as the ini flag won't actually fix it.
amycodes | 14 hours ago
https://chaos.social/@christopherkunz/117477368766737839 that poc may also have been wrong to start with, someone couldn't repro
legoktm | 6 hours ago
So:
loldot | 15 hours ago
jbauer | 6 hours ago
Additional statement from The PHP Foundation following the release of the Security Advisory: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
Worth a read imo
kingmob | 5 hours ago
For those wondering how the coordinated disclosure of php2shell broke down in the last few days:
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/#leak-and-disrupted-disclosure
Timeline:
TBH, given the sheer scale, I don't see any realistic scenarios where 70% of the world's websites are updated before a single bad guy with an LLM makes an exploit. Responsible disclosure broke down, but I'm not sure how much difference a few hours would make to the long tail of vulnerable sites.
hoistbypetard | 4 hours ago
That's a good point. While I think Calif and Chainguard behaved badly (whether deliberate or not) it's probably time to reconsider the value of "coordinated disclosure" at all, at least when the group of stakeholders is this large..
Two9A | 8 hours ago
As a corollary, the patches are now out and CVEs have been issued: https://www.php.net/archive/2026.php#2026-10-21-5
Released twenty minutes early, no less.
hyperpape | 14 hours ago
7:30 AM UTC, and it looks like it’s been independently discovered/leaked some time ago (at least several hours). Holding the release for coordinated disclosure doesn’t seem to have worked at all.
Haven’t seen a thorough explanation of the bug.
mort | 12 hours ago
No, a bug has been independently discovered. We don't know if it's the same bug. If it is, the people who discovered it don't understand it completely. PHP core developers are saying that the proposed config change (
session.upload_progress.enabled = Off) doesn't resolve the issue and the only fix is to upgrade.Going around on social media and claiming that it's the same bug as what will be receiving a patch today is dangerous and leaves people with a false sense of security. From what I can tell, the only workaround before you can patch your systems is to turn off PHP.
moltonel | 12 hours ago
https://jackalsyn.com/posts/php-up-2026.html
gerikson | 12 hours ago
See comment above: https://lobste.rs/c/qqk3t0
Everything is moving too fast. Time to batten down the hatches, have a pint, and wait for it all to blow over.
mort | 12 hours ago
Ignoring the fact that this post is just terrible prose for a second, it's also wrong. It might be talking about a real bug, but the proposed config change doesn't fix the RCE that's being patched today.
In short, it's AI generated misinfo.
sjamaan | 12 hours ago
I wonder if this is because someone was using LLMs to verify or originally discover the bug. In a talk by Greg KH I recently watched, he says LLMs demonstrably leak data to others, so projects can get hit with so-called "independently discovered" vulnerabilities in a short amount of time.
cadey | 10 hours ago
I wasn't able to get that PoC working, even with an excessively wrong setup
cln | 12 hours ago
Ouch, it's uncanny to see an AI-generated exploit page with an AI-generated write-up.
gerikson | 8 hours ago
The PHP project page now has links to updated versions
https://www.php.net/archive/2026.php#2026-10-21-5
Security advisory: Critical remote code execution vulnerabilities, update 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.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
amycodes | 8 hours ago
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
direct links for those
proctrap | 8 hours ago
Debian has a non-listed php update 8.4.27-1~deb13u1 from the security updates, but the CVEs themselves can't be found in the issue tracker, so no idea whether it's truly done or not.
calvin | 7 hours ago
PHP 8.4.27 includes the fix for these CVEs, yes. (Speaking as PHP 8.4 RM, I just don't have a hat for that.)
proctrap | 7 hours ago
thank you for confirming
nicoco | 7 hours ago
Interesting, I assumed that this
php-8.4in myapt upgradewas it. I should more careful.proctrap | 7 hours ago
seems fine?
nicoco | 5 hours ago
Ho cool, not more nextcloud downtime for me then. :)
Thanks.
proctrap | 5 hours ago
Maybe, maybe not :D https://fedi.katze.sh/@elise/117478797599905586
luke8086 | 12 hours ago
This has a chance to be the most impactful vulnerability I've seen.
At least Cloudflare added mitigations for the known exploits:
Yogurt | 6 hours ago
The fix for anyone that wants to see the code
https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065
gspr | 3 hours ago
Auch! That's an enormous amount of changes needed! Sounds like good chances that some corner case will have been forgotten about :(
hyperpape | 5 hours ago
A former PHP developer says they’ve looked at the patch and are worried that it’s going to be gappy—not because of a specific gap, but just because the approach requires finding a huge number of potential failures. https://social.noyu.me/@hikari/statuses/01M5FKSAZR531Y1PG1HHBCJ4YJ
muvlon | 2 hours ago
It's wild to me that this is the fix. Why take the risk of having to find all those call sites just to keep the longjmp OOM handling working? Surely you'd just get rid of that longjmp and abort on OOM.
gerikson | 10 hours ago
Multiple large sites in the Netherlands taken offline, including the national e-ID system:
https://nos.nl/artikel/2636055-websites-van-overheid-en-in-onderwijs-offline-vanwege-lek-risico-op-hacks
refi64 | 7 hours ago
Apologies if this should've been folded into the existing thread, but I felt that much of that is already bloated with speculation and such already, whereas this post has the actual technical details behind the CVEs.
amycodes | 6 hours ago
https://lobste.rs/c/dkmxpk could you add this too? it has a lot of the background from a release perspective which is worth showing i feel
pja | 12 hours ago
This one looks like a doozy. Safest to just take any PHP applications offline until the patches drop.
thisalex | 11 hours ago
Vincent Schmalbach tells that 2 things need to be done:
php_admin_flag[session.upload_progress.enabled] = offaiono | 7 hours ago
Is taking the Nextcloud into maintenance mode enough to mitigate it until the fix arrives?
ggpsv | 7 hours ago
Maintenance mode is served by PHP too, so no.
pegasus | 9 hours ago
Any idea how much an exploit like this would be worth on the black market? I'm kinda surprised that it got released through official channels first.
gerikson | 9 hours ago
There's so much misinformation flying around, so I have to ask - what official channels released an exploit?
amycodes | 9 hours ago
the php foundation was informed, and several large enterprises got advance notice. one of those people leaked it to HN and it exploded from there
greg_kennedy | 6 hours ago
The official post on PHP foundation blog (https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) indicates that Calif itself accidentally leaked details ahead of time through the "anime girl dancing to EDM while sites are pwned in the background" video being made public before embargo end
gerikson | 9 hours ago
OK, someone in a position of trust leaking privileged information is hardly what I would call "officially releasing an exploit" but maybe we have different readings of the terms.
amycodes | 8 hours ago
the discoverer reported it to php themselves, it was leaked from there. not sure how much more official you get than project management themselves. unless you mean the poc itself, which was only now just released as the embargo was lifted
gerikson | 7 hours ago
If you can point me to a post, source commit, or other artifact connecting a person involved with the PHP foundation and the text or description of the CVE, I can accept that the presence of these security issues was presented officially by PHP.
That they would also release an active exploit, as implied by the comment by @pegasus at the start of this thread beggars belief.
(my emphasis)
Again, this might just be us talking past each other. But implying that a well-established software project would officially release a malicious code artifact affecting their users before a fix borders on libel, in my opinion.
Edit to wrap this up and for posterity:
https://lobste.rs/c/bmgjok
krtab | 7 hours ago
Your misunderstanding the original comment. The authors is not saying that an exploit was released by the php devs, they are saying that the bug disclosure was done "right" instead of being sold out to a 0-day vendor.
gerikson | 3 hours ago
It must be depressing to have a view of humanity that sees that as an exception rather than the rule.
igorclark | 3 hours ago
I wonder if this might still just be different readings of the original comment. I read it that ~pegasus meant he’s surprised that the goodies found it faster than the baddies - I agree it was a bit ambiguously worded, but given the number of people out there actively trying to find and exploit security holes for nefarious ends, it doesn’t seem that bleak to think we’re lucky the white hats got there first this time :-)
pegasus | 2 hours ago
Yes, that was my observation. Will try to be more precise with words next time.
amycodes | 7 hours ago
right, yes, it wasn't the php foundation who found the bug, if that was your question. the two advisories are published on GH now though
ubernostrum | 3 hours ago
Probably at least 4.
Jackevansevo | 5 hours ago
Disclaimer: I don't understand the timelines and/or the CVS disclosure process at all
It looks like this became widespread knowledge before PHP was actually able to ship a patch/fix.
Should something of this magnitude not be fed to the PHP security team first so a security release can coincide with the announcement to the wider public? Or was info just get leaked?
mro | 8 hours ago
brittle foundations. Ran into an unrelated example ten years ago https://blog.mro.name/2015/03/why-php-is-utterly-broken/
alper | 11 hours ago
The time to be deploying PHP applications in production is long over. At this point it should be considered malpractice.
proctrap | 9 hours ago
WTF so if we find a similar bug in ruby then we ditch ruby, same for JS ?
I hope you never used or intend to use moodle, nextcloud, wikipedia, a forum, mailcow, mailchimp...
TyberiusPrime | 8 hours ago
PHP was a 'fractal-of-bad design in 2012, see the infamous assay of the same name, and the corollary of that is that no matter what they improve, it's still fractally bad.
The fact that it became as common as it did is fascinating from an evolutionary perspective. It came with a low barrier of entry business model ('LAMP hosting'), and all it's warts didn't affect it's fitness in that landscape.
proctrap | 8 hours ago
I know it's cool to quote talks from 2012 about a language in 2026 but PHP has changed a lot.
hjvt | 7 hours ago
Well if that 2026 language still has vulnerabilities from 2004, I'm not sure I trust that it's many changes don't equate to collecting every vulnerability imaginable.
vetch | 5 hours ago
I mean OpenBSD patched a 27 year old bug this year so…
bbrown | 2 hours ago
Using it is malpractice then, sayeth alper.
greg_kennedy | 5 hours ago
Having sufficiently put PHP in its place for being "old" and "uncool", it's now time to take a big sip of coffee and check out what that trendy Node.js blog is posting about. (https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)
hjvt | 3 hours ago
I mean, JS is also a deeply unserious language. And I mean that not as "eww script kiddies" but as "designed and implemented in 10 days, and it still shows 30 years later".
dzwdz | 6 hours ago
If memory serves, that article was (mostly?) about programming language design. A badly designed language might make it easier to write vulnerable code, but that's unrelated to the security of the runtime.
sjamaan | 8 hours ago
PHP has a horrible security track record. This particular bug isn't the reason to claim that, rather its history should be.
thisalex | 8 hours ago
Some of the older PHP frameworks/apps do have horrible security record. PHP itself: not really, quite on par with everyone else.
muvlon | 2 hours ago
If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C's lack of memory safety, it's very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C's foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it's not C's problem, it's just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn't also running into these issues.
lollipopman | 2 hours ago
For those with more C knowledge than myself, would running PHP compiled with Fil-C have prevented these exploits?