LPE is in the title. And you sound like someone who doesn’t know what that stands for.

This also comes with a good public write-up on github (not some monetized fancy domain), with an explanation why it went public early, which wasn’t their fault.

There is a lot of intelligence insulting going on in the security theater industry, which is something I talked about here more than once, despite not being exactly a prolific commentator. But unfortunately for you, this particular case is one of the least offensive.

That may be true for private machines, but having user access to a machine, yet not be allowed admin rights is not actually a rare setup in the wild (read: servers… where the actual money is, not on that boring thing sitting under your desk)

It is a bit eye rolling “LOOK AT THIS DISASTER OF AN EXPLOIT!!!” *Requires physical access to the machine

But the major issue is that if you have some other exploit that gets you RCE or a shell you can then use these exploits to pwn someone and we have RCE’s and shell exploits come around all the time.

Desktop machines aren’t really the target of these kinds of attacks.

Also I think the author in this case seems to have been pretty reasonable about what they did. If more of these issues were done this way I wouldn’t have nearly as much irritation about “branded bugs.”

Every university with an https://en.wikipedia.org/wiki/High-performance_computing system or a lab with Linux workstations gives shell access to what amount to untrusted users. If antivirus or similar software on the system doesn’t proactively catch the exploit, it’s a bad day.

In the Node.js world adding a dependency may lead to arbitrary code being executed.

It’s bad enough on its own because a bad actor can steal SSH-keys this way, but combined with this exploit they will be able to install a rootkit and compromise your entire system.

Only every local file inclusion bug ever. Include shellcode, run as webserver privs, escalate locally.

Pretty much all those examples, but the real danger is chaining this exploit with others

Perhaps someone is sitting on a couple exploits to get them into a system, but only to an unprivileged user, this would be a great final act

• 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.
• 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.

Well, that’s reassuring - hopefully, since the patch for it is also described in the repo, distro maintainers can patch it quickly

works in bazzite which is fedora-based