6/27/2026 at 4:04:22 PM
I took a look at the Ghidra ones (because I use Ghidra), and I'm unimpressed: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...The first requires being able to overwrite binaries in the Swift tool directory. Yes, if you overwrite binaries executed by ghidra, you can trigger code execution. This is not a surprise.
The second, idk, I'm not familiar with TraceRMI (but it's probably worth noting that "RMI" stands for Remote Method Invocation).
The third is not a vulnerability in the slightest, they just demonstrate that native 7zip parsing code is reachable. Maybe there is a bug in the 7zip parser, but without that it's meaningless.
by Retr0id
6/27/2026 at 7:58:58 PM
A glance at the nmap one seems potentially high severity. It might be a nothing in practice, but it being around parser code means the chances of preparing something to jump around are pretty high.There'd be a certain irony being able to reverse shell anyone doing an nmap scan. If i had infinite tokens i'd throw claude on writing an exploit and dig through the history who made it possible because - if we take a moment to wildly speculate and assume it can ACE - this is the kind of bug an intelligence agency would love to have: Add a few ipv6 packets that then edit the trace being observed if the observer uses nmap / get access to any researcher pc who uses nmap.
by athrowaway3z
6/27/2026 at 5:42:35 PM
Was just thinking it would be hilarious if these were all known CVEs hiding the next Shai-Hulud inside of them and waiting to compromise security hobbyists rushing to download them.by ofjcihen
6/27/2026 at 5:47:09 PM
It wouldn't be the first time!by Retr0id
6/27/2026 at 6:57:50 PM
Ghidra one is pretty weak, but I checked out the ones that were interesting to me (c-ares, libssh2, ffmpeg) and they seem to all work as of the latest upstream commit. Weirdby newguy33
6/27/2026 at 5:20:42 PM
The Gitea one looks marginally interesting, but is probably not exploitable in practice (unless Gitea or whoever else isn’t properly isolating jobs on dedicated VMs). I suspect GitHub Actions has similar behavior and is not considered exploitable because the user is assumed to already have local, non-namespaced root access.by woodruffw
6/27/2026 at 6:18:18 PM
Gitea action runner has a bunch of different ways to setup and doing the isolation properly looks tricky. The documentation doesn't provide any isolation tests to administrators, either.The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users. Not flawless security, but it's something...
by Scaled
6/27/2026 at 6:29:36 PM
> The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users.This recommendation seems incompatible with third-party collaboration, at least on its face!
by woodruffw
6/27/2026 at 8:26:49 PM
Potentially, but for many projects things like that are tools that you want to control access to anyway. Anyone wanting to update the CI/CD process who isn't a trusted part of the project should be having their changes properly reviewed by someone who is anyway, at which point the reviewer is the trusted user not the random external entity.by dspillett
6/27/2026 at 8:54:07 PM
I don’t disagree with that, but I think GitHub has shown that projects want to have their cake and eat it too. GitHub has also shown that it’s incredibly easy to design an insecure CI/CD that satisfies that goal, but I see that more as a symptom of them being first-to-market rather than an inherent quality of the problem.by woodruffw
6/27/2026 at 4:57:34 PM
> Yes, if you overwrite binaries executed by ghidra, you can trigger code execution.> but it's probably worth noting that "RMI" stands for Remote Method Invocation
This reminds me of someone submitting a (clearly vibecoded) vulnerability report claiming to have found a way to execute arbitrary SQL. The project in question? An SQL server... https://github.com/tursodatabase/turso/pull/4322
by andrepd
6/27/2026 at 5:06:53 PM
I'm no expert on any of these programs, but that's kinda the problem, isn't it? No single person is an expert on every codebase supposedly exploited in this repo.After a bit of research, the Firefox one seems plausible to me. But, I haven't actually tried the POC. The explanation about the private-data and untrusted-input flags is plausible but I'm not an expert on Firefox's internals, maybe that's not actually how it works.
This just sucks, all around. Are we going to need every open source project gawking at the same repo full of stuff that has nothing to do with them, on the off chance that someone discloses a vuln that does have to do with them? Is this some kind of performative complaint about high friction in responsible disclosure? Well great job dickhead, you've just made a system that's even worse. Nobody benefits from this. Yuck yuck yuck.
by ryukoposting
6/27/2026 at 5:20:47 PM
I actually prefer them being public than in some governments or corporations toolboxby trinari
6/27/2026 at 5:59:31 PM
> Nobody benefits from thisDisclosures always enable more secure software to theoretically exist,
even if nobody follows through creating it.
They often do.
by DANmode
6/27/2026 at 6:20:10 PM
>The first requires being able to overwrite binaries in the Swift tool directory.Does it? Or does it need to be in the same directory you invoked ghidra?
by charcircuit
6/27/2026 at 4:49:38 PM
I immediately saw the Ghidra one and was thinking: huh?by skerit
6/27/2026 at 4:57:24 PM
The bigger takeaway is someone that smart is pissed off and dropping their shit with zero warning... but hey, that's just like, my opinion man.by firefax
6/27/2026 at 4:58:35 PM
You don't need to be pissed off to decide that immediate public disclosure is the best option.by Retr0id
6/27/2026 at 5:26:06 PM
Ok, I don't know their emotional state. Fair point.Maybe I'm projecting my own biases ;-)
by firefax
6/27/2026 at 6:13:15 PM
Meanwhile, some dude was just playing with claude and accidentally made his repo public.by b112