Cybersecurity challenge: be nice to each other [IMPOSSIBLE]

you will need it after you're done reading | src

You don't have to look for 0-days in open-source right now. And most definitely, you don't have to immediately publish exploits for them. It is OPTIONAL, heck, i'd say that as far as RFC 2119 is concerned, it's currently NOT RECOMMENDED. And you're sure as hell not "helping" anyone by doing it - let me explain why.

The background

It's 2026, and the use of GenAI for "security research" is in full swing. I won't debate whether that's a good, or a bad thing - I'm merely stating a fact. By now, a lot of the "low-hanging fruit" has been already found and exploited, and some of it even got fixed!

From their own perspective, security researchers are doing the lord's work: ensuring that everyone is safer, and that no security bugs remain to be fixed. It's a win for them (free press!) and win for everyone else ("no more bugs!")

Except, the reality is much sadder

In the past few weeks, server hosters have experienced an unprecedented influx of 0-days published against core infra components. The Linux kernel saw several Local Privilege Escalation (LPE) bugs discovered in rapid succession. Other large projects such as nginx, dnsmasq and qemu suffered a variety of issues ranging from information disclosure (bad) to remote code execution and sandbox escapes (very bad). And other than how quickly those issues emerged, all of this wouldn't sound that much out of the ordinary. However, virtually all of those reports had either first-party exploits provided immediately, or 3rd-party exploits published before the embargo period lapsed. Comparing this to the previous status quo of over 90%¹ of high severity security bugs having no public exploits #1
stats out of my ass, but i've browsed through enough CVEs that had no entries on exploitdb to know how it is ever, what we have right now is nothing short of horrifying.

Clout-chasers

A bunch of companies specializing in broad "security research" figured out that publishing sploits is a great way to get free press. On May 14th, v12sec posted a hash for a file called qemu.c on their twitter account. Just one day later, they published the vulnerability details, including a PoC. Some comments:

Posting a hash for "qemu.c" already draws attention to the project. This Sucks. Don't Do That.
The only reason to post a hash beforehand is to "lock in" your findings, proving that you had them very early. Doing it a day before you publish the full thing is laughable, you might as well not do it at all.
Their disclosure (both on twitter and github) VERY CONVENIENTLY avoids mentioning how the exploit needs a CXL-based 'memory-backed-ram' device, which is NOT loaded by default in any of the default qemu setups. In clear words: most hosters weren't vulnerable, but the disclosure is worded like everyone was.

Picture 1 - you can tell they're real pros because they committed a random qemu-system-x86_64 binary + a bunch of ROMs entirely unrelated to the exploit

Who In The World is algif_aead??

(rhetorical question; don't answer, i can't really hear you from here)

Kernel bugs are some of the scariest. I rely on the POSIX permission system (users and groups) for controlling levels of access on my servers, and discovering that local users can now read/write all files (or worse, execute code as root) is always a recipe for a bad time. Even worse, with kernel bugs, you can't just automatically apply patches - a reboot is required.

... IS WHAT MOST EXPLOIT DEVELOPERS SOUND LIKE. In reality:

Most recent Linux 0-days targeted specific kernel modules that could be unloaded (if they were even loaded in the first place!), and later denylisted.
Most of those modules were only used in very rare hardware configurations; IPsec support modules were an exception, but even then only a fraction of Linux system used them.
Most of those vulnerabilities depended on module load on demand; This behavior can be disabled using sysctl kernel.modules_disabled=1
A mitigation like this isn't anything new. Debian has been doing something similar at least since 2013.
heck, with emergence of "cloud computing", linux servers generally² have #2
stats out of my ass again, but. come on. I envy you if you haven't seen modern deployment horrors. one user (with sudo perms), or even just root. LPEs target the minority of shared servers and pubnixes, maybe a CI runner host. In virtually all other cases, there's nothing to escalate to - you're already effectively root.

Out of several recent kernel 0-days (I've lost count), so far only one pertained to built-in kernel functionality. Everything else could be mitigated without rebooting, either by playing whack-a-mole on vulnerable modules, or by disabling autoload altogether.

# illustrative only install algif_aead /bin/false install esp4 /bin/false install esp6 /bin/false install rxrpc /bin/false install xfrm_user /bin/false install xfrm_algo /bin/false install authencesn /bin/false install rds_tcp /bin/false install rds /bin/false Figure 1 - /etc/modprobe.d/eh.conf is a great way to monitor your sysop's mental health ahead of the inevitable burnout

As someone essentially hosting a pubnix, I'm more affected by this madness than the average sysop. In the past decade, I've only had to disable user SSH access to sakamoto for more than a few minutes once: a week ago, in response to one of those sploits.

Carrot disclosure

If dropping exploits for 0-days left and right wasn't bad enough, some people went as far as to invent entirely new ways of vulnerability disclosure. Introducing carrot disclosure (IA link to author's webpage) - in his own words:

> Carrot Disclosure, dangling a metaphorical carrot
> in front of the vendor to incentivise change. (...)

