Upcoming Critical PHP Security Release
141 points by pushcx
141 points by pushcx
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.
Somebody leaked. I'm not sure what can be done to handle that better other than not trusting them again?
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.
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
At the start of the video: right column: a browser open to a WordPress instance pointed at /wp-content/uploads/pwned.txt showing a 404.
Left column: a terminal running the PoC exploit with this command:
python3 php2shell.py \
--profile 21 \
http://127.0.0.1:29264/wordpress/wp-content/index.php \
--command 'uname -a; id; echo "pwned" > /var/www/html/wordpress/wp-content/uploads/pwned.txt'
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.
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.
You RCE entirely without writable file system access and it's exactly as useful as without.
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.
I don’t know anything about your dog. I do know something about this RCE.
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?
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.)
What a banger of a track too!
High Forever (Marlon Hoffstadt Remix). Damn, Edgerunners II soundtrack making the rounds at pace!
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!
I do hope the brave souls who run their personal nextcloud on the open internet are paying attention.
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.
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):
It's supposedly vulnerable back to 5.x, so I think that rules out the JIT.
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.
https://chaos.social/@christopherkunz/117477368766737839 that poc may also have been wrong to start with, someone couldn't repro
So:
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.
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
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.
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.
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.
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.
every line reference in the original writeup
Ouch, it's uncanny to see an AI-generated exploit page with an AI-generated write-up.
The PHP project page now has links to updated versions
https://www.php.net/archive/2026.php#2026-10-21-5
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:
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.
Interesting, I assumed that this php-8.4 in my apt upgrade was it. I should more careful.
$zless /usr/share/doc/php8.4-common/changelog.Debian.gz
php8.4 (8.4.27-1~deb13u1) trixie-security; urgency=high
* New upstream version 8.4.27
+ (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via
bailout.
-- Ondřej Surý <ondrej@debian.org> Wed, 21 Oct 2026 09:53:46 +0200
seems fine?
This has a chance to be the most impactful vulnerability I've seen.
At least Cloudflare added mitigations for the known exploits:
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.
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
This one looks like a doozy. Safest to just take any PHP applications offline until the patches drop.
Vincent Schmalbach tells that 2 things need to be done:
php_admin_flag[session.upload_progress.enabled] = off
The fix for anyone that wants to see the code
https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065
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.
There's so much misinformation flying around, so I have to ask - what official channels released an exploit?
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
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
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.
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
For those wondering how the coordinated disclosure of php2shell broke down in the last few days:
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.
brittle foundations. Ran into an unrelated example ten years ago https://blog.mro.name/2015/03/why-php-is-utterly-broken/
The time to be deploying PHP applications in production is long over. At this point it should be considered malpractice.
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...
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.
I know it's cool to quote talks from 2012 about a language in 2026 but PHP has changed a lot.
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.