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.

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.

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. Weird

> 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

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.

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.

>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?

I immediately saw the Ghidra one and was thinking: huh?

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.

I mean, that's how people get hacked. If vlc crashed on my computer, and every day I should raise thanks to my gods that I do not use vlc, I would immediately unplug it and thoughtfully consider the circumstances under which it would be safe to turn it back on.

Yes, big pet peeve of the new world. Every em dash is apparently an AI trigger. Back in my day, they were a sign of great respect within my people.

Those aren't even em-dashes and yet there's a huge thread talking about them.

..."and for the love of God, don't use M dashes when you write it"...input goes on for an hour droning about slop...

Repo claims

> A single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.

Which is roughly the definition of zero day. Whether the contents of the repo reflect the above claim is something else entirely.

RCE has no meaning either in these situations. The "remote" part is usually an ssh root session if it means anything at all.

I'm an OSS developer and I've received three "CWE" alerts in the last two weeks. While they were all valid, they were for very trivial things like "this debug logfile could overwrite a file if it were a symlink" and "if a user is able to put OSC screen codes into the Git output they could write arbitrary data to the screen"

These AI models are making *everything* sound like an exploit. Not sure if this is good for the ecosystem. It makes me question everything that comes in more carefully. Is this a real exploit, or someone farming for karma to claim "I opened 39 CWEs in the last week. Hire my 'security' company to audit your code."

This is not what I heard from folks who worked directly with mythos. I was told that the vulnerabilities it generated were largely real and meaningful.

> a flurry of this sort of stuff as the AIs get smart enough to find them.

I really think this characterization is misleading. It's not "getting smart", only more tailored toward a specific usage, better curated dataset, better harness, better prompts, better labeling of results, documentation of failures and success, etc.

The outcome is (hopefully) overall better but this anthropomorphized wording makes it sound like AI itself is somehow changing or evolving. No, both academia doing fundamental research, industry making it available commercially, and finally security researchers making the entire tooling and process packaged as a service are actively shaping it to make it better. There is no "it".

> It will naturally die down as the legitimate ones are fixed.

Seems like we're already in the middle of this phase, but rather than dying down, the 'reports' have just gotten more noisy and obtuse, making it more difficult to establish the actual degree of threat / attack vector.

> It will naturally die down as the legitimate ones are fixed.

Every software update introduces and reintroduces them

Honestly execution complexity is over time becoming a lower and lower barrier too.

The old book didn't say "... maliciously." though?

I disagree. That FFmpeg code execution is absolutely nasty

all vulnerabilities are just bugs.

Then, don't rush and take a few minutes to set up a virtual machine.

You can just download the zip over HTTPS

Yea, that's what's confusing. some of these are like lower level slop but some are like genuine criticals.

Floci, libssh2, c-ares, FFmpeg, and the PHP one are all LEGIT./

The Ghidra one for example, not so much. I cant help but wonder if this was halfway completed research folder and they just published it as is

llms are fantastic disassembly partners, they're quite good at labeling functions from various dissassemblers -- the net losses from losing the benefits of open source , imo , outweigh the protection afforded by hiding your source code in yet another layer that is more and more easily unrolled through automated procedures.

Open source is a good thing, but I don't think what you are proposing is accurate.

A different way to frame this would be that those bugs would never be surfaced or exploited if the software were proprietary.

Presumably, one could let the bots loose on your own codebase first. The question is one of financing of course. If your end users are enterprises willing to pay for a support contract, they probably care enough about not getting hacked to endure the higher prices that would let you throw enough tokens at the problem. Other open-source projects might have a harder time.

I think LLMs might actually have a bigger effect on closed source software - the tedium saved on open source bug hunting is significant, but on closed source software the tedium of finding bugs is extreme because of all the reverse engineering, but LLMs will chew through that. So there's probably a lot of low hanging fruit.

> I don't know what methods where used to find these exploits but I am starting to think security through obscurity might not be a bad thing in this day and age, where someone can just let bots loose on your codebase.

I'd love to hear why you think obscurity is bad, if you now think maybe it's good in the LLM age?

I'd also be interested if you could describe exactly what or how you think security through obscurity works, or doesn't?