One paragraph further, he dropped logs from what looked like a Forgejo 0-day exploit.
Some remarks on this:

It's not "a vendor", Forgejo is a community project! Don't use slurs like that!
Forgejo is one Gazillion lines of code. There are larger projects, but it's certainly not small. Best this can do is give the security team a small heart attack, not "motivate them to make an audit"
This is genuinely one of the most anti-social ways of handling a vulnerability disclosure I've ever seen. Not in the spirit of OSS at all.

Why the hostility? Apparently he tried working with the team, but then couldn't accept no for an answer and turned against them in the worst way possible. Still, to his credit, several days later he cycled back on the carrot, and disclosed the issues in private.

... and the vulns, you ask? The largest one he fearmongered about turned out to be a nothingburger requiring the attacker to know an instance-specific INTERNAL_TOKEN. And the only way to acquire that token was to... already have it? It's bizarre.

But... What if we could do even worse?

Open your search engine of choice and search for "CVE-2026-27771". It'll turn up a plethora of believable-looking writeups, even some ready to run exploits! Apparently it concerns over 30k gitea instances, and allows an attacker to access "private container images".

Except. Gitea Private Container Registries do not exist. It's not a gitea feature, never was a Forgejo one either. This thing is ENTIRELY hallucinated. Their "temporary stopgap" measure just enables login for all views, including the API, which is rather Baffling.

What the hell is going on!?

Reality check

While browsing the comments under one of the disclosures (I know, my bad), I stumbled upon this stinker exchange:

Picture 2 - twitter exchange > The exploits will continue until all the vulnerabilities have been patched

... NO!! That's NOT how software engineering works! A bunch of people who don't know any better, with a newfound ability to "talk" to a computer, sending an avalanche of reports to open-source maintainers will not magically end security issues. It'll burn the maintainers out. Everyone who wrote a non-trivial amount of code knows this. Suggesting that we'll ever have the capacity to find all bugs, both existing and upcoming is really silly.

> Careless coding will no longer be tolerated :)

First of all. Fuck you sideways for that smiley. Your people are creating Hell on Earth for poor souls who host anything accessible publicly, with a 2nd ring dedicated solely to fucking over maintainers with tight "responsible disclosure" times. AND YOU'RE SMIRKING AT THIS SITUATION!?³ #3
was this bait, or is the author that much of a twat? after reading too many similar takes, I'm inclined to believe the latter.

Secondly. This sentence implies that techbros gained the ability to solve a social problem with tech, which is something I'd heartily laugh at... if it wasn't so depressing at the same time.

There are dozens of exchanges like the one above. Even if I could, there's no point in analyzing all of them. People writing stuff like this are severely out of touch with reality of what exactly they're doing, and how beneficial or harmful they're being. For them, this isn't a "disastrous amount of 0-days, each one disclosed worse than the previous one, not leaving any room for safe patching, contributing to burnout all across IT as a profession" - in their worldview, it's an "important piece of work that has to be done by someone, to better the overall world cybersecurity". It's a very naïve perspective, but it's rooted deeply in their core beliefs.

Conclusions

This post isn't trying to advocate for "responsible disclosure", as in my opinion it's fundamentally incompatible with open source as a concept: the patch needs to land in the source tree sooner or later. GenAI seems to have dismantled the barrier of going from a secfix commit to exploit, and script kiddies took notice - that's what's really happening. We're learning what should have been already obvious: if everyone can get an exploit, someone will mishandle the situation and publish it immediately.

What are the workarounds? We definitely shouldn't normalize distributing binary-only hotfixes - that's how you get sneaky backdoors. Hiding a change in a larger commit is ALSO how you get backdoored (see the xz fiasco). Withholding the patch from the public as long as possible hugely benefits corpos with support contracts, and does relatively little for normal users, unless maintainers work very closely with distros - which, from personal experience, happens rather rarely. There are more strategies, but every one I thought of had some caveats - plus, I don't believe there is a one-size-fits-all mitigation strategy this time.

The real solution would include getting more people to understand that the story doesn't end when you publish a PoC. That's merely the beginning. Rushing the disclosure isn't cool. Rushing the maintainers... reprehensible.

Really, I just wish security people were better about this. Collaboration is a huge part of why OSS could flourish and grow in the first place. Now, thanks to a bunch of people who fundamentally misunderstood what "collaborate" even means, we're at risk of losing it all.

I really hope I'm wrong about this.

Notes

1 - stats out of my ass, but i've browsed through enough CVEs that had no entries on exploitdb to know how it is
2 - stats out of my ass again, but. come on. I envy you if you haven't seen modern deployment horrors.
3 - was this bait, or is the author that much of a twat? after reading too many similar takes, I'm inclined to believe the latter.

Thanks to jn, ari, Eloy, famfo, Multi, mei, Lili, Riedler, Jana, BluRaf, elly, kleines Filmröllchen, and Gusted for proofreading and providing feedback. (c-c-c-combo breaker!)