Kevin BeaumontThere's serious panic being caused by AI discovered vulnerabilities behind the scenes, where those finding them are basically using them as marketing. Automated vulnerability hype train again, basically.
A thread on a few of them.
CVE-2026-34486 - Tomcat
- Only exploitable if a certain feature is used, if its endpoint is reachable and if port 4000 is available. It's pretty niche.
CVE-2026-42945 - Nginx (otherwise branded Nginx Rift)
It relies on a specific Nginx config to be vulnerable, and for attacker to know or discover the config to exploit it. To reach RCE, also ASLR needs to have been disabled on the box.
The PoC they've built specifically disabled ASLR, deploys a specifically vulnerable config and the exploit knows about the vulnerable config endpoint.
I will likely be one of the first people banging the drum to patch and mitigate if any of the recent AI vulns results in serious harm. Otherwise, keep calm and carry on patching as usual.
Regarding CVE-2026-42945 in nginx - no modern (or even old) Linux distribution runs nginx without ASLR.
The way the PoC exploit works is they spawn nginx like this:
> exec setarch x86_64 -R /nginx-src/build/nginx -p /app -c /app/nginx.conf
Setarch -R disables ASLR. I've had a look through Github and I can't find any other software which actually does this for nginx either.
So, cool, sweet technical vuln - it's valid - but the RCE apocalypse ain't coming.
SaThaRiel 
@GossiTheDog If I got it right, they have a working PoC for ASLR enabled systems, but holding it back. Sure it requires more (probably a lot more) requests for success, but seems possible.
Or, like with many of the exploits today, its just a marketing stunt. Sadly you never know.
Fellows@GossiTheDog plus, don’t they need to know exactly which rewrite url to request from the server that would actually trip the vuln?
floyd aka floyd_ch@GossiTheDog hmm, depends on how good the ASLR is, I can tell you a couple of years ago it was quite bad on certain platforms, so with a systemd restarting nginx service you get a lot of tries over time (although of course nginx logs will scream) and that was enough to brute force ASLR (actually just retrying until that byte random matched what was in the exploit). I'm not deep enough into modern 64bit ASLR, I just remember the one on ARM being bad. Still niche probably
nyanbinary
FC@GossiTheDog and that's why I'm here. Thanx for keeping us calm.
draeath@GossiTheDog ... also never turn off ASLR! Why would someone do that nowadays!?
Lily Star@GossiTheDog Copy Fail and Dirty Frag are pretty serious.
Bit Regurgitator
Will Dormann@GossiTheDog
(except fewer)
(except fewer)
Otte Homan - remember Geordie@GossiTheDog sounds a little ... esoteric ?
Andrew Golding@GossiTheDog this particular defect-leading-to-vulnerability according to F5 can be mitigated by using named parameters instead of numbered in the rewrite regex replace expressions.
I don't think the conditions that expose the issue are too terribly unusual as this is the sort of thing that would be done if one wanted to, say, wrap an older HTTP API with semantics that use path parameters.
The defect also impacts the NginX Kubernetes Ingress Controller.
Andreas> Theoretically, we could leverage this design to leak ASLR by progressively overwriting pointers byte by byte. In this post, we discuss the exploitation technique assuming ASLR has already been bypassed.
Based on that ASLR is "just" a nuisance and not an actual show stopper 🤔
https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability
NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability | depthfirst
We used the depthfirst system to analyze the NGINX source code, and it autonomously discovered 4 remote memory corruption issues, including a critical heap buffer overflow introduced in 2008. We further investigated the exploitability of the issues, and developed a working proof of concept demonstrating RCE with ASLR off. If you use rewrite and set directives in your NGINX configuration, you're at risk.
Seth Mos@GossiTheDog could this one be related to the Palo Alto captive portal authentication ?
brib 
​ 
@GossiTheDog I spent way too long figuring out how I needed to respond and now I'm annoyed at these vendors.
Admittedly I've been annoyed at these vendors for a while, it's one thing to use AI to discover vulns and another thing to use AI to create terrible writeups that are wasting everyone's time (this was an issue with CopyFail too)
If every slop receiver could bill the slop sender for the extra time taken trying to parse this stuff I think companies would think a lot harder before sending slop out
Mike Siegel@GossiTheDog while they can certainly find some fun things, a number of the "vulns" are ridiculous "Oh this can be an RCE during full moons with ASLR disabled running on TRSDOS ported to ARM."
The models don't really threat model well at all. I like @bagder 's approach of VULN-DISCLOSURE-POLICY.md
Misuse Case@GossiTheDog I really want to hear your take on this because I’ve heard conflicting things about whether any of the vulnerabilities are serious or not.
Tero Hänninen@MisuseCase @GossiTheDog most of the stuff is just pure marketing fluff. Sure, AI is finding bugs. People are fixing them. This has been the case for a while now. Nothing new. Exploitable bugs still very rare. Catastrophic ones like Heartbleed nil, so far. It’s business as usual. The noise volume is up, quality of the signal seems about same as always.
@0xtero @GossiTheDog Meanwhile
1. AI coding agents are one of the factors contributing to shorter intervals between “vulnerability discovery” and “working exploit”
2. Orgs can’t be bothered to patch known vulnerabilities in a timely fashion so a huge proportion of cyberattacks and their associated damage are down to bugs that have been known about (and left unpatched) for half a year or more
@MisuseCase @GossiTheDog For sure. But the "from vuln to exploitation" trend has been clear downward slope for years now. (https://zerodayclock.com/). We're seeing a high volume of vulns and bugs, but I feel lot of it ends up being low, medium severity, because it's hard to exploit in real conditions. Fixing these vulns is good - but the marketing messages don't quite map to reality I feel (when do they ever..)
@0xtero @GossiTheDog I know about the zero day clock and part of the reason it looks like that is that people who have some idea what they’re doing (not script kiddies, though that may change) can use AI coding agents to develop exploits faster than they would otherwise.
So that part is real, or uncomfortably close to it.
Space Invader@MisuseCase My 2¢: like any vuln, it’s serious if you have exposure to them and not serious if you aren’t. CVSS scores are just a starting point and not the be-all-end-all.
I’ve handled both AI and human reported vulnerabilities, and a recent human-discovered one had the highest CVSS score I have personally issued, but required a unique configuration. An AI-reported vuln had a lower score but was more likely to be present.
Seriousness requires context to determine.
I’ve handled both AI and human reported vulnerabilities, and a recent human-discovered one had the highest CVSS score I have personally issued, but required a unique configuration. An AI-reported vuln had a lower score but was more likely to be present.
Seriousness requires context to determine.
@spaceinvader Stuff like this is why CISA’s Known Exploited Vulnerabilities (KEV) list is so important. I think CISA still maintains that but CISA being decimated means it can’t weigh in on issues like this just when we need it most.
@MisuseCase Yeah, the KEV is still being updated AFAIK. But I don’t think I’d rely on that too much, because who knows what’ll happen to CISA next.
I am glad to see bugs being surfaced and patched. This industry likes big splashy things and doesn’t seem to respond as well to the effort it takes to build, maintain, and test. Compared to bridge building—which humans have done for millennia—software is in its infancy. There just aren’t the same standards around how to really build software well.
@spaceinvader The irony is that AI coding and scanning tools could potentially make us much better at building software by detecting vulnerabilities before code ships to production, but AI is not being hyped for that aspect of software development and it’s also got a credibility issue because of how it *is* being hyped.
Bert Driehuis@MisuseCase @spaceinvader so far I've not seen any evidence that AI is doing much for code quality -- quite the contrary in fact. As productivity (and burnout) soars, the seniors have no cycles left to weed out even the low hanging vuln fruit. The juniors have no way to know what is low hanging fruit. And the folks in between, well heaven knows how they will ever become senior other than by outliving the seniors physically.
@bertdriehuis @MisuseCase it depends on how you use the tool. Outsourcing all thought and creation to AI is almost certainly going to cause issues. Having an AI vulnerability finder take a pass before release can be akin to running code through a fuzzer. Letting the LLM fix issues may fix one bug at one time, but isn’t a holistic approach to fixing a codebase.
Managing burnout and upskilling jr devs was a concern before LLMs. Orgs that fail to recognize and manage that will fail regardless.
Managing burnout and upskilling jr devs was a concern before LLMs. Orgs that fail to recognize and manage that will fail regardless.
Robin Syl 🌸
@GossiTheDog I already feel so "boy who cried wolf"ed about all the vulns
Matt Palmer@GossiTheDog I'd be willing to bet that if they paid real humans the same amount of money as the true cost of running the LLM, they'd find more and better bugs.
redsakana@GossiTheDog All this feels like a good demonstration of the statement that AI companies tend to have little in the way of a moat. So you have cookie-cutter LLM-linter startups trying to stand out from the vast ocean of cookie-cutter AI startups by dropping a "0day RCE", no matter how silly, with maximum splash.
seepr@GossiTheDog Litany of Gendlin:
What is true is already so. Owning up to it doesn't make it worse. Not being open about it doesn't make it go away. And because it's true, it is what is there to be interacted with. Anything untrue isn't there to be lived. People can stand what is true, for they are already enduring it.
Finding security issues is good in general for the advancement of humanity. Can we ever reach 100% security with the way our systems are designed?