Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.
-
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?)
-
@GossiTheDog Those PHP volunteers deserve some appreciation
-
I call dibs on this.
See my comments here at line 573. I also ran into longjmp problems and solved them also.
Unfortunately the PHP team only wanted a quick oneline fix of the handler which later bit them again on pipelined http requests.
https://github.com/gmoniker/php-apache2handler/commit/11aa93f85afcf837fd299b3557191f00cc026ec9
-
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.
And as always these days, if you get news from a media source that is played by this, reconsider keeping them as a media source.
-
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.
@GossiTheDog it’s a more advanced case of tag hijacking.
-
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.
-
@GossiTheDog well, use AI and risk getting known (and forgotten) because of it.
I know the AI company is much larger and powerful, and needs the markering hype to survive, but that seems to be the current tradeoff for using AI. -
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.
@GossiTheDog given that it’s reasonably likely they were scraping chat sessions for hints on mathematical problems, it seems plausible to me that the same happened here.
-
If you use Palo-Alto firewalls, make sure you upgrade for the PHP vulns.
In particular, if you have the mgmt interface facing the internet upgrade those now. The Palo-Alto firewall VMs have ASLR disabled which makes exploitation trivial.
-
If you use Palo-Alto firewalls, make sure you upgrade for the PHP vulns.
In particular, if you have the mgmt interface facing the internet upgrade those now. The Palo-Alto firewall VMs have ASLR disabled which makes exploitation trivial.
@GossiTheDog If you have a management interface facing the Internet on your firewall, you should reconsider your career.
-
If you use Palo-Alto firewalls, make sure you upgrade for the PHP vulns.
In particular, if you have the mgmt interface facing the internet upgrade those now. The Palo-Alto firewall VMs have ASLR disabled which makes exploitation trivial.
Also update Citrix Netscaler boxes for PHP vuln, particularly if you have mgmt interface facing Internet. Why? You guessed it - ASLR is disabled.
-
If you use Palo-Alto firewalls, make sure you upgrade for the PHP vulns.
In particular, if you have the mgmt interface facing the internet upgrade those now. The Palo-Alto firewall VMs have ASLR disabled which makes exploitation trivial.
@GossiTheDog here's where I'd install the patch
-
Also update Citrix Netscaler boxes for PHP vuln, particularly if you have mgmt interface facing Internet. Why? You guessed it - ASLR is disabled.
Please let me sleep? * Poetry, that'll work. Come, sweet slumber. Enshroud me in thy purple cloak…
