Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
@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.
-
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.
I am still trying to figure out whether I should assume breach by default or whether I am fine checking manually for intrusion.
The main primary systems and client facing stuff just doesn't use php, so we kinda dodged a bullet.
-
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.
@GossiTheDog still online unlike the dutch ncsc thanks to Java. stay winning, germany lol
-
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 so….this vulnerability just grounded the Belgian school system provider. The platform will be down until the vulnerability has been appropriately dealt with. Any idea if the fix is readily available? Just to estimate the amount of downtime.
-
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 Any mitigations for Windows? We have customers running PHP 7 and even 5 who cannot patch (besides, there won't be a patch available for anything but 8).
Or should we just prepare for incident response?
-
@GossiTheDog session.upload_progress.enabled = off
@joho @GossiTheDog as far as we've all been told, that doesn't work.
-
@GossiTheDog so….this vulnerability just grounded the Belgian school system provider. The platform will be down until the vulnerability has been appropriately dealt with. Any idea if the fix is readily available? Just to estimate the amount of downtime.
@TomDB @GossiTheDog Php website mentions fixes to be released at 14:00 UTC, i.e. 16:00 CEST.
-
@joho @GossiTheDog as far as we've all been told, that doesn't work.
-
@GossiTheDog Any mitigations for Windows? We have customers running PHP 7 and even 5 who cannot patch (besides, there won't be a patch available for anything but 8).
Or should we just prepare for incident response?
-
@bontchev @GossiTheDog Any good ones?
-
@bontchev @GossiTheDog Any good ones?
@t_var_s @GossiTheDog Haven't tried any of the PoCs yet; need the admin's permission. The write-ups contain mitigations but warn that they are not completely sufficient. I've also seen claims that making the site read-only (i.e., disable POST requests) prevents the exploit, if you can afford to do it.
-
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.
PHP updates and mitigations are out: https://www.php.net/index.php#2026-10-21-5
-
The screenshot in this tweet is real. https://infosec.exchange/@wdormann/117475540081194496
@GossiTheDog I sent claude after it just using the source code and the picture posted. Got a PoC working by the time I dropped the kid off at school.
