Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
@t_var_s @GossiTheDog One of the mitigations suggests disabling that.
-
@GossiTheDog @CenturyAvocado do the patches actually fix it as I'm seeing rumors that maybe not or another similar exploit
-
@GossiTheDog @CenturyAvocado urrgh
-
@GossiTheDog More information, from various sources:
https://medium.com/@costin.raiu/php2shell-apocalypse-b8dae59dd753
https://cybersecuritynews.com/php-early-exploitation-attempts/
Exploitation attempts seem to have started, despite the lack of public weaponizable exploit.
@GossiTheDog And even more. (Serious stuff starts after the comic at the beginning.):
-
@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@christopherkunz @GossiTheDog What if this was just some readiness test from counter-intelligence? Tomorrow is told there was no exploit. Only hundred thousand servers rummaging through launchpad for software updates.
-
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 According to the post below, 8.5.12 introduced a new vulnerability
https://fedi.katze.sh/@elise/117479383739450605
(edit: no, different vuln, I missed the details earlier in their thread)
-
@GossiTheDog Ah yes sorry, you are right - the first part of their thread did not cross my eyes at first
-
@GossiTheDog agreed
-
@GossiTheDog Especially with companies breaking the embargo.
-
@FediThing @nemo @GossiTheDog as someone that has a particular interest and hobby into talking and exploring the hobbyist maintainer side of things... this is an actually well funded and managed project compared to the vast majority of what runs the internet.
The PHP foundation is easily in the top1% if not the top 0.1% of these FOSS projects in term of resources.
I know it is even worse said like that but... yeeeeeep
-
@fedipete @GossiTheDog where 4 art thou, PKI?
-
You wrote "... it’s mostly volunteers powering the internet while almost everybody freeloads off ‘em, tale as old as, well, the internet."
Hmmn, I've been reading economic philosophies in passing, am]nd notice freeloading seems to be something every system seems to have to face.
Which have been studied, sometimes to death...
Anyone in economics here?
If not, please boost for reach -
@FediThing @nemo @GossiTheDog I mean... I don't see this as so negative. I see this as a positive. These companies have massive rosters of devs and can barely do anything close to what the volunteers do. It shows they are just.. bad at this and not a danger.
-
OpenAI ambulance chasing the PHP vulnerabilities and pretending they found and disclosed them (they did not) is disgusting. It’s a media play and it’s really gross, and says a lot about OpenAI.
-
OpenAI ambulance chasing the PHP vulnerabilities and pretending they found and disclosed them (they did not) is disgusting. It’s a media play and it’s really gross, and says a lot about OpenAI.
Regarding the rumours the PHP patches don’t fix the vulnerabilities - it’s not true, they patched the vulnerabilities of issue.
The rumours are also separate issue which people are mixing up. Don’t panic about that one.
-
Regarding the rumours the PHP patches don’t fix the vulnerabilities - it’s not true, they patched the vulnerabilities of issue.
The rumours are also separate issue which people are mixing up. Don’t panic about that one.
Regarding the rumours the PHP patches don’t fix the vulnerabilities - it’s not true, they patched the vulnerabilities of issue.
Having reviewed their diff, I'm not sure how you can make that claim. Their fix for data corruption in out-of-memory conditions was to add explicit error handling on a huge number of code paths. A change of that level of complexity almost certainly misses error handling from one or more paths that matter. It is not a systemic fix that would address the root cause, it is a load of duck tape applied across the entire codebase.
I think it's reasonable to claim that it fixes the specific exploit path used in the PoC but I am not at all convinced that it fixes the vulnerability.
-
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 really important message
thank you for sharing -
OpenAI ambulance chasing the PHP vulnerabilities and pretending they found and disclosed them (they did not) is disgusting. It’s a media play and it’s really gross, and says a lot about OpenAI.
-
Regarding the rumours the PHP patches don’t fix the vulnerabilities - it’s not true, they patched the vulnerabilities of issue.
Having reviewed their diff, I'm not sure how you can make that claim. Their fix for data corruption in out-of-memory conditions was to add explicit error handling on a huge number of code paths. A change of that level of complexity almost certainly misses error handling from one or more paths that matter. It is not a systemic fix that would address the root cause, it is a load of duck tape applied across the entire codebase.
I think it's reasonable to claim that it fixes the specific exploit path used in the PoC but I am not at all convinced that it fixes the vulnerability.
@david_chisnall Since the blog that describes the exploitation process recommends memory_limit = -1 (disabled) as a mitigation if patching is not possible, I was thinking whether it would make sense as a defense-in-depth measure to run with the internal memory_limit disabled all the time. Instead set up rlimits or cgroups or whatever to immediately kill off workers that hit the limit.
I don't deal in php much and this probably isn't suited to all installations, but in theory this feels like it should eliminate a class of vulnerabilities stemming from retroactively implemented OOM recovery. @GossiTheDog
(edit: turns out that convincing Linux to JUST KILL THE FUCKING PROCESS DO NOT SEND ENOMEM DO NOT TRY ANYTHING without resorting to LD_PRELOAD tricks is hard, setting both memory.max and memory.swap.max maybe kinda does it?)
