Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
@GossiTheDog https://www.behindtheconsole.com/2026/10/21/patch-your-php-pre-2026-10-20/ this shell script helps to toggle the mitigation setting to
session.upload_progress.enabled = Off@filid @GossiTheDog According to Heise, changing this parameter won't help https://www.heise.de/news/Wichtige-PHP-Updates-am-21-Oktober-beheben-Codeeinschleusung-Schwachstellen-11495072.html
-
The screenshot in this tweet is real. https://infosec.exchange/@wdormann/117475540081194496
@GossiTheDog Link to the post from which the screenshot seems to have been taken:
https://news.ycombinator.com/item?id=50167754
I've seen claims that the post was deleted - but I can still see it.
-
-
@filid @GossiTheDog According to Heise, changing this parameter won't help https://www.heise.de/news/Wichtige-PHP-Updates-am-21-Oktober-beheben-Codeeinschleusung-Schwachstellen-11495072.html
@gunchleoc @GossiTheDog
Thanks, I updated my blog post mentioning heise and https://www.vincentschmalbach.com/cve-2026-109618-and-cve-2026-109619-what-you-should-do-now/ -
Somebody has posted technical details of the PHP vulns. It’s likely LLM generated from GitHub commits (or somewhere!) but it’s in the right ballpark on one of the issues.
There’s also another decent mitigation in this but the only real one is to patch.
-
@GossiTheDog so concern is that anyone sitting on vulns will now rush to exploit before they can be patched?
Seems like this kind of thing could also be used without real vulnerabilities (but with a bunch of honeypots in place) to "shake the bushes" for any vulns that are being held.
@fencepost @GossiTheDog I don’t know that there’s a need to rush. So many embedded installations out there that will never be patched. Too many forgotten, unmaintained apps. There will be a long tail for this one.
-
@lanodan @GossiTheDog They didn’t.
-
@GossiTheDog @christopherkunz It's AI slop, so nobody should rely onthe proposed mitigation.
-
@GossiTheDog @systemadminihater @wdormann Plus the exploit is in the wild ...
-
A really good mitigation for this btw - AppArmor or SELinux.
Google something like apparmor restrict php from executing commands. Works against these CVEs.
Sucks for cybersecurity vendors who shipped their appliances using PHP without SELinux or AppArmor, of course.
What makes you think that Apparmor works against these?
-
I think PHP probably has to bring forward the release as cyber vendors who have advanced notice told customers details so now everybody is running around with details.
There’s probably a conversation to be had about cyber vendors effectively reselling open-source project intelligence for profit. I don’t think it is great. Protecting the ivory tower sucks.
@GossiTheDog You're faster than most commercial services on the issues that matter
. -
@GossiTheDog @derickr @saramg pinging for visibility
@sephster @GossiTheDog @saramg Thanks. We'd seen it already.
-
@GossiTheDog
Looks like Calif may have a PoC called php2shell that works against WordPress.Calif as in the cybersecurity company?
It's not on their official channels though, is it?
-
Calif as in the cybersecurity company?
It's not on their official channels though, is it?
@kallisti @wdormann @GossiTheDog yes it was. But they either took it down afterwards or Twitter has some kind of new "private" setting. Unsure. But I have seen links refer to the video published by Calif's Twitter channel, which didn't work for me through nitter.
-
Somebody has posted technical details of the PHP vulns. It’s likely LLM generated from GitHub commits (or somewhere!) but it’s in the right ballpark on one of the issues.
There’s also another decent mitigation in this but the only real one is to patch.
@GossiTheDog PHP lead developer says that mitigation isn't sufficient @ https://phpc.social/@joepferguson/117476273857491231
-
@kallisti @wdormann @GossiTheDog yes it was. But they either took it down afterwards or Twitter has some kind of new "private" setting. Unsure. But I have seen links refer to the video published by Calif's Twitter channel, which didn't work for me through nitter.
-
The PHP situation will lead to a mass of incidents - it’s one of the biggest vulns in years.
Shodan dork "X-Powered-By: PHP/" - a lot are on EOL versions with no patch. It’s also more hosts as not everybody lists their PHP version in headers.
@GossiTheDog session.upload_progress.enabled = off
-
@GossiTheDog You're faster than most commercial services on the issues that matter
.@masek @GossiTheDog I am still wating for debian/ubuntu patches....
It's a shame that all details are on the table and the embargo is still in place.
That 3 hours left are a LONG time...
-
The screenshot in this tweet is real. https://infosec.exchange/@wdormann/117475540081194496
BSI advisory on PHP:
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297981-1032.html
And yes, I agree with everybody it is best to patch where updates are available.
There *are* mitigations for some of the chain which may be useful as an interim measure - they should be in the PHP advisory I’m guessing, if not I’ll do a blog later.
SELinux and AppArmor, configured correctly, work well and should be considered regardless.
-
A really good mitigation for this btw - AppArmor or SELinux.
Google something like apparmor restrict php from executing commands. Works against these CVEs.
Sucks for cybersecurity vendors who shipped their appliances using PHP without SELinux or AppArmor, of course.
@GossiTheDog True, but #SELinux to restrict #php execution is difficult to implement.
For instance, when using #Apache and #php-fpm, the latter has the same SEL profile as the main apache process and therefore, none of the restrictions of the SEL profile used for PHP scripts. Creating a custom SEL profile for php-fpm is not something you can improvise in half a day.
