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.
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.
Also hp system management homepage (installed on HPE Proliant servers) all ship with PHP.. with no ASLR. There doesn’t appear to be a patch for that, you can use it to surf around flat networks as it drops you as SYSTEM/root.
There’s absolutely shit tons of exploits for PHP2Shell on GitHub and basically none of them actually work to RCE as nobody can figure out ASLR properly.
Which is good, because patching is going to take a long time.
https://php2shell.censys.com/
If you’re wondering why your million dollar cybersecurity vendor appliances don’t have ASLR enabled.
ASLR supporting PHP exploits are coming, probably next week.. but it’s a really good security control (from decades ago) you should demand your vendors actually enable as it enabled time for orgs paying attention to patch.
The cybersecurity vendor industry itself is essentially negligent when it comes to this stuff. https://infosec.exchange/@catc0n/117487878549556020
There is another PHP potential RCE vulnerability - CVE-2026-115560 - without a patch. Do not panic.
It is a non-default configuration and will not be a widespread issue.
The mitigations in this thread already fix it, if you want to panic.
PHP Foundation’s budget is about 700k a year. It’s used on something like 40 million websites. Almost no company who uses it contributes anything and many people work on it for free.
The latest trend is cybersecurity and AI vendors have realised they can vampire off its security for publicity (money).
Perhaps the world would be a better place if those orgs who rely on it just contributed sponsorship to the foundation, and vendors didn’t monetise vulnerabilities for themselves.
Oct 22, 2026, 8:35 AMRegarding 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 There's a lot more setjmp/longjmp use in there, which would make it even harder to reason about the code than normal for a project like this. Combine that with trying to handle out of memory conditions without terminating, and I wouldn't be surprised if there are a lot more bugs out there.
I can understand why you wouldn't want mod_php taking down the web server in these cases, but perhaps that just means putting the language runtime inside the web server is a bad idea.
Oct 22, 2026, 5:55 PM@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.
🎵Please let me sleep? 🎵
* Poetry, that'll work. Come, sweet slumber. Enshroud me in thy purple cloak…
@GossiTheDog That toot says there's already a functional ASLR bypass poc out there...?
@christopherkunz there’s one on GitHub but it’s not super functional in reality.. plus people largely haven’t found it yet 🤣 it’d need more work to scale.
@GossiTheDog what is #aslr #php
Oct 23, 2026, 12:32 PM@GossiTheDog but yeah, php is a bad language and we should get rid of it.
Oct 23, 2026, 12:44 PMSo what Meta (who famously use PHP extensively in what used to be their flagship product) spent on the complete failure that was the metaverse (~$60 billion) could have funded them at current levels for close to 100,000 years
@GossiTheDog
Sure, but they knew about this since 2024!
So the main issue still is bad judgment on security here, as they invested their time and money obviously on other issues since then…
@MarkusStoll I hate to alarm you but there are likely other known, bigger issues. They need funding.
@GossiTheDog Someone never heard of defence in depth? ;)
Oct 23, 2026, 8:37 AM
@aetios @GossiTheDog I found this post really insightful: https://infosec.exchange/@david_chisnall/117308418842462706
In this sense ASLR is a non-durable mitigation
Oct 23, 2026, 10:27 AMASLR adds work factor for attackers but there are a bunch of ways of breaking it. The Blind ROP attacks, for example, are easy to automate. In practice, it's often possible to leak a pointer.
I really hate the naming because there are two different techniques whose names are the wrong way around. Address Space Randomisation (ASR) was first (I think?) shipped in OpenBSD and randomises each mmap call. The layout of the address space is random. Address Space Layout Randomisation came from the Linux PaX project. It gives a deterministic layout but with a random base. This is nice for deployment: ASR suffers from the problem (especially on 32-bit systems) that the random addresses may be sufficiently fragmented that a later memory allocation fails because there isn't a sufficiently large contiguous space, but it works the next program invocation with different layout.
With ASR, leaking one pointer lets you determine the addresses of all other memory locations in the same region (shared library, malloc bucket, whatever). With ASRL, leaking one pointer is sufficient to determine the location of everything. It turns out it's really easy to leak one pointer. This is even worse for KASLR because your adversary (userspace) has a rich API surface that was never designed on the assumption that kernel addresses were secret (because the MMU means that you can't use a kernel address, even if you know one) and you just need one.
The thing that's changed here seems to be LLMs. Now, rather then using exploit toolkits the include automatic mitigation bypass steps, script kiddies are just asking Claude to produce an exploit. And Claude is doing what LLMs normally do: produce output that looks correct according to a statistical distribution of text. When used in an 'agentic' model, it keeps trying to do this until it finds one output that actually works in the specific conditions that the agentic loop is set up to test. It turns out it's not just nature that can build a better idiot, Anthropic is competing hard in this domain.
The other dimension in this spectrum is the cost. ASLR is basically free. The kernel complexity is tiny (I think the FreeBSD patches had under a hundred lines of functionality change, most of the code was the extra controls for turning it on and off - you really want to be able to turn it off in debuggers, for example, so that your program runs are deterministic, and ideally you want to be able to capture the random seed and replay it so that your debugger can see the conditions that your fuzzer triggered). It also doesn't change the programmer's abstract machine significantly, so if you remove it in the future it won't break things.
If it adds any work factor to attackers, you may as well turn it on because it will at least prevent the least competent ones. And it's embarrassing if your system can be compromised without any effort.
@GossiTheDog It doesn't work perfectly. Let's remove it then. 🤡
Oct 23, 2026, 8:59 AM@GossiTheDog Wondering why Colin is having such a strong opinion here. He is quite knowledgeable on good security tradeoffs usually. Purism ?
It would be easy to dismiss it as security by obscurity, though it's more than that it's akin to the obfuscation of code.
The difference is that the layout of addresses should be random each time it's launched.
But like anything identify the mapping and it's another exercise in lookups.
@GossiTheDog
It's always such a surprise when someone you respect has a dumb take... But then I remember that there are likely so many dumb takes of mine on the internet 😂
@GossiTheDog neat page, though it just assumes versions like 7.4 are unfixed, whereas probably many are using Sury’s PHP which definitely patched it (and I think even 5.6).
There’s probably no better way though to track, so still a useful infographic
@mig5 yeah if has clarifications for version numbers not being a bulletproof way. But still, orgs historically very bad at patching so it gives a rough indicator picture. Many are just on raw EOL versions, can also see they’re on EOL Redhat etc.
@GossiTheDog I can’t believe so many leave expose_php = On !
@GossiTheDog Presumably that may get confused by backports, i know some hosting control panel providers have backported to 7.4 for instance.
@GossiTheDog crap
@GossiTheDog Why in the name of god would you disable ASLR on a security appliance?
@mikesiegel palo never enabled it, and Citrix Netscaler is based on a decade old FreeBSD release which is EOL and doesn’t have ASLR support.
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.
@GossiTheDog it’s a more advanced case of tag hijacking.
Oct 22, 2026, 8:17 PM@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.
