Since my posts have been shared here ~30 times in the past few weeks, it seems like I'm going to be contributing to Space Karen's Ketamine Extravaganza whether I like it or not. I don't really intend to be active here, but I'll post some of the more important cybersecurity-focused stuff, since it gets screenshotted anyway. That way, people don't have to read post a week late and out of context.

I'll be the first to admit I'm mediocre at exploit development, but I am in contact with enough extremely talented exploit developers to say this for certain: Anyone claiming they were "easily" able to generate a working php2shell exploit with AI is either: a) a world-class exploit developer with an extreme case of imposter syndrome. b) currently looking at some very confident-sounding but wrong LLM output. I'm rather certain it's the latter based on the number of AI-hallucinated exploits I've seen posted on GitHub. Threat actors are also blasting my honeypot network with "php2shell" exploits that not only don't work, but aren't even within 10,000 miles of anything to do with how the exploit actually works. I've seen the same technique from the attached image in multiple alleged "php2shell exploits", including one on GitHub with over 100 stars. Problem is, it's not php2shell, nor is it even a vulnerability at all. It's a technique known as "session poisoning", which can be leveraged to exploit local file inclusion (LFI) vulnerabilities in PHP apps (not PHP itself). The only thing it has in common with CVE-2026-109618/CVE-2026-109619 is they both use the "PHP_SESSION_UPLOAD_PROGRESS" feature. And mitigation advice for both issues reference setting "session.upload_progress.enabled" to "Off". People are shoving loose details of the vulnerability into LLMs, the LLMs are keying in on the "PHP_SESSION_UPLOAD_PROGRESS" string, then generating session poisoning code that has nothing to do with the actual CVE. And because the people doing this have absolutely no idea what they're doing, they're confident enough to post their "proof of concept exploit" to GitHub and share it on social media. So if you see people talking about "session poisoning + LFI" it's likely their LLM hallucinated an exploit based on a 2018 blog by Orange Tsai talking about a local file inclusion attack vector. What's even worse is that "security researchers" are then using LLMs to triage these exploitation attempts, falling victim to the same hallucinations, then confirming there is ongoing mass-exploitation (there currently isn't). The actual real exploit is very difficult to exploit, and so far I've not seen anyone successfully get it working on more than a handful of PHP version with highly-specific configurations. LLMs are useful tools in the hands of skilled professionals, but for others, they're often just a Dunning-Kruger accelerator.

This is 100% correct when looking at it from a single-system perspective. ASLR does not create a significant barrier to successful exploitation. But when looking at it from a mass-exploitation perspective, there are a lot of hidden complexities that come into play. Vulnerability research is one of the few fields where you tend to make more money on the right side of the law. There isn't a huge demand for black market exploits. Most of the money is in bug bounty, working as a vulnerability researcher, or selling to grey-market exploit brokers. This means that even the smallest bit of added complexity can take a vulnerability from 'cybercriminal free-for-all' to 'unlikely to be widely exploited'. Mass-exploitation events are almost always preceded by someone publishing fully-weaponized point-and-click exploit code. It's extremely rare for criminal groups to successfully develop exploit for higher-complexity vulnerabilities on their own, even with AI. So, less researchers capable of exploiting the bug means less chance of a working weaponized exploit being posted online. But also, the increased difficulty of exploitation, thus increased time/effort, discourages those who can exploit the bug from giving it away for free. There's also per-target variability (which I don't know for sure is the case with this bug). But with more complex bugs, it'll sometimes be impossible to make universal exploits. In extreme cases, attackers may need to build exploit for each specific system or software version, or each specific config, or maybe even both. So, while it's correct that it's not hard to find an ASLR bypass, it is difficult to find a bypass that works reliably at scale. So far, most of the working exploits I've seen are limited to just a handful of PHP versions, or bruteforcing ASLR. And that makes all the difference when it comes to the risk of threat actors spraying exploits at the entire internet. For this specific exploit, the honest answer is, I don't know. It's above my pay grade. But I'm almost 100% certain that the level of bad this will be will be directly dependent on what kind of exploits security researchers make public.

Current information I have on php2Shell: - The RCEs requires the attacker to obtain memory addresses which are typically protected by ASLR. - I suspect the original author (lcfr_hax) likely has a reliable exploit which leads to stable code execution. - Most of the PoCs being posted are completely non-functional AI slop. - There is at least 1 working non-slop exploit being passed around, but it's reliant on bruteforcing for ASLR bypass, so not particularly impactful. - Rumor of ITW exploitation are patchy. There are attempts being seen using the non-functional leaked RCE, or variants that are config / system specific. - Some rumors point towards a known-working exploit being used by threat actors (I've personally confirmed this specific exploit works, but the ASLR bypass technique is unreliable at best and massively limits the potential impact). - I'd expect heavy ITW exploitation in the next few weeks based on how many people are looking at this. Though, success rates will vary heavily based on the specific exploit chain.