I've been thinking a lot about how to better teach this concept, so I'm looking to understand exactly how everyone thinks/understands how it currently works, or should work, or what it should do. I don't care about the "correct" answer, (I have ddg too :P) I'm interested in general expectations from SWE's that I might teach at work, instead of opinions of security eng speaking about theory.

But do people actually find these vulnerabilities on their own, or are they using LLMs? I was curious about how these vulnerabilities work, so I tried asking my dear friend Mr. CLAUDE, but he immediately threw an error and ended the session because it was a cybersecurity question. Enterprise APIs block even the analysis itself, so it's amazing that people can actually pull this off in practice.

le sigh, c-ares. Very predictable outcome. If you ever find yourself entertaining the idea that you will simply write non-blocking network protocol stacks in C with manual lifetime management, slap yourself. It doesn't matter if you think you are a super genius of unimpeachable taste. The job is impossible.

Why is that surprising? LLMs can churn out arbitrary volumes of "documentation" in an instant.

That seems trivial for an llm to provide.

We need our infrastructure to stop treating bank account numbers and social security numbers as secrets. At least in the US, bank account numbers appear on physical checks and are required to be shared in order to do an ACH transfer, and a social security number is not supposed to be used as an identifier (unless to the Social Security Administration itself) or as a secret password.

Ideally, nothing nefarious should happen if both of them were listed and queryable publicly.

You all need a better system than US SSNs

You can buy your SSN for $6-$10.

Firewalled VM, locked-in keyboard/mouse, 1 query to any agent and it's setup.

... support cash, tell your neighbors

>I've been a skiddy, he would have believed this. Thankfully, I've grown a bit, and can see this for the transparent, "I'm angry and want to hurt others so I will feel a little less alone", it actually is

Please name the "victims" here.

I'm genuinely curious, have you ever had actual, direct threats to your safety before, as a person? As in, murder, torture, false imprisonment, or other __likely and credible__ threats of grave bodily harm?

> but as someone who's joined the blue side

Are you somebody who separates "cybersecurity" from say: military intelligence poisoning one of your employees, sending them to a hospital which is already compromised, before sending back their new asset into your very "secure" company?

While i can follow your path, maybe because i see the same, i sadly have seen in groups of friends how this can go sideways very fast. If you report things, some companies gone treat you as a criminal/offensive actor and even go legal actions against you even you just tellem here you got this vuln.

Sure you than can do it anonymous and so on but point is : its not like every actor that gets notified will react thankful to it. Some even just ignore it.

User/admin discretion for software they use should be a big factor, sometimes getting burned is how you learn to play with fire. Or decide that having your data/participation disrespected means you need to set harder boundaries. My solution is to try things in isolation, run very few services, try to avoid becoming dependent on the online, appreciate the offline and local first.

How bad are your security practices that these tiny obscure things matter? None of these findings that show up here on HN should even make you flinch. The alarmist takes on this stuff is fucking exhausting and I'm tired of security teams bugging me about it. Do your job and this shit doesn't matter AT ALL.

Yep and typically none of this is meaningful unless you have no security practices at all. You can't have it both ways. Every security team says these things are all critical even though, for example, it's only being used internally. Cool, so you somehow have our network cert, are on site physically, have compromised a laptop fully without all of our tools detecting weird shit, have a password, admin access to the repo, somehow are spoofing MFA, etc etc. Yeah it all adds up, but as an admin I'm just fucking done dropping everything for these kinds of things.

No, the days start counting from the availability of a patch.

I've only heard it used as Retr0id's definition.

> A friendly reminder that a 0-day is a vulnerability that wasn't known until after a malicious actor exploited it.

No, the full name was always "zero-day exploit". The number 0 refers to the days between the vulnerability being known by the vendor and the public availability of the exploit. So the vendor has zero days to create a security patch before the release of the exploit.

The term "zero-day vulnerability" is a derived term to refer to a vulnerability affected by a zero-day exploit. Similarly, a "zero-day attack" is a derived term to refer to an attack carried out using a zero-day exploit.

wouldn't it be trivial to match the repo to the user logs?