Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
PHP releasing patches tomorrow for CVE-2026-109618 and CVE-2026-109619
Fixed versions will be 8.5.12, 8.4.27, 8.3.36, 8.2.35
All others are end-of-life but are still vulnerable - the vulns date back to versions from 2004 onwards.
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.
-
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 I may look into this, though I'm not sure how restrictive I can get with mine since I use it to host Nextcloud, which has a variety of "apps", such as one that hooks into clamd to scan files for viruses when they're uploaded, etc. I'm not certain exactly how those work and if restricting the ability to execute commands would break certain expected functionality. I need to educate myself on AppArmor anyway; seems like a good excuse to sit down and do some reading.
-
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 I’m convinced security vendors are, on average, substantially worse at security than any random vendor.
-
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 you're saying blocking your php from execve() fully mitigates this?
-
@GossiTheDog I had read that 8.0 and 8.1 would also be getting patches, is that not correct?
@emd @GossiTheDog If you're on an EOL version, I would suggest searching for "PHP commercial LTS".
-
@emd @GossiTheDog If you're on an EOL version, I would suggest searching for "PHP commercial LTS".
@afilina @GossiTheDog have to see how our devops platform (Laravel Forge) will handle.
But nice to know there might be other options, thanks for making me aware of these.
-
@GossiTheDog you're saying blocking your php from execve() fully mitigates this?
@tbodt @GossiTheDog he has no idea
-
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 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 -
That's gotta be the plan, right?
Force people to adopt unmaintainable slop fixes, to ensure they never will be able to get rid of that growing ball of technical debt and stay chained to the slop machines forever.
-
PHP releasing patches tomorrow for CVE-2026-109618 and CVE-2026-109619
Fixed versions will be 8.5.12, 8.4.27, 8.3.36, 8.2.35
All others are end-of-life but are still vulnerable - the vulns date back to versions from 2004 onwards.
@GossiTheDog Any relation to Netscaler? There’s some php on there too. Or nothing to do with it?
-
@piggo @GossiTheDog Don't worry, the first to break in will usually patch it for you.
@yngmar @GossiTheDog well I'll just watch it from the back seat here. But there is no infrastructure for automated updates, so the servers will sit unpatched for days at least
-
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 Happily, we do have apparmor already running, so thanks for the mini profile.
(I also have an alarm set up for a Fuck You Assholes three hour early wakeup to stagger over to a console in time for the patch drops. But, well.)
-
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.
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.
-
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.
-
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 @derickr @saramg pinging for visibility
-
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 thank you that was the best explanation of it yet
-
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.
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.
-
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 yeah, I'm calling bs on this too. From a place of "having tried the poc", see e-mail for details.
https://chaos.social/@christopherkunz/117477368766737839 -
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 Greenland looks good
-
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 This is LLM-written (evidence for claim: A - the entire text flags 100% in Pangram, which anecdotally is not perfect but is pretty good. B. the credited author ( https://x.com/J4ck3LSyN ) sounds nothing like this on their Twitter and people don't change their voice so easily)
I don't say this to entirely disparage it - lots of hackers do this currently to put their conclusions in "nice" writing, and the conclusions might be right. But I'd be careful if you can't follow the claims.
