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.
I also have a library of bugs I found using Claude Opus 4.8 through the Customer Verification Program. Undisclosed, Atp I dont even know if they have been found by someone else. But just like this repo
Theres a bunch of very specific scenario DoS bugs, buffer over/ underflows, that will get caught by ASLR and whatnot
When I report serious ones, mostly the devs will respond with something like, yeah, thats how we designed it in a dangerous way, so that the layer above or below can solve the issues, and other footgun stuff.
0-days-vibes-vulns? There should be a new category, for spotting and handling the em-dashes of this brave new world of vulns and making the old fossils like me only picking my head up for the old painfully still hand-crafted artisanal ones instead. A kind of label, like free-range for eggs, in sum.
Are they all actually 0-day? I think a lot of them are from disclosed CVEs/code that were already fixed upstream. It often seems like the term "0-day" has lost most of its meaning today and people often use it to refer to any exploits.
> 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.
There is going to be a flurry of this sort of stuff as the AIs get smart enough to find them. It will naturally die down as the legitimate ones are fixed. Yes, there will always be some level of this, but I’d expect it to be low and the exploits found to be increasingly complex. This is a time of transition.
What if this person is from an AI lab that really wants the govt to keep suppressing Mythos/Fable & GPT5.6? It's what I would do, the timing couldn't be any better.
I think people may miss the point of a repo like this. Individually these are small puzzle pieces that can't do anything. Put them all in one place and it becomes easier to pick up pieces and try them together to see if they fit and build something bigger. Get enough pieces to fit together and you actually have something. This is the 'FOUO' idea in security. Enough open information gathered together in one place crosses the boundary from 'just public info' to 'secret stuff here!'. Now we have automatic puzzle solvers (coding assistants) a repo like this becomes a lot more meaningful.
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.
trying something new? this is interesting. the problem is that submitting reports is too slow. if you find one then your not supposed to share. but then over the next 90 days you learn no one cares and 13 other people submitted it before you, 43 after. maybe better that we just know. so we can run code we can trust sooner. zero is the proper number of dependencies. otherwise assume its broken.
I'm going through each one, and it's fascinating to see things like this. The UAF principle in c-ares is really interesting.
The problem ultimately came from not being able to prevent stale pointers. The attack works by figuring out the size of the stale pointer, then spraying memory with data of the same size, and finally achieving RCE (Remote Code Execution). How do people even come up with ideas like this?
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.
Most of the exploits are for opensource/free software.
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.
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.
And isn't it also mostly a transitioning issue. Those open codebases will be constantly scanned for potential security issues and getting more and more hardened.
There are probably a lot of easy wins that are going to be discovered over the next few years but it should taper out after a while.
I don't think that's exactly it. OSS only needs someone to have a strong LLM to check for bugs. If your software is proprietary, it's a competition between just you and whatever model you have vs any attacker and whatever model they can lay hand to.
Um, the nginx binary would have to be in the hands of hundreds of thousands of server operators. And the set of server operators is rich in the kind of person who would attack it. Not to mention the huge number of leaks you'd get.
Maybe if it's some server-side software that you only use yourself...
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.
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.
> 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. I do this so to allure people into the field, and I've always found this is the most efficient way.
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 don't feel alone", it actually is.
I'm sorry you're so angry dude (me too), but as someone who's joined the blue side, we'd appreciate it if you gave us some kind of heads up, the bad guys generally have a lot more time to scroll for new payloads than I do. Not all of us deserve the kindness of a heads up, but every single one of our users deserve it. Don't punish them because you're mad at someone else.
You can flex on the idiots you're trying to flex on, without hurting people. Even an email to security@[that_project_domain] saying "hey, I've published these" would move you from the group of people I see making the world worse, into the group making it better. (You don't have to, obviously, but making the world worse wont make you less angry.)
A friendly reminder that a 0-day is a vulnerability that wasn't known until after a malicious actor exploited it. If someone publishes a PoC, it is not a 0-day, just a vulnerability.
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.
I also have a library of bugs I found using Claude Opus 4.8 through the Customer Verification Program. Undisclosed, Atp I dont even know if they have been found by someone else. But just like this repo
Theres a bunch of very specific scenario DoS bugs, buffer over/ underflows, that will get caught by ASLR and whatnot
When I report serious ones, mostly the devs will respond with something like, yeah, thats how we designed it in a dangerous way, so that the layer above or below can solve the issues, and other footgun stuff.
0-days-vibes-vulns? There should be a new category, for spotting and handling the em-dashes of this brave new world of vulns and making the old fossils like me only picking my head up for the old painfully still hand-crafted artisanal ones instead. A kind of label, like free-range for eggs, in sum.
Are they all actually 0-day? I think a lot of them are from disclosed CVEs/code that were already fixed upstream. It often seems like the term "0-day" has lost most of its meaning today and people often use it to refer to any exploits.
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.
There is going to be a flurry of this sort of stuff as the AIs get smart enough to find them. It will naturally die down as the legitimate ones are fixed. Yes, there will always be some level of this, but I’d expect it to be low and the exploits found to be increasingly complex. This is a time of transition.
Pretty unimpressive as security vulnerabilities. It would be better to just say these are simple bugs for the most part.
What if this person is from an AI lab that really wants the govt to keep suppressing Mythos/Fable & GPT5.6? It's what I would do, the timing couldn't be any better.
I think people may miss the point of a repo like this. Individually these are small puzzle pieces that can't do anything. Put them all in one place and it becomes easier to pick up pieces and try them together to see if they fit and build something bigger. Get enough pieces to fit together and you actually have something. This is the 'FOUO' idea in security. Enough open information gathered together in one place crosses the boundary from 'just public info' to 'secret stuff here!'. Now we have automatic puzzle solvers (coding assistants) a repo like this becomes a lot more meaningful.
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.
trying something new? this is interesting. the problem is that submitting reports is too slow. if you find one then your not supposed to share. but then over the next 90 days you learn no one cares and 13 other people submitted it before you, 43 after. maybe better that we just know. so we can run code we can trust sooner. zero is the proper number of dependencies. otherwise assume its broken.
I'm going through each one, and it's fascinating to see things like this. The UAF principle in c-ares is really interesting.
The problem ultimately came from not being able to prevent stale pointers. The attack works by figuring out the size of the stale pointer, then spraying memory with data of the same size, and finally achieving RCE (Remote Code Execution). How do people even come up with ideas like this?
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.
I imagine this is a large open model like GLM5.2 etc
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.
Thank goodness I use a GC language
Most of the exploits are for opensource/free software.
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.
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.
And isn't it also mostly a transitioning issue. Those open codebases will be constantly scanned for potential security issues and getting more and more hardened. There are probably a lot of easy wins that are going to be discovered over the next few years but it should taper out after a while.
Fair point but it assumes we all have access to LLMs with the same capabilities.
I don't think that's exactly it. OSS only needs someone to have a strong LLM to check for bugs. If your software is proprietary, it's a competition between just you and whatever model you have vs any attacker and whatever model they can lay hand to.
disassembly only applies to client side software
something like nginx could arguably be more secure if it was closed source
(I am a proponent of and contributor to open source)
Only until a single server running nginx is hacked and the binary leaked though...
Um, the nginx binary would have to be in the hands of hundreds of thousands of server operators. And the set of server operators is rich in the kind of person who would attack it. Not to mention the huge number of leaks you'd get.
Maybe if it's some server-side software that you only use yourself...
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.
That's one way to do it.
A surprising amount of documentation if the actor was just LLM-dropping these..
Why is that surprising? LLMs can churn out arbitrary volumes of "documentation" in an instant.
That seems trivial for an llm to provide.
we have got to stop putting our bank accounts and SSNs on computers
Firewalled VM, locked-in keyboard/mouse, 1 query to any agent and it's setup.
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.
Hang on, can you actually do something nefarious with just the bank account number?
It’s quite ridiculous that we haven’t been able to build a modern identification system capable of replacing SSNs in the last 30 years.
... support cash, tell your neighbors
And Monero for online.
til you get debanked
Cash doesn't require a bank.
Banks are kinda useful to avoid getting robbed all your money, on a regular basis.
Many French people with crypto money experienced that the hard way recently.
"cybercrime is cringe"
> 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. I do this so to allure people into the field, and I've always found this is the most efficient way.
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 don't feel alone", it actually is.
I'm sorry you're so angry dude (me too), but as someone who's joined the blue side, we'd appreciate it if you gave us some kind of heads up, the bad guys generally have a lot more time to scroll for new payloads than I do. Not all of us deserve the kindness of a heads up, but every single one of our users deserve it. Don't punish them because you're mad at someone else.
You can flex on the idiots you're trying to flex on, without hurting people. Even an email to security@[that_project_domain] saying "hey, I've published these" would move you from the group of people I see making the world worse, into the group making it better. (You don't have to, obviously, but making the world worse wont make you less angry.)
A friendly reminder that a 0-day is a vulnerability that wasn't known until after a malicious actor exploited it. If someone publishes a PoC, it is not a 0-day, just a vulnerability.
No, the days start counting from the availability of a patch.
Open source is the best