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.
If you see what a massively sweeping change this patch is (as per Yogurt's comment), I understand they wanted to take a few more hours to ensure there are no regressions.
And if that's the case, I'm glad they were doing more testing. Their earlier messaging made it sound like it was done and had been given to various distro packagers, and "reserved the right" to release it early if it leaked or if exploits were seen in the wild.
Having looked at the fix, I suspect that the actual fix will come in pieces over the next year.
The fix for the OOM issue is not to do the sensible thing (kill the process and rely on the process manager to restart), it’s to scatter hundreds of explicit error handling paths that try to do graceful cleanup across the entire codebase. This is exactly the approach that has led to many other vulnerabilities in other projects over the years.
With PHP applications I've found most pre-built Container images to be sorely lacking, to the point that I'd rather avoid the "official" container images and provision the service in a Debian VM using php-fpm and nginx. Otherwise, write my own containerfile using stock Debian images. During this PHP incident the stock php: images in Docker hub lagged behind distros like Debian for a couple of hours.
You can run WordPress in a container without using the official image or mod_php. This is not an indictment of WordPress itself (despite it's well-earned notoriety) but of how they decided to containerize it.
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.
This is why I always arrange my PHP scripts such that they include the bulk of the code from www/../php, i.e. a directory that lies outside the web root. A long time ago, as a teenager, I once stole credentials precisely through this kind of exploit, PHP was not running and raw PHP was served as plaintext, so you could navigate through the scripts in the web root to obtain credentials.
Most frameworks like Laravel will push you to this style, i.e. set document root to public/ which just has a router in index.php, and everything in sibling directories for i.e. code, config, etc.
I was investigating a site last year which had, among others, a problem like this:
There was an SQL injection bug (my initial finding)
They had debugging enabled (d'oh!) so it showed file paths in stack traces
One file was named class.Something.inc. I was able to download that file because it wasn't passed through the PHP engine.
Said file contained SMTP credentials in plaintext for gmail accounts where passport scans got sent (although I didn't need that to view them, they were accessible from the server through the aforementioned SQL injection bug)
Pretty terrible across the board. I tried to report this but didn't get anywhere (no official security contacts etc, so I mailed random addresses I could find). After mailing a CERT, who created a ticket and told me I'd be updated, it was silently fixed by getting rid of the entire PHP app. I never heard back. I still don't know if it was the CERT that got through to them, or if they saw my mail to them, or if they saw my attempts in the logs.
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!
What about it though? I can see that it's a large number of lines, but I'm not going to pretend I know how to reason about the changes in that diff. Is there something in particular?
I did. "Lots of LoC changed" is a poor metric to judge this. A vast majority (like, 90%) of the changes are test cases and don't affect the runtime itself. The others appear to do early-bailout / assert-style checks at the top of functions for very rare, unusual paths.
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.
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..
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.
Sure, and they can take their time and think how to bring that feature back safely. But we're talking about a very urgent security fix here. Lots of people are even entirely shutting down all their PHP apps.
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.
I believe that humans have seen the issue but never followed through because it's such a daunting thing to fix all memory allocation in the entire codebase.
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.
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.
One thing I’ve been thinking about a lot over the years is how much context we throw away when we describe something as easy or hard without qualification. In a way, there’s no such thing as “easy” or “hard”, only “easy to (use/understand/do the basics/master)” or “easy for (someone with certain qualities)”. We just leave out or ignore those details, and hope people get the gist of what we’re saying. Most of the time it’s good enough, but often it causes confusion.
I do appreciate the observation that LLMs will accelerate the flood of bad POCs and misinformation after each vulnerability is announced.
However, It seems like this post conflates how easy it is to write an exploit from scratch with how easy it is for someone to use the exploit once they’ve developed it.
Imagine an exploit that requires a very clever person to spend two days developing it, but then is usable against any PHP server with little to no modification. We really wouldn’t be reassured that it took two days to develop the first exploit.
I don’t think this post gives any real evidence about exploitability. It just shows that many people have failed to develop an exploit. But we care about the ones who’ve succeeded.
Either way, the upside is that organizations are starting to take security more seriously and actually patching and taking servers offline until there is a patch. I think that's a good thing. Of course the risk is that eventually it causes CVE fatigue and possibly a backlash where admins are throwing their hands up saying there's nothing to be done anyway.
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.
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.
The same people who designed the language designed the runtime. That should tell you enough. Also, just look at the damn patch for these bugs already. Clearly that is terrible design. And people are already realizing they can't possibly have caught all the instances of this bug, so there's plenty of chance we'll be seeing more of these, unless they now take the time to overhaul their memory allocation and OOM behaviour to a well-designed approach.
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".
I was talking about their track record and approach to engineering. It's still the same code base even if it evolved over those 10 years. And the current bug and approach to "fixing it" shows that. Read the other comments, I'm not the only stating that the entire OOM recovery attempt and reuse of memory is a terrible idea.
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.
At a glance, I think the answer is yes. This is exactly the kind of thing Fil-C is supposed to prevent. That being said, I don't know whether PHP even works on Fil-C yet. It's not in https://fil-c.org/programs_that_work, but that doesn't have to mean anything.
Yeah. But the bugs have some interesting aspects that aren’t related to memory safety. Part of the problem is that php’s main data structure is reused across successive requests, instead of being allocated and initialized from scratch each time; this allows corruption caused in one request to be exploited in the next. Another part of the problem is exception (un)safety, which allows a data structure’s invariants to be broken by a request that triggers an OOM longjmp. I can imagine that this combination could lead to shenanigans even in a memory-safe language, though I expect it would be much harder to exploit and I doubt it would be worse than denial-of-service or an information leak.
[OP] pushcx | 2 days 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 | 2 days 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 | 2 days ago
Somebody leaked. I'm not sure what can be done to handle that better other than not trusting them again?
hoistbypetard | 2 days 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.
sjamaan | a day ago
If you see what a massively sweeping change this patch is (as per Yogurt's comment), I understand they wanted to take a few more hours to ensure there are no regressions.
hoistbypetard | a day ago
And if that's the case, I'm glad they were doing more testing. Their earlier messaging made it sound like it was done and had been given to various distro packagers, and "reserved the right" to release it early if it leaked or if exploits were seen in the wild.
david_chisnall | 2 days ago
ChrisDenton | 2 days ago
"As soon as possible" is doing some heavy lifting there. They did move the release forward (it was originally planned for Thursday).
david_chisnall | a day ago
Having looked at the fix, I suspect that the actual fix will come in pieces over the next year.
The fix for the OOM issue is not to do the sensible thing (kill the process and rely on the process manager to restart), it’s to scatter hundreds of explicit error handling paths that try to do graceful cleanup across the entire codebase. This is exactly the approach that has led to many other vulnerabilities in other projects over the years.
calvin | a day ago
This approach wouldn't work for embedded/threaded SAPIs where they would kill much more than a PHP worker, i.e. non-threaded Apache MPMs with mod_php.
david_chisnall | a day ago
Does anyone still do
mod_phpanymore? It's such a security nightmare it hasn't been recommended for at least 20 years.cmcaine | a day ago
The default docker images for e.g. wordpress use mod_php.
ggpsv | a day ago
With PHP applications I've found most pre-built Container images to be sorely lacking, to the point that I'd rather avoid the "official" container images and provision the service in a Debian VM using php-fpm and nginx. Otherwise, write my own containerfile using stock Debian images. During this PHP incident the stock
php:images in Docker hub lagged behind distros like Debian for a couple of hours.david_chisnall | a day ago
Well that's horrifying to learn. Thank you for giving me my 4123th reason to avoid WordPress.
ggpsv | a day ago
You can run WordPress in a container without using the official image or
mod_php. This is not an indictment of WordPress itself (despite it's well-earned notoriety) but of how they decided to containerize it.jtdowney | a day ago
Yep, anything that uses the Docker PHP image with the Apache variant uses mod_php, including the default Nextcloud image.
kingmob | 2 days ago
Two9A | 2 days 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 | 2 days ago
Hmm this makes me wonder about Mediawiki and Ghost!
ggpsv | 2 days ago
Ghost is a Node.js app.
hsivonen | 2 days 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 | 2 days ago
Ah yes, fail-safe design
BenjaminRi | a day ago
This is why I always arrange my PHP scripts such that they include the bulk of the code from
www/../php, i.e. a directory that lies outside the web root. A long time ago, as a teenager, I once stole credentials precisely through this kind of exploit, PHP was not running and raw PHP was served as plaintext, so you could navigate through the scripts in the web root to obtain credentials.calvin | a day ago
Most frameworks like Laravel will push you to this style, i.e. set document root to
public/which just has a router inindex.php, and everything in sibling directories for i.e. code, config, etc.sjamaan | a day ago
I was investigating a site last year which had, among others, a problem like this:
class.Something.inc. I was able to download that file because it wasn't passed through the PHP engine.Pretty terrible across the board. I tried to report this but didn't get anywhere (no official security contacts etc, so I mailed random addresses I could find). After mailing a CERT, who created a ticket and told me I'd be updated, it was silently fixed by getting rid of the entire PHP app. I never heard back. I still don't know if it was the CERT that got through to them, or if they saw my mail to them, or if they saw my attempts in the logs.
hoistbypetard | 2 days ago
When you turn it off, deny access to php files in the server config.
kalkin | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
As if LPE wasn't a dime a dozen.
Gaelan | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
I don’t know anything about your dog. I do know something about this RCE.
stephenr | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
even shelling out to imagemagick is opening up this hole.
adrien | 2 days 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 | 2 days ago
What a banger of a track too!
quad | 2 days ago
High Forever (Marlon Hoffstadt Remix). Damn, Edgerunners II soundtrack making the rounds at pace!
tonyarkles | 2 days 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 | 2 days ago
nota bene, if you use a Mac it has an built in Shazam. I've put mine in the ControlCenter.
citbl | 2 days ago
alper | 2 days ago
thombles | 2 days ago
I do hope the brave souls who run their personal nextcloud on the open internet are paying attention.
Yogurt | 2 days ago
The fix for anyone that wants to see the code
https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065
riking | 2 days ago
It's an overhaul of all memory allocation in the entire codebase
gspr | 2 days ago
Auch! That's an enormous amount of changes needed! Sounds like good chances that some corner case will have been forgotten about :(
motet-a | a day ago
Wow. This is… frightening…
citbl | a day ago
It will be interesting to see the benchmarks of this new version of PHP against the vulnerable ones.
Yogurt | a day ago
you think there'll be a meaningful difference? I could certainly see it, but I'm not sure I'd expect it
citbl | a day ago
well yeah check the changes it's quite big.
Yogurt | a day ago
What about it though? I can see that it's a large number of lines, but I'm not going to pretend I know how to reason about the changes in that diff. Is there something in particular?
greg_kennedy | a day ago
I did. "Lots of LoC changed" is a poor metric to judge this. A vast majority (like, 90%) of the changes are test cases and don't affect the runtime itself. The others appear to do early-bailout / assert-style checks at the top of functions for very rare, unusual paths.
I doubt it will be much, if any, performance hit.
mort | 2 days 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
kingmob | 2 days 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 | 2 days 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..
jbauer | 2 days 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
hyperpape | 2 days 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 days 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.
riking | 2 days ago
Handling and recovering from OOM conditions is one of the primary "moat features" of PHP that distinguish it from other programming languages.
muvlon | 2 days ago
Sure, and they can take their time and think how to bring that feature back safely. But we're talking about a very urgent security fix here. Lots of people are even entirely shutting down all their PHP apps.
legoktm | 2 days 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 | 2 days ago
Partial details have leaked: it's in the handling of POST requests before any PHP code runs.
fourfourthree | 2 days ago
It's supposedly vulnerable back to 5.x, so I think that rules out the JIT.
legoktm | 2 days 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 | 2 days ago
https://chaos.social/@christopherkunz/117477368766737839 that poc may also have been wrong to start with, someone couldn't repro
legoktm | 2 days ago
So:
riking | 2 days ago
I believe that humans have seen the issue but never followed through because it's such a daunting thing to fix all memory allocation in the entire codebase.
loldot | 2 days ago
hyperpape | 2 days 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 | 2 days 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 | 2 days ago
https://jackalsyn.com/posts/php-up-2026.html
gerikson | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
I wasn't able to get that PoC working, even with an excessively wrong setup
cln | 2 days ago
Ouch, it's uncanny to see an AI-generated exploit page with an AI-generated write-up.
Two9A | 2 days 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.
gerikson | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
thank you for confirming
nicoco | 2 days ago
Interesting, I assumed that this
php-8.4in myapt upgradewas it. I should more careful.proctrap | 2 days ago
seems fine?
nicoco | 2 days ago
Ho cool, not more nextcloud downtime for me then. :)
Thanks.
proctrap | 2 days ago
Maybe, maybe not :D https://fedi.katze.sh/@elise/117478797599905586
cinemast | a day ago
That post reads to me there will be a round II. I will keep my php sites down a little longer I guess.
gerikson | 2 days 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 | 2 days 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 | 2 days 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
luke8086 | 2 days ago
This has a chance to be the most impactful vulnerability I've seen.
At least Cloudflare added mitigations for the known exploits:
hyperpape | a day ago
One thing I’ve been thinking about a lot over the years is how much context we throw away when we describe something as easy or hard without qualification. In a way, there’s no such thing as “easy” or “hard”, only “easy to (use/understand/do the basics/master)” or “easy for (someone with certain qualities)”. We just leave out or ignore those details, and hope people get the gist of what we’re saying. Most of the time it’s good enough, but often it causes confusion.
I do appreciate the observation that LLMs will accelerate the flood of bad POCs and misinformation after each vulnerability is announced.
However, It seems like this post conflates how easy it is to write an exploit from scratch with how easy it is for someone to use the exploit once they’ve developed it.
Imagine an exploit that requires a very clever person to spend two days developing it, but then is usable against any PHP server with little to no modification. We really wouldn’t be reassured that it took two days to develop the first exploit.
I don’t think this post gives any real evidence about exploitability. It just shows that many people have failed to develop an exploit. But we care about the ones who’ve succeeded.
sjamaan | a day ago
Either way, the upside is that organizations are starting to take security more seriously and actually patching and taking servers offline until there is a patch. I think that's a good thing. Of course the risk is that eventually it causes CVE fatigue and possibly a backlash where admins are throwing their hands up saying there's nothing to be done anyway.
pja | 2 days ago
This one looks like a doozy. Safest to just take any PHP applications offline until the patches drop.
thisalex | 2 days ago
Vincent Schmalbach tells that 2 things need to be done:
php_admin_flag[session.upload_progress.enabled] = offaiono | 2 days ago
Is taking the Nextcloud into maintenance mode enough to mitigate it until the fix arrives?
ggpsv | 2 days ago
Maintenance mode is served by PHP too, so no.
jbauer | a day ago
Gaelan | a day ago
Yeah, this squares with my impression that I haven’t really read about any successful exploits. Has anyone heard of one?
pegasus | 2 days 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 | 2 days ago
There's so much misinformation flying around, so I have to ask - what official channels released an exploit?
amycodes | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days 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 | 2 days ago
It must be depressing to have a view of humanity that sees that as an exception rather than the rule.
igorclark | 2 days 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 days ago
Yes, that was my observation. Will try to be more precise with words next time.
gerikson | a day ago
Thanks, sorry if I came off as overly critical.
amycodes | 2 days 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 | 2 days ago
Probably at least 4.
Jackevansevo | 2 days 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?
alper | 2 days ago
The time to be deploying PHP applications in production is long over. At this point it should be considered malpractice.
proctrap | 2 days 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 | 2 days 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.
dzwdz | 2 days 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 | a day ago
The same people who designed the language designed the runtime. That should tell you enough. Also, just look at the damn patch for these bugs already. Clearly that is terrible design. And people are already realizing they can't possibly have caught all the instances of this bug, so there's plenty of chance we'll be seeing more of these, unless they now take the time to overhaul their memory allocation and OOM behaviour to a well-designed approach.
proctrap | 2 days ago
I know it's cool to quote talks from 2012 about a language in 2026 but PHP has changed a lot.
hjvt | 2 days 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 | 2 days ago
I mean OpenBSD patched a 27 year old bug this year so…
bbrown | 2 days ago
Using it is malpractice then, sayeth alper.
hoistbypetard | 2 days ago
They were banned about 7 hours prior to your comment. It seems rude, IMO, to continue putting words into their mouth after that.
greg_kennedy | 2 days 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 | 2 days 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".
greg_kennedy | a day ago
Yeah, I suppose I walked right into that one.
sjamaan | 2 days ago
PHP has a horrible security track record. This particular bug isn't the reason to claim that, rather its history should be.
thisalex | 2 days ago
Some of the older PHP frameworks/apps do have horrible security record. PHP itself: not really, quite on par with everyone else.
sjamaan | a day ago
cough cough
magic_quotes_gpccough coughregister_globalscough coughthisalex | a day ago
Those are relics of the past. Removed for more than 10 years
sjamaan | a day ago
I was talking about their track record and approach to engineering. It's still the same code base even if it evolved over those 10 years. And the current bug and approach to "fixing it" shows that. Read the other comments, I'm not the only stating that the entire OOM recovery attempt and reuse of memory is a terrible idea.
muvlon | 2 days 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 days ago
For those with more C knowledge than myself, would running PHP compiled with Fil-C have prevented these exploits?
muvlon | 2 days ago
At a glance, I think the answer is yes. This is exactly the kind of thing Fil-C is supposed to prevent. That being said, I don't know whether PHP even works on Fil-C yet. It's not in https://fil-c.org/programs_that_work, but that doesn't have to mean anything.
fanf | 2 days ago
Yeah. But the bugs have some interesting aspects that aren’t related to memory safety. Part of the problem is that php’s main data structure is reused across successive requests, instead of being allocated and initialized from scratch each time; this allows corruption caused in one request to be exploited in the next. Another part of the problem is exception (un)safety, which allows a data structure’s invariants to be broken by a request that triggers an OOM longjmp. I can imagine that this combination could lead to shenanigans even in a memory-safe language, though I expect it would be much harder to exploit and I doubt it would be worse than denial-of-service or an information leak.
lollipopman | a day ago
Looks like they just ported it? https://github.com/pizlonator/fil-c/pull/338
kwas | 2 days ago
not precisely that one but the problem has been known for over 6 years. https://bugs.php.net/bug.php?id=78876 https://gist.github.com/cmb69/384d5f5bb6b2de834877348dcdbe3282
mro | 2 days ago
brittle foundations. Ran into an unrelated example ten years ago https://blog.mro.name/2015/03/why-php-is-utterly-broken/