The demo video has been going around Twitter today and apparently the proof of concept is privately being shared around too. The video shows pasting something in the URL and then gaining a shell on the server. It looks completely catastrophic.
I think the best course of action is to just shut your server down before the patch goes live and then bring it back after you have patched.
This is gonna rinse so many LAMP WordPress installs where the PHP version is either not getting a patch or the hosting is managed by the user via a contractor or the hosting is managed by a company with a fleet of custom servers etc etc.
We almost need some bot that logs in to every vulnerable PHP server and turns it off to prevent it being properly exploited before the server admin updates it..
Good advice if you're not using the default PHP session settings, but using default settings this means sessions can't be created. At best, that means no-one can log-in. At worst, it completely breaks the site (for those that depend on sessions even for unauthenticated users).
"How to make your site cost unlimited money and have terrible performance". People did this in the Web 1.0 days on occasion and it leads to all kinds of problems for any site with any kind of traffic.
>Or you make an exception for them.
Useless. All you need to do at that point is chain a priv-esc to your existing exploit and you get root.
Paying a ransomware attack tomorrow is very much better, than not having critical medical data for the emergency right now. Of course not having a public facing medical database based on PHP, would be even better, but that might not be a decision that they are able to make right now.
This is probably possible, there are github repos of extensions you can build for almost every distro and php version. You could probably pre-build most and then just do a background php extension load and restart.
ha! Who knew ignoring critical updates and continuing to run deprecated software while kicking the can down the road while focusing solely on building new features would turn out to be the best security policy after all.
That was how a cluster of Java servers at a former employer avoided the Log4j vulnerability. Though I think they'd be on at least PHP 5 by now (maybe even PHP 7!), so they can't dodge two bullets.
The URL is to show the effects of the exploit. The person's running a python script that runs the exploit and then makes the PHP installation execute an arbitrary shell command. The proof of concept involves writing "pwned" to a publicly accessible location on the web server, then they refresh the browser pointing at the URL to show it's been written.
There are some vulns that warrant a pre-release announcement (in the Drupal community, this happened for a few of the more serious fixes). And prior to the public pre-announcement, there is often informal coordination between some of the larger hosting providers or giant companies who can help roll out the patch more quickly.
Apparently, any PHP server that accepts a POST request is vulnerable to arbitrary code execution on the host (from the FPM user?) with no defense. This is DEFCON 1 of internet security: 70% of all websites are currently vulnerable until 14:00 UTC tomorrow with zero escape hatch other than blocking traffic.
The proof of concept works against any PHP server (5 and up) running in the default configuration, leading directly to RCE without authentication. The PoC out there can be defeated by disabling multi part uploads.
The PoC also requires a known binary to exploit so custom PHP builds may be safe if you're lucky, but this seems to be an extremely bad one.
If the rumors for these exploits being shared on Twitter are correct this is going to be a nightmare. I wouldn't be surprised if VPS hosts step in to mitigate it somehow since so many cheap/unmaintained LAMP installs are running on those servers.
I don't know if people understand that this actually lowers their reputation, instead of increasing it. Putting so important text as AI slop. Maybe it is not so important, if not worth of modifying themselves.
Yes. Bad themes have been a staple of the Internet ever since it got mainstream, remember <marquee> and <blink>. I'm used to that (although as I said the low contrast is making things extra annoying).
But I'm reading a website for getting information, not LLM fluff.
The exploit is already out. Yeah this looks like it's going to go on history as the worst vulnerability ever. And now with LLMs you'll likely see tens of thousands of agents hacking any php website out there within hours.
Yup, I'm seeing several legit people on X claiming to have seen or found the exploit. Some say that: turning session.upload_progress.enabled off and setting file_uploads = Off will mitigate. But others are claiming that those steps are not enough and "Upload progress can serialize before basic RINT clears BG(serialize)". So, I'm taking no chances and taking my services offline.
To be honest that clueless individual and its pathetically lame security practices made him lose 800 000 Bitcoin belonging to its customers with Mt Gox, which was written in... PHP.
And he went to prison for a few years for it. So he knows something about PHP exploits.
If the problem is in the parser then `file_uploads = Off` doesn't help, PHP still parses the multipart body. That seems to be why they're talking about blocking multipart/form-data on routes that don't take uploads and rate-limiting those that do.
I'm not them, but I'd say Conficker and those other windows file share worms were worse. They went after peoples personal computers rather than web servers so affected people less aware of how to deal with it. It's a little early to tell what this php one will all affect though.
Log4Shell was on a library called Log4J, used by many (but also not that many: Logback is equally as used and wasn't affected by the same vuln). This is straight up php the language.
It depends? I recall being on incident response and checking for that specifically (I worked in a big java shop at the time and was responsible for stuff like this). It was alot of screaming online, but things like Spring Framework used to pull Log4J v1 (ie: not affected) and spring-boot (the modern, way more used one) used Logback (also not affected). You'd get it from like a Kafka/Elastic dependency or similar, but only if you didn't have an SLF4J handler.. like spring would ship Logback for example. Which makes me thing, in general other java shops were mostly not affected as well, given spring is basically the go-to on the java world.
Extremely legacy software wasn't affected either (log4j v1 or apache commons-logging!). Lots of automated scanners flagging the idle jar as well (when the app used Logback for example as the SLF4J implementer, but the scanner saw a transitive for the log4j jar and would scream at you - that's when I stopped caring about github vuln scans btw, it was a shitshow).
Like dont get me wrong, it was a bad vuln, but to me it seems like it was more hype machine and internet screaming than actual vulnerable applications. I do recall Minecraft was vulnerable though, that one was indeed a big target given publicly exposed servers and such.
As a percentage of websites, though, Java is far from ubiquitous. It's probably not even double digit percentages. PHP, meanwhile, is some 70% of websites. So in terms of exploit targets, this is 10x that of Log4J, maybe.
The vulnerability also required you to log arbitrary user provided strings and maybe some other precondition that I can't remember. Nothing at my workplace at the time was affected despite using log4j since user provided data was either parsed (e.g. a uuid) or private/not something we would log.
I got into software dev because of cyber sec, and almost everything I learned revolved around poorly implemented php, so I always stayed away from it when building
What an awful video, not only because of the content of many PHP-running sites being exploited, but also because of the awful glitching and vignette effect, an odd dancing anime girl at the bottom and the horrendous music.
I am seeing a lot of words like "unconditional" thrown around but I remind that defense in depth is a thing and you can practice it, or should have been practicing it. You can, for example, disable the `system` function of PHP altogether. You can also arrange for your PHP to be running in a situation where there's no shell, or any other program, to exec. Or for that matter a filesystem.
no idea why this is downvoted. PHP runs typically on linux machines. If you depend on a language feature to prevent 'exploit' and don't utilize the operating systems features to limit access to data.
Shell access is not good, but in many places that wouldn't be the end of the world either.
If your PHP application accesses a database, you've got exfiltration, it doesn't matter in this case. Unless your PHP application is just echoing non sensitive data (i.e. rendering md files)...
For everyone wondering why the patch is not out yet:
There are a handful people responsible for doing a release. They are still asleep.
To be honest, I am also shocked, that the exploit was published that quickly, after the leaked video (which was the reason, why the announcement happened in the first place, at that specific time). We expected a bit more time, even with LLMs...
This is something of a fallacy. "The Industry" cannot learn.
But laws and regulations can require better security.
As in the history of seatbelts in vehicles, tech tool stacks are insecure by design and no one is ever really held accountable... until the cost is deemed too high.
It's evident that we have not reached that limit yet.
How? Biggest organisations and shared hosting providers had a chance to patch and protect their users. Everyone else will learn about the vulnerability the second patch comes out (this is also fixable with a configuration chance, so nobody needs to wait for their distro). This was the right approach and it worked.
The problem is that, since proofs-of-concept have leaked but the patch isn't available, bad guys can attack any site whose operators aren't part of the club, and the only thing the operators can really do to prevent that is to take the site offline. (PHP core team has denied that the configuration change fixes the problem.) I would call this a significantly worse outcome than everyone finding out about the vulnerability at the same time, since in that case operators can take timely action if they get the news quickly enough.
People here tend to be part of the silicon Valley insider club that gets access to all the cool offensive models, the expensive licensed software and services and insider information under NDA
They didn't release the patch out of fear that someone would quickly use the patch to develop an exploit, meaning an exploit is available shortly after the patch.
What they have achieved by delaying the patch is that exploits are now available publicly before a patch.
Also they could’ve sent patches to at least some trusted members/maintainers/distros/hyperscalers/big Hosters/plesk/cpanel.
It would’ve been easier to make some kind of coordinated release.
We've been working with the team on the coordinated disclosure, but I made the call to get these out early when exploits hit in the wild.
The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.
We've made these images free and will keep them that way.
What an incredible irresponsible move essentially 0-daying everyone who was working toward coordinated disclosure to ensure everyone had images or distro packages to update to.
what possible reading of "I made the call to get these out early when exploits hit in the wild" contorts into "these exploits hit in the wild after i made the call to get these out early" with flipped causality?
sure, i'm happy to recant my rather tepid defense of chainguard in the case that what was said upthread was a blatant fabrication. i'm even open to being convinced that it was.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
I don't think we have to not-believe Chainguard. To me, the problem is more that "in the wild" is a somewhat airy statement that can only be taken to strictly mean that one found it somewhere on a computer that is connected to other computers. This is almost a non-statement, as airgaps are the exception rather than the rule.
Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.
Publishing a patch beforehand potentially multiplies the impact. Now the actual bug(s) can be diffed from the source. Whereas existing PoCs (after verifying whether it even works), obfuscated at least a bit about the details. It is not so clear what is the best approach.
Yesterday the actual bugs plus many more (though less critical) were discovered by the people pointing their LLMs at it. I am confident no new bugs will be found by looking at binary diffs compared to what was already surfaced.
If you want to 'adopt' a new reality, you talk to all parties, and everyone moves up the release. That's how agreements and trust work. If you don't do so? No one will trust you ever again.
Yes but they obtained this information based on the one-sided courtesy of another party, under a scheme that tried to get as many people to safeguard together.
If the first party to receive this information says, "Wow, of course I must act on this, because customers are on the line," then it makes sense to simply choose who you tell more carefully or not at all.
If you saw customer data was being compromised; financial data, government data, electronic patient records etc, and you had the fix. Would you do nothing?
The alternative isn't "doing nothing". It's raising the issue in the coordination group so that everyone can collectively decide on a new timeline if necessary, and you aren't leaving everyone else hanging out to dry.
I find it really interesting how no one has been able to produce a POC after the blogs hit the public. Something key was probably omitted from the disclosure to prevent exactly this.
"We took our website down this morning when the "PoC"s were released, only serving a static website. Our customers were not pleased. Then we got contacted by Chainguard affiliates using our public support form if we would like to schedule a meeting with them, so that they could sell us their security services."
This is nonsense, disappointed to see that publicly from a core dev. Yes, some people are asleep, but the decision was made to wait, to ensure the patch is only made available when users are actually able to install the update and we're giving distros the time to build PHP packages.
Honestly, kindarails2shell resulted in a responsible disclosure coordination followed by the decision to release early since it was reversed too quickly. Even just a hint of a 0-day is enough to cause people to look for it and exploit it with LLMs.
That's horribly naive with an installed base this size and if you are that geographically dependent then I would hope to read how this will be dealt with going forward.
I am used to Python. Hard to switch to something else until I am forced to. I am trying to manage agentic coding at least to the point where I can identify bugs with my own eyes instead of purely believing the LLMs. I know I will cheat and let an LLM take over the entire Rust app if I tried.
NodeJS and Java are in a similar place (this CVE is a memory safety issue in PHP's C-language interpreter) but Go's compiler/runtime is written in Go and is memory-safe all the way down to the assembly.
Much of Node’s standard library is written in JavaScript, which can’t go on to exploit V8 vulnerabilities even given similar types of bugs, so I wouldn’t say it’s in a similar place. Not as familiar with Java, but I expect PHP is in a class of its own here.
How can I try this to see if I should shut things down myself. I run a 6 figure stealth and have a day job for fintech in 9 figures all php so kinda worried
Meh, I'll just roll PROD back to our 4.7 image, then head down to the pub for a pint until this all blows over... Only 3 years of data will be missing... No biggie! LOL :P
Years ago I migrated all my personal sites to being statically generated, since they don't have actual dynamic content anyway. That was a good decision.
Same here. And for the dynamic content, I host dedicated, small services, or client side code.
Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.
While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.
Only 53 comments for what's most likely going to be the biggest vulnerability in history? I don't understand how this isn't getting more attention. The exploit is already out and it's basically shell access on any php website out there.
It's also very early in EU and evening/night time in part of US. The information that was out earlier was on level "make sure you update tomorrow when the patch comes out", the actual details weren't out yet.
Off-topic but Reddit now requires sign-in to see old.reddit. They destroyed it, "to keep us safe".
Further more, if in Australia or a few other places like Brazil, UK, France, reddit won't let you sign in at all unless you're proven to be over 16. Bottom line, linking to old.reddit is similar to linking to a paywalled article.
They degraded old.reddit even for logged in users - images show as <image>and when you click the link you are redirected to new reddit layout just to see the picture
Once the dust has settled, it would be interesting to give LLMs the pre-patch source code and see whether any of them can identify this chain of vulnerabilities. Even if they can't identify the full chain, can they at least spot one of the constituent bugs and recognise its seriousness?
A PHP core dev suggested all the mitigations getting posted are not enough and that if possible you need to shut down any PHP app until the patch comes out https://phpc.social/@Girgias/117476510850918355
It gets used because people would rather say nice things like "PHP is alright" and "PHP has its place", than the hard truth. It is the political poster child for the software development domain. And shitting on it is almost career suicide and saying nice things about it would help fitting in...
But nature does not give a fuck about political correctness...
I don't have a "favorite" language. I see languages and communities having strengths and weakness..I evaluate languages as being suitable or unsuitable for certain job..
If a language gets frequently get vulnerability reports, it will change my evaluation...
Php's should have been evaluated out for web applications a long time ago, if the development community was rational, but sadly its made up of far too many emotional people who takes everything personal...
Just as a scripting language on my own laptop, nothing prod. But one thing I notice, even coming back to it after a little while, even after using Python for everything, I find I am effortlessly productive with it.
There was an article I read recently about a blind developer who finds it easy to write in, as the "$" for the variable names makes it easier for him to identify what's going on in any given line of code.
Like any language it has advantages and disadvantages.
The "Syntax as landmarks" section sounds like he's comparing it particularly to Python. The quirk of `$` denoting a variable did kind of work out for him. Especially compared to Python where you declare a variable by assigning it. But it's not like PHP was designed with a special character for each syntax role. He still needs to use context to infer other roles.
PHP has the advantage of being preinstalled or easy to install in a lot of environments. I had to investigate the blind developer thing because I'm still on the hunt for a second advantage.
Writers/editors really, really like Wordpress for some reason, which is like 40% of the Internet, add to that all the other Php stuff. At $DAY_JOB we have a Wordpress instance behind our VPN and use the json API to send the articles to a front-end server written in something else. Forces us to duplicate some of the front-end plugin code (and we try to not use many) but we get peace of mind in exchange.
I think the ubiquiti edgerouter admin interfaces use PHP. I don’t know about mikrotik, but wouldn’t surprise me if there are a lot of those devices hanging off the internet on some nonstandard port.
Unsure what the correct response from the PHP team is here - I hope there's been plenty of work done behind the scenes to mitigate this on unpatched servers because there's not a chance defenders win the race everywhere it matters once the patches are out.
475 comments
[ 0.19 ms ] story [ 130 ms ] threadI think the best course of action is to just shut your server down before the patch goes live and then bring it back after you have patched.
https://www.schneier.com/blog/archives/2005/12/benevolent_wo...
Turning it off may cause deaths. Letting it get ransomwared may cause more. Do you pull the lever to turn it off?
You make sure www-data CANNOT write ANYWHERE on disk. Not /tmp/ Not to /var/www/. No where.
Then make sure your sudoers has nothing weird in it.
Finally disable www-data's ability to run basically anything that isn't required for the operation of your httpd or php-fpm et al.
You then harden it further and further until an RCE does not matter because it's incapable of doing anything.
tldr always treat httpd as untrusted.
And also relies on the target being patched against any Linux EoP...
Also: https://stopdisablingselinux.com/ - SELinux can mitigate this.
"How to make your site cost unlimited money and have terrible performance". People did this in the Web 1.0 days on occasion and it leads to all kinds of problems for any site with any kind of traffic.
>Or you make an exception for them.
Useless. All you need to do at that point is chain a priv-esc to your existing exploit and you get root.
The PoC also requires a known binary to exploit so custom PHP builds may be safe if you're lucky, but this seems to be an extremely bad one.
php.ini:
Are you speaking officially here?
There are various mitigations suggested online, including completely blocking multipart requests at LB level. Is the combination of both effective?
https://phpc.social/@Girgias/117476477429221001
> Two cached bucket pointers, one freed tree.
I've rarely been happier than now to have left IT for good...
You immediately know you're likely to get clear, technical, actionable info instead of some corporate bullshit
Not so with LLM usage
But I'm reading a website for getting information, not LLM fluff.
And he went to prison for a few years for it. So he knows something about PHP exploits.
why it would be a thing, beyond "serious problem"?
Yeah no.
This is bad but doesn't even crack the top ten.
At the end of the day, nobody gives a shit if another WordPress blog gets hacked.
lol no.
I feel old. Heartbleed was 2014.
Extremely legacy software wasn't affected either (log4j v1 or apache commons-logging!). Lots of automated scanners flagging the idle jar as well (when the app used Logback for example as the SLF4J implementer, but the scanner saw a transitive for the log4j jar and would scream at you - that's when I stopped caring about github vuln scans btw, it was a shitshow).
Like dont get me wrong, it was a bad vuln, but to me it seems like it was more hype machine and internet screaming than actual vulnerable applications. I do recall Minecraft was vulnerable though, that one was indeed a big target given publicly exposed servers and such.
Measuring “worst” is hard.
Thanks, PHP.
I got into software dev because of cyber sec, and almost everything I learned revolved around poorly implemented php, so I always stayed away from it when building
but this time it's php directly? that's scary
Shell access is not good, but in many places that wouldn't be the end of the world either.
Rethink your strategy
At least this time we can have LLMs rediscover it and make patches ourselves.
There are a handful people responsible for doing a release. They are still asleep.
To be honest, I am also shocked, that the exploit was published that quickly, after the leaked video (which was the reason, why the announcement happened in the first place, at that specific time). We expected a bit more time, even with LLMs...
This is something of a fallacy. "The Industry" cannot learn.
But laws and regulations can require better security.
As in the history of seatbelts in vehicles, tech tool stacks are insecure by design and no one is ever really held accountable... until the cost is deemed too high.
It's evident that we have not reached that limit yet.
What they have achieved by delaying the patch is that exploits are now available publicly before a patch.
Surely this is the worse outcome.
Also not announce it beforehand…
The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.
We've made these images free and will keep them that way.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.
If you want to 'adopt' a new reality, you talk to all parties, and everyone moves up the release. That's how agreements and trust work. If you don't do so? No one will trust you ever again.
And?
You won't be at the table next time.
If the first party to receive this information says, "Wow, of course I must act on this, because customers are on the line," then it makes sense to simply choose who you tell more carefully or not at all.
"We took our website down this morning when the "PoC"s were released, only serving a static website. Our customers were not pleased. Then we got contacted by Chainguard affiliates using our public support form if we would like to schedule a meeting with them, so that they could sell us their security services."
anything that narrows the searchspace
That's horribly naive with an installed base this size and if you are that geographically dependent then I would hope to read how this will be dealt with going forward.
https://nodejs.org/en/blog/vulnerability/october-2026-securi...
Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.
While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.
With vibe coded slop tools readily available, using php in 2026 is just laziness.
https://xitter.cf/k_firsov/status/2112718728232329240#m
https://phpc.social/@Girgias/117476510850918355
https://old.reddit.com/r/PHP/comments/1xb2utu/comment/phyu5m...
Further more, if in Australia or a few other places like Brazil, UK, France, reddit won't let you sign in at all unless you're proven to be over 16. Bottom line, linking to old.reddit is similar to linking to a paywalled article.
If they can't, why not?
If they can, why haven't they already?
If you only tell them to find issues in PHP - the strongest models probably still can, although they might find different issues ;)
The bad guys have invested the resources of the criminal enterprise into hardware running unrestricted models.
I know there must be a ton of random sites which makes this a huge deal.
But, does it affect any big players? I think php is big at Meta but I would imagine its so heavily customized it might be safe from this.
It gets used because people would rather say nice things like "PHP is alright" and "PHP has its place", than the hard truth. It is the political poster child for the software development domain. And shitting on it is almost career suicide and saying nice things about it would help fitting in...
But nature does not give a fuck about political correctness...
If a language gets frequently get vulnerability reports, it will change my evaluation...
Php's should have been evaluated out for web applications a long time ago, if the development community was rational, but sadly its made up of far too many emotional people who takes everything personal...
Just as a scripting language on my own laptop, nothing prod. But one thing I notice, even coming back to it after a little while, even after using Python for everything, I find I am effortlessly productive with it.
There was an article I read recently about a blind developer who finds it easy to write in, as the "$" for the variable names makes it easier for him to identify what's going on in any given line of code.
Like any language it has advantages and disadvantages.
The "Syntax as landmarks" section sounds like he's comparing it particularly to Python. The quirk of `$` denoting a variable did kind of work out for him. Especially compared to Python where you declare a variable by assigning it. But it's not like PHP was designed with a special character for each syntax role. He still needs to use context to infer other roles.
PHP has the advantage of being preinstalled or easy to install in a lot of environments. I had to investigate the blind developer thing because I'm still on the hunt for a second advantage.
[0] https://modat.io/blog/php-exposure-before-the-21-oct-2026-se...