Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
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.
-
PHP updates and mitigations are out: https://www.php.net/index.php#2026-10-21-5
-
PHP updates and mitigations are out: https://www.php.net/index.php#2026-10-21-5
@GossiTheDog but where are the docker images?
-
PHP updates and mitigations are out: https://www.php.net/index.php#2026-10-21-5
@GossiTheDog is php 4 affected (asking for a friend)?
-
@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.
@GossiTheDog Messing with getting a PoC. This doesn't seem to be a trivial exploit. ASLR has to be defeated through leak addresses, size of the memory has to be large enough, specific glibc has to be considered. While the entire platform of PHP is vulnerable, I don't think this is going to be a simple exploit to land.
-
@GossiTheDog is php 4 affected (asking for a friend)?
@CenturyAvocado @GossiTheDog Get with the times! (I'm on php 5)
-
@GossiTheDog Messing with getting a PoC. This doesn't seem to be a trivial exploit. ASLR has to be defeated through leak addresses, size of the memory has to be large enough, specific glibc has to be considered. While the entire platform of PHP is vulnerable, I don't think this is going to be a simple exploit to land.
