Cybersecurity challenge: be nice to each other [IMPOSSIBLE]

domi's webpage

Main

Weblog

Floppy

Pick-a-font:

IBM VGA8

Monospace

Chinacat

Sans-serif

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%1 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 generally2 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<br>install...