Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin:
What is true is already so.
Owning up to it doesn't make it worse.
Not being open about it doesn't make it go away.
And because it's true, it is what is there to be interacted with.
Anything untrue isn't there to be lived.
People can stand what is true,
for they are already enduring it.
I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.
To address this framing directly: "a bug exists" is a different truth/state of the world than "the bug is known to exist", and that's also very different from "this bug exists and an exploit is readily available". So the transmission of information about the bugs does change the state of the world, and requires action.
As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state.
Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being completely unknown is better than being known to a few, but there is no way to ever know if that's the case.
From the outside, known to none and known to a few are indistinguishable, and thus both states are the worst possible case. The only remedy is to make the bug known to everyone such that it cannot be covertly exploited.
That's not the whole picture though. Bugs exist anyway. The only practical concern is, which are practically most likely going to be used among all these bugs that yes exist and included in production.
You've described states one and two as outlined above.
Whether a bug is exploitable is an entirely separate category of unknowable, because seemingly-innocuous bugs quite often have very deep and very subtle implications that when combined with another innocuous bug, result in an RCE or PE.
Therefore, it's sensible to treat all bugs as potential threat vectors unless and until proven otherwise. Which brings us full circle: state 3, all bugs being public, is probably the safest thing because nobody can know if a bug is in state 1 or 2.
It's sensible just as it's sensible to have invulnerable immune system.
Sure, who wouldn't like to have that? Such a thing is impossible to reach starting with the same reason as Gödel's incompleteness theorem is a thing, plus a gazillion of more practical constraints.
A bug existing or not for a person is a statement about that person's knowledge of the bug.
Is your assertion that, since you specifically didn't know about the bugs that nobody, not in Russia or anywhere else did?
Obviously if bugs are out there existing in software and you don't know about them, or the CVE system doesn't know about them, or whatever ... this does not preclude bad guys from knowing about them. In the era of agents, knowing the bug exists is equivalent to having a PoC, so the distinction completely collapses.
Arguably, the transition goes from - this bug exists but vendors ignore it because only criminals and intelligence agencies know about it to, this bug is publicly embarassing lets fix it right away.
Sweeping things under the rug is how we get insecurity. Sunshine is the best disinfectant.
> Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
Is this supposed to be hard to imagine? I can completely imagine this, especially if the mathematician is a celebrity in their field.
In theory, the vulnerability was always there, and it's better to find out than not find out.
In practice, how much effort it is to find vulnerabilities matters a lot. We're in a time where things that used to be quite hard are now easy and the rate of discovery will change.
This rate of discovery matters a lot -- for OSS maintainer burnout if nothing else.
It matters in a positive sense; it's a thing that enables you to make some predictions about the state of the world tomorrow. It does not matter in a normative sense; OSS maintainer burnout is strictly a less important concern than software security, which is an externality of software development.
> OSS maintainer burnout is strictly a less important concern than software security,
Burnout means that no more fixes come - ever - and that things sit vulnerable until everyone relying on that tool takes the time to build and switch to a replacement.
Maintainer burnout is perhaps the single biggest threat to the ecosystem right now.
That can't possibly be an argument for forbearing security vulnerabilities in software. It's an argument for prioritizing hypothetical flaws over real ones.
If these flaws are so important, users of open source (business or individual) need to pay up - literally. Pay the maintainers enough to justify spending the time on these things, including the opportunity cost of not working at other software jobs during that time.
Pay each maintainer an absolute minimum of $200K a year or shut up and do the work yourself - in a fork if necessary.
This comment should not be greyed out. I feel that we all forget this far too much. You've exaggerated it somewhat.
There is no right to demand someone does something for free, and we have gotten dependent on people doing things for free. We don't have to pay people but if we don't want to, then we have to be willing to do it ourselves. Otherwise it could go away at any moment and we have no recourse.
Stated differently -- the way OSS software is currently maintained and users are conditioned to behave, there is a capacity problem if the rate of discovery surges too sharply.
And if the capacity is overshot (which I believe is happening as we speak), users end up in extended states of being insecure.
I'm also one of the unwashed rabble who believes there is a large practical difference between a vulnerability that exists but isn't found and one that is widely known and exploitable.
There's two fallacious arguments encoded here. The first is obvious, that we should prioritize hypothetical future vulnerabilities and fixes over ones we know exist today. The second is subtler and more insidious: it's the idea that the goal of software is to ensure every package and project is viable, that everyone who wants to deploy it should be able to do so. The risks this attitude pose to users, ordinary people who have no agency over which software packages you use to serve their needs, are a pure externality. The idea that a project serving real human users might opt to compromise availability rather than putting people at risk is never even broached.
This is so far outside of reality that I can't believe I'm even commenting on it.
If you believe people don't use software that is unmaintained and hilariously out of date I genuinely don't know what world you live in or how to deliver the bad news to you.
Oh, I agree that today there's a general expectation that externalized security doesn't matter and someone will always come around to rescue you (and your unmaintained dependency) from disaster. I'm just saying: infinite free bugs is likely to disrupt that equilibrium.
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
I don't think anyone is saying that here.
I think the net result is "wow, we're going to end up a lot more secure in several months, but things are going to feel sucky because stuff just got A) way easier for the average bad guy, and B) way busier on the fixing side."
I think it's likely we end up with an equilibrium with a lower rate of bug discovery than we're used to, but we need to experience an above average rate for a long while first...
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Try binge-watching old Star Trek episodes, to see how Spock deals with the illogical 99.9% of humanity?
The article focuses on OSS, but closed-source software is at major risk too. Perhaps more.
It's gotten much easier to reverse engineer binaries in general, and security patches in particular. Basically, an LLM can turn binaries into 'readable' code, and then reason about said code.
That happens a lot though, even OpenAI is attempting to lock functionality (like computer-use, 2 weeks ago) behind a binary -- Mac only they said, no EU. I saw a guy crack it the same day, ported to Windows. There are many many things like Rive that use binaries, obfuscation and uglification has been the name of the proprietary game for a long ass time, with the only protection being an assumption that "nobody would go through that trouble", yeah an LLM would ralph loop through it all day long, and make what you paid good money for pretty much free for anyone to use whenever they feel like it, we're back to the the "you wouldn't download a car would you?" argument
My understanding is that decompilation into more readable code is an important step in building the path to an exploit.
This understanding may be incomplete or outdated (things moving very fast right now). I'd love to hear from a someone with more experience using LLMs to do binary analysis about the level of 'binary annotation' needed for LLMs relative to humans.
I had done a fair bit of reverse-engineering-jar-files in the pre-LLM era for various reasons. The biggest problem with decompiled java files was naming. The original variable names, class names etc were not retained and the decompiler would use some alphanumeric series. That'd make reading code very hard. Curious how the current LLMs are able to address this. Maybe it's able to figure out how the class, variable etc is used and name it accordingly. (All this is assuming the original code itself was readable because there are enough bad programmers)
I expect Java would be easy-mode for the AI, they already do quite well reconstructing C++ from ghidra output in my experience from when I wanted to know what damage formula some game was using.
As a reminder; your account has been shadow-banned, it looks like you got a little unlucky in 2016.
That makes sense. Java leaves metadata in compiled code to reconstruct better.
> your account has been shadow-banned, it looks like you got a little unlucky in 2016
I see. I wasn't aware. Thanks. I thought the two comments per day limit is for users with low karma. Anyway, I'm using that limit to push myself in being picky about posts to comment on and to improve the quality of comments.
Shadowbans are actually a bit more than that - your comments are invisible unless someone with a high karma threshold puts a little effort in to mark them as reasonable. People can't actually see most of your comments.
I'd recommend creating a new account. Or you could email the mods (I forget the email but it is publicly available somewhere) if the user name has sentimental value. In your case it is clear that a shadowban is inappropriate.
Clearly for commercial oriented opensource software, security through obscurity is one way to keep the pace in the short term. Not an option for proper open source software.
Will this be the case that people who use open source software that is easily detectable will also start to shy away from using them for the fear of zero-days?
One of the benefits of Open source has been that there are more eye balls on the source, leading to more secure code/better quality. I think given enough time the bug reports will plateau and we will be back to a normal cadence - once the tsunami is over, hopefully things will settle at a more manageable cadence .
I'm not sure that the benefit of many eyes helps here. So much of this bulk scanning is low-effort, and if you're a smart person developing closed source software you get the benefits of bulk scanning, but _at the time of your choosing_ .
OSS has always had tradeoffs and I sadly think this one is going straight to the "Cons" column. We still think the Pros outweigh the Cons, but this is NotGreat.
It's certainly possible to write optimizations that generate nondeterministic llvm outputs, but the docs explain conditions when that can happen, and warn against it.
I do not think author understands how opensource works. You have a problem on your computer, in __your__ software, and somehow some random dude is responsible for fixing it? Sure if you gimme a few kilo USDs I will drop everything and come to rescue you. But for free it is a volunteer gig I do once a month....
I dunno man ... I produced a few things that got a few github stars over the years.
At the risk of repeating myself -- this is targeted at other OSS maintainers, not random people who might have done a git pull of some random project a couple years ago.
I think this is going to play out in interesting ways. There's a saying in lockpicking: even if you can pick the lock, the easiest way in is usually a window. Distribution is core to a technology's market reach, and every distribution point is a window.
The strip-mining piece reads to me as one phase of a longer cycle — tech distributed → adopted → experimented with → misused → secondary protection market emerges. The 2017 S3 misconfiguration wave is a useful reference: Verizon and Booz Allen both spilled data through bucket ACLs with inadequate controls, AWS responded with Block Public Access, and the CSPM market matured to sell the discipline back. Mythos looks like the same shape at the AI layer — leaked via vendor environment chain (Mercor breach + contractor credentials + URL guessing), not code-level vulnerability.
The proliferation of high-quality security research the article points at reads to me as one sign of the secondary market forming as the primary disruptive technology stabilizes — Gartner already has AI governance spending crossing $1B by 2030. And it seems to be landing on OSS first because that's where the surface area and public exposure are, which is what the labor pressure is documenting. Cascade to closed source seems likely as the compression between vulnerability-introduced and vulnerability-identified continues, just on a lag and behind NDAs.
The OSS side could go either way under that pressure, and I don't know which dominates. FFmpeg slowed in 2024 from overload and got rescued by Germany's Sovereign Tech Fund — pressure converted into hardened posture. Ingress-Nginx retired November 2025 after two maintainers couldn't sustain it on weekends, despite running in ~50% of cloud-native environments — same pressure, no backing. Tracks institutional backing more than anything intrinsic to OSS.
The wrinkle Mythos adds: same product is both weapon and salve. Pay to run it against your own systems, or be vulnerable to what it finds in everyone else's — discovery and protection collapsed into one SKU. We'll need to watch the locksmiths to see if they end up selling lockpicks in addition to keys.
Going to be an interesting summer.
Say I had $1000, how do I get the best value for money to discover vulnerabilities? Are there any worthwhile LLM powered services that are turnkey and ready to go?
From what I've heard, every LLM before Mythos (which you can't get, they'll call you if you're big enough) will have far too many false positives to be helpful, so I guess the best option would be to use an agent to help you (not lights-off vibe coding!*) take advantage of all the older tools like valgrind and closing all the compiler warnings?
* I presume I'm not the only one to find the agents tasked with adding unit tests will sometimes try to sneak through "open source code and apply regex to confirm presence or absence of specific string literal".
They can speed you up significantly, but you absolutely do need to pay attention to what they produce.
With all respect to the Anthropic folks, that's just marketing. (If they're reading this: let us into the program so I can be proven wrong here.)
I'm sure what they have is awesome, but it's clear that there are people out there with some decent prompts that are getting results out of widely available models as well.
The big thing we're sharing is: bulk scanning by random people in random geographies got a _lot_ better around January, it's widely distributed, and it's going to get a lot better regardless of whether that specific version of Mythos becomes widely available or not.
> prompts that are getting results out of widely available models as well.
Absolutely, and the "false-positive" issue people keep citing as why Mythos is so good is easily solved in the harness, simplest solution is starting fresh context with another prompt to evaluate if it's a false-positive or not, just adding that drastically cuts down the rate.
That is false. A year ago every LLM generated report was slop - more likely a false positive than correct. However in the past few months nearly every LLM generated report is real.
This is not good reasoning. You're offloading your thinking to "Turso" for some reason.
You're also assuming that they haven't made the alternative judgement that instead of triaging the haystack of slop that they get in order to potentially pay out to someone, they should instead be spending that cash and effort on tokens to find bugs in their own codebase.
You should read the mentioned article. They have hired some of the people they paid out to, and some of those people were LLM-assisted.
The claim I'm rebutting is "in the past few months nearly every LLM generated report is real." If that were true, there would be no need to close the bounty. The bounty is to address approaches that they themselves may not have considered, so would still hold value if the claim held true, as outside individuals may still hold unique LLM-assisted approaches and perspectives.
Everyone is going to see different results. Overall the general trend is AI is getting better. Although that might be partially people are shutting down their bounty programs which gives the incentive to generate slop.
Not sure about turnkey solutions for finding vulnerabilities that doesn't involve having to hand over a bunch of identity proofs for them to store on their insecure infra and also enrolling in programs.
Besides that, hiring a beefy GPU instance at Vast.ai or similar places then running your own uncensored models on it, I've had great success with AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-NVFP4, smart + uncensored, but there are lots of options, probably some are already tailored for security research.
> Most are not serious, and we’ve quietly fixed them, thanked the researcher, and went our merry way... These come from a wide variety of locations and people, and sometimes, but not always, are looking for bug bounties.
I take it that Metabase is both not paying bug bounties and not using these tools internally?
If that's the case, Metabase is not going to get meaningful investment from researchers who want to fix issues, but they'll get increased attention from malicious attackers who have no qualms exploiting the vulnerabilities for profit.
LLMs have made it a lot easier for people to find vulnerabilities in software. Open-source makes it easier, but we already have non-AI tooling (IDA Pro, Ghidra) that's good at binary reverse engineering, and LLMs can use that output to find vulnerabilities as well.
This year, as I select products to use for sensitive data, I've been paying a lot more attention to whether they offer bug bounties and for how much. For example, I like Kagi for search and thought about trying Orion, their web browser. Then, I saw that Kagi's been paying $100 for UXSS vulnerabilities.[0] For comparison, Firefox pays $8-10k,[1] and Chrome pays up to $10k for the same class of bug.[2]
Thankfully we've historically had a fair amount of attention (and investment in our security) by both customers, our oss users and people our ecosystem.
The interesting thing is that the business model seems to have changed. Why collect a 10k bounty when you can advertise a 3k/month scanner?
> Did you have other plans for the weekend? Or a long term project you’re prioritizing? That’s nice, you have a new plan — fix every vulnerability that comes in NOW.
Or you know, provide the security companies and businesses using your software for free with all the fix timelines and out of hours support they’ve paid for (none).
It's not for the benefit of the security company though. In fact they get zero benefit from it. It's for the benefit of the users of the software which makes the calculus more complicated.
I'd buy the core thesis and appreciate the concern.
I do think security is going to require more, not, less human investment as attackers may be running automated vulnerability screens from the outside that you must counter, as well. Without rigorous internal processes to manage and screen all changes and upgrades, companies risk leaving themselves open.
One design change which limits exposure is to have more local-first apps or experiences so there's less cloud / server to computer interactions to secure.
> Did you have other plans for the weekend? Or a long term project you’re prioritizing? That’s nice, you have a new plan — fix every vulnerability that comes in NOW.
Umm... no? It's called OPEN source. Expecting people to cancel their plans to make your free software more secure is pretty audacious. Luckily, many WILL, but the expectation is just foolish.
Sorry for all caps, but for some reasons OSS licenses think this is the proper way to style this paragraph
MIT:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
BSD:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OSS maintainers don't owe anyone shit. Anyone who thinks fixing the bug is important is free to fix it and submit a patch.
This is something I struggle with as someone building a tool for debugging and security.
I have dog-fooded it heavily on my own projects, client projects and friends projects. It finds things that are really quite clever and not obvious. It really helps me.
But when I try to do the obvious thing for sales of using an OSS project to get hype, show off etc. I find that it becomes really hard to really know that I am helping and not just spamming.
To be clear - I think for an AI tool like mine to actually give you clever results that finds not obvious issues and security flaws - it needs to have some level of false positives.
I find myself struggling to justify the approach of firing off defects to an OSS maintainer without verifying them - which takes considerable time if I am going to do a good job. Even with tools to help pull apart the code, the core problem is always you don't know what you don't know.
The same process working on my own projects I can eat through a ton of defects and find some really great stuff. But that's only possible because I can tell at a glance what is real, what is fake, and also what is an oh ** issue.
So I think this is true, but the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing.
This stuff is more complicated than people give credit - and it's so easy to kid yourself into thinking any bug report is helpful.
So you slop-coded a tool, you're slop-generating reports, you know it has hallucinations ("false positives").. and you're complaining it's too much work to even verify the output?
And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
> And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
How do you get that from:
> the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing... and it's so easy to kid yourself into thinking any bug report is helpful.
The problem on the side of closed source software is that if there had been leaks of source code, the vulnerabilities and exploits may remain unknown for long time.
I would go to say that most closed source software code gets leaked. Most companies hold that info close and don't disclose it, even if legally required unless it's made public.
Nobody really knows of course. However it is safe to assume they are not so stupid as to ignore what is happening in the other areas (at least some of them), and so they are running their own targeted scans and then trying to figure out how to make money (or whatever their goal is) by exploiting them. They are also using LLMs to try things on closed source that are more than a brute force attack, though I have no idea what those would be.
A focus on security in 2026 is driving code quality improvements in long-lived software. There is a step-function increase in the identification and remediation loop among disciplined engineers.
Defining an "era" as a "summer" is short-sighted. Calling an industry-wide efforts to find and fix security vulnerabilities with better tools "strip mining" is backwards thinking, from where I sit.
This needs to be read after the article from Turso on how they're retiring their bug bounty program because of being inundated with useless AI slop reports. It's the top story on HN right now.
Good luck getting anyone who values their time to even triage the results.
I would rather lick the bottom of a NYC dumpster that a rat had just died in.
Software will eventually become "unmaintainable due to lack of interest", because of this very thing. People not invested in this are not "in peril" in any way.
A lot of people are invested without realizing it. I'm typing this on a computer running linux, with all the standard services/software. I maintain one OSS project (icecc - we have always said only run on trusted networks. I'm sure there are a lot of issues in our code but nobody has bothered run a scan yet to my knowledge), but I don't pay attention to everything. I'm sure there are known easy to exploit (with a LLM) issues on this computer just because my distro hasn't updated yet. (I need a better distro, but even the most up to date will constantly have these issues)
What you just described may be accurate. But it also is the essence of a "trap".
My comment about investment was more to that point.
If software "is a trap", even my ever-computing loving wrote first programs on an Apple II in the 80s will only be as you sort of describe invested in by reference (minimal usage).
But no-one will sign up for a "trap" as a career, and only those who do will deal with its problems. The first thing that comes to mind is "Johns", "Hotels", and the trappings of the sex trade.
Apparently the AI company Metabase has a very poor code base. Like so many others, instead of questioning their own (or AI) output, they help their AI overlords by promoting security scans.
Fact is that Mythos found only one issue in curl and nothing at all in most code bases. It is getting quiet around Mythos, and the AI companies will move on to the next scam.
Mythos found only one issue in curl - but it didn't start until many other LLMs had been run and found a lot of issues that were fixed. If Mythos was run a year ago it would have found over 100 issues (of course it didn't exist a year ago, nor did the other tools).
Curl had many old protocols and code from the 1990s that no one used. Besides, Mythos was claimed to be better than existing tools.
In most open source projects, Mythos or similar tools have found nothing. The AI people only contact the projects where they find something, because it would be bad for marketing otherwise.
This is now the open source problem. And why my personal opus of work has been removed from online repositories.
Who gave them "the right to scan"? You did by hosting your open source in public. But scanning a public service prior to AI was still covered by "Unauthorized System Access".
But what if they are wrong, and given the self-serving nature of these scans, now your repo is just OJ Simpson? And your software is banned due to an external scan you did not ask for?
Is there no one in this world who will be accountable for any thing at all?
Can we sue the scanners if they are wrong and publish their results for defamation even in a public PR?
These things will happen. IF I had source in the open and a scan result was incorrect that nobody asked for and the results had false positives, I would sue Anthropic for defamation and I would win.
The open source problem argues for a modification of licenses to exclude certain uncompensated use in training commercial LLMs (which may arguably already be a violation).
With careful prompting, LLMs will give up some of their sources and methods. Claude describes the legally and ethically suspect methods Anthropic used acquiring training materials for its models.
The IP law and courts are starting to catch up (re: Anthropic settlement September 2025), but licensing language and enforcement has not.
Do you even believe this cope in your heart? With each month that passes you're going to keep seeing increasingly advanced bugs and mathematical proofs found by AI. And you'll have to keep coming up with increasingly silly excuses why that isn't real progress. Maybe save yourself the cognitive dissonance and face reality now. It's not just a parrot.
Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin:
I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.
To address this framing directly: "a bug exists" is a different truth/state of the world than "the bug is known to exist", and that's also very different from "this bug exists and an exploit is readily available". So the transmission of information about the bugs does change the state of the world, and requires action.
There are actually three states:
- A bug exists and nobody knows
- A bug exists and some people know
- A bug exists and everyone knows
As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state.
Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being completely unknown is better than being known to a few, but there is no way to ever know if that's the case.
From the outside, known to none and known to a few are indistinguishable, and thus both states are the worst possible case. The only remedy is to make the bug known to everyone such that it cannot be covertly exploited.
That's not the whole picture though. Bugs exist anyway. The only practical concern is, which are practically most likely going to be used among all these bugs that yes exist and included in production.
You've described states one and two as outlined above.
Whether a bug is exploitable is an entirely separate category of unknowable, because seemingly-innocuous bugs quite often have very deep and very subtle implications that when combined with another innocuous bug, result in an RCE or PE.
Therefore, it's sensible to treat all bugs as potential threat vectors unless and until proven otherwise. Which brings us full circle: state 3, all bugs being public, is probably the safest thing because nobody can know if a bug is in state 1 or 2.
It's sensible just as it's sensible to have invulnerable immune system.
Sure, who wouldn't like to have that? Such a thing is impossible to reach starting with the same reason as Gödel's incompleteness theorem is a thing, plus a gazillion of more practical constraints.
A bug existing or not for a person is a statement about that person's knowledge of the bug.
Is your assertion that, since you specifically didn't know about the bugs that nobody, not in Russia or anywhere else did?
Obviously if bugs are out there existing in software and you don't know about them, or the CVE system doesn't know about them, or whatever ... this does not preclude bad guys from knowing about them. In the era of agents, knowing the bug exists is equivalent to having a PoC, so the distinction completely collapses.
Arguably, the transition goes from - this bug exists but vendors ignore it because only criminals and intelligence agencies know about it to, this bug is publicly embarassing lets fix it right away.
Sweeping things under the rug is how we get insecurity. Sunshine is the best disinfectant.
> Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
Is this supposed to be hard to imagine? I can completely imagine this, especially if the mathematician is a celebrity in their field.
In theory, the vulnerability was always there, and it's better to find out than not find out.
In practice, how much effort it is to find vulnerabilities matters a lot. We're in a time where things that used to be quite hard are now easy and the rate of discovery will change.
This rate of discovery matters a lot -- for OSS maintainer burnout if nothing else.
It matters in a positive sense; it's a thing that enables you to make some predictions about the state of the world tomorrow. It does not matter in a normative sense; OSS maintainer burnout is strictly a less important concern than software security, which is an externality of software development.
> OSS maintainer burnout is strictly a less important concern than software security,
Burnout means that no more fixes come - ever - and that things sit vulnerable until everyone relying on that tool takes the time to build and switch to a replacement.
Maintainer burnout is perhaps the single biggest threat to the ecosystem right now.
That can't possibly be an argument for forbearing security vulnerabilities in software. It's an argument for prioritizing hypothetical flaws over real ones.
If these flaws are so important, users of open source (business or individual) need to pay up - literally. Pay the maintainers enough to justify spending the time on these things, including the opportunity cost of not working at other software jobs during that time.
Pay each maintainer an absolute minimum of $200K a year or shut up and do the work yourself - in a fork if necessary.
This comment should not be greyed out. I feel that we all forget this far too much. You've exaggerated it somewhat.
There is no right to demand someone does something for free, and we have gotten dependent on people doing things for free. We don't have to pay people but if we don't want to, then we have to be willing to do it ourselves. Otherwise it could go away at any moment and we have no recourse.
Stated differently -- the way OSS software is currently maintained and users are conditioned to behave, there is a capacity problem if the rate of discovery surges too sharply.
And if the capacity is overshot (which I believe is happening as we speak), users end up in extended states of being insecure.
I'm also one of the unwashed rabble who believes there is a large practical difference between a vulnerability that exists but isn't found and one that is widely known and exploitable.
There's two fallacious arguments encoded here. The first is obvious, that we should prioritize hypothetical future vulnerabilities and fixes over ones we know exist today. The second is subtler and more insidious: it's the idea that the goal of software is to ensure every package and project is viable, that everyone who wants to deploy it should be able to do so. The risks this attitude pose to users, ordinary people who have no agency over which software packages you use to serve their needs, are a pure externality. The idea that a project serving real human users might opt to compromise availability rather than putting people at risk is never even broached.
If the maintainers burn out, nobody's going to be making your software secure.
Then people will stop using that software.
This is so far outside of reality that I can't believe I'm even commenting on it.
If you believe people don't use software that is unmaintained and hilariously out of date I genuinely don't know what world you live in or how to deliver the bad news to you.
Oh, I agree that today there's a general expectation that externalized security doesn't matter and someone will always come around to rescue you (and your unmaintained dependency) from disaster. I'm just saying: infinite free bugs is likely to disrupt that equilibrium.
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
I don't think anyone is saying that here.
I think the net result is "wow, we're going to end up a lot more secure in several months, but things are going to feel sucky because stuff just got A) way easier for the average bad guy, and B) way busier on the fixing side."
I think it's likely we end up with an equilibrium with a lower rate of bug discovery than we're used to, but we need to experience an above average rate for a long while first...
> The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
The philosophy in this subthread may be too deep for me.
Me and the Jedi at the ends of the bell curve are just thinking "It's bad when your attackers know your code is vulnerable"
as a jedi you’re surely wise enough to understand that closed source has just as many vulnerabilities if not more.
open source will get fixed while closed will not.
The vulnerability looks like a failure on the dev team's part.
The patching cycle can become a problem for certain operations / industries.
Everybody hates the work, and security is often seen as a barrier and a cost center, not a driver or revenue.
Humans are famously rational and ego-less.
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Try binge-watching old Star Trek episodes, to see how Spock deals with the illogical 99.9% of humanity?
The article focuses on OSS, but closed-source software is at major risk too. Perhaps more.
It's gotten much easier to reverse engineer binaries in general, and security patches in particular. Basically, an LLM can turn binaries into 'readable' code, and then reason about said code.
Perhaps -- but I think for most people, the vast majority of proprietary software they consume is over the network.
But yeah, if you're distributing binaries publicly, then you're going to have very similar problems.
That happens a lot though, even OpenAI is attempting to lock functionality (like computer-use, 2 weeks ago) behind a binary -- Mac only they said, no EU. I saw a guy crack it the same day, ported to Windows. There are many many things like Rive that use binaries, obfuscation and uglification has been the name of the proprietary game for a long ass time, with the only protection being an assumption that "nobody would go through that trouble", yeah an LLM would ralph loop through it all day long, and make what you paid good money for pretty much free for anyone to use whenever they feel like it, we're back to the the "you wouldn't download a car would you?" argument
Does it even need to turn it into readable code?
My understanding is that decompilation into more readable code is an important step in building the path to an exploit.
This understanding may be incomplete or outdated (things moving very fast right now). I'd love to hear from a someone with more experience using LLMs to do binary analysis about the level of 'binary annotation' needed for LLMs relative to humans.
I had done a fair bit of reverse-engineering-jar-files in the pre-LLM era for various reasons. The biggest problem with decompiled java files was naming. The original variable names, class names etc were not retained and the decompiler would use some alphanumeric series. That'd make reading code very hard. Curious how the current LLMs are able to address this. Maybe it's able to figure out how the class, variable etc is used and name it accordingly. (All this is assuming the original code itself was readable because there are enough bad programmers)
I expect Java would be easy-mode for the AI, they already do quite well reconstructing C++ from ghidra output in my experience from when I wanted to know what damage formula some game was using.
As a reminder; your account has been shadow-banned, it looks like you got a little unlucky in 2016.
> I expect Java would be easy-mode
That makes sense. Java leaves metadata in compiled code to reconstruct better.
> your account has been shadow-banned, it looks like you got a little unlucky in 2016
I see. I wasn't aware. Thanks. I thought the two comments per day limit is for users with low karma. Anyway, I'm using that limit to push myself in being picky about posts to comment on and to improve the quality of comments.
Shadowbans are actually a bit more than that - your comments are invisible unless someone with a high karma threshold puts a little effort in to mark them as reasonable. People can't actually see most of your comments.
I'd recommend creating a new account. Or you could email the mods (I forget the email but it is publicly available somewhere) if the user name has sentimental value. In your case it is clear that a shadowban is inappropriate.
[dead]
Clearly for commercial oriented opensource software, security through obscurity is one way to keep the pace in the short term. Not an option for proper open source software. Will this be the case that people who use open source software that is easily detectable will also start to shy away from using them for the fear of zero-days?
One of the benefits of Open source has been that there are more eye balls on the source, leading to more secure code/better quality. I think given enough time the bug reports will plateau and we will be back to a normal cadence - once the tsunami is over, hopefully things will settle at a more manageable cadence .
I'm not sure that the benefit of many eyes helps here. So much of this bulk scanning is low-effort, and if you're a smart person developing closed source software you get the benefits of bulk scanning, but _at the time of your choosing_ .
OSS has always had tradeoffs and I sadly think this one is going straight to the "Cons" column. We still think the Pros outweigh the Cons, but this is NotGreat.
This benefit you speak of is actually just a meme.
Source that is unmaintained is dead. Nobody is looking at it, even the maintainer has something better to do.
Do you know whats even more powerful than "eyeballs"? Money.
Lets be honest, LLM with fuzzers are going to pound any llvm generated binary right in the hubris.
Won't matter if is closed source, signed, and or obfuscated. =3
Don't think you even need to qualify that with "llvm generated."
Nondeterministic compiled code-motion in llvm means a workaround can't reliably be patched given version permuted bug emergence.
Fun times =3
It's certainly possible to write optimizations that generate nondeterministic llvm outputs, but the docs explain conditions when that can happen, and warn against it.
I do not think author understands how opensource works. You have a problem on your computer, in __your__ software, and somehow some random dude is responsible for fixing it? Sure if you gimme a few kilo USDs I will drop everything and come to rescue you. But for free it is a volunteer gig I do once a month....
I dunno man ... I produced a few things that got a few github stars over the years.
At the risk of repeating myself -- this is targeted at other OSS maintainers, not random people who might have done a git pull of some random project a couple years ago.
I think this is going to play out in interesting ways. There's a saying in lockpicking: even if you can pick the lock, the easiest way in is usually a window. Distribution is core to a technology's market reach, and every distribution point is a window. The strip-mining piece reads to me as one phase of a longer cycle — tech distributed → adopted → experimented with → misused → secondary protection market emerges. The 2017 S3 misconfiguration wave is a useful reference: Verizon and Booz Allen both spilled data through bucket ACLs with inadequate controls, AWS responded with Block Public Access, and the CSPM market matured to sell the discipline back. Mythos looks like the same shape at the AI layer — leaked via vendor environment chain (Mercor breach + contractor credentials + URL guessing), not code-level vulnerability. The proliferation of high-quality security research the article points at reads to me as one sign of the secondary market forming as the primary disruptive technology stabilizes — Gartner already has AI governance spending crossing $1B by 2030. And it seems to be landing on OSS first because that's where the surface area and public exposure are, which is what the labor pressure is documenting. Cascade to closed source seems likely as the compression between vulnerability-introduced and vulnerability-identified continues, just on a lag and behind NDAs. The OSS side could go either way under that pressure, and I don't know which dominates. FFmpeg slowed in 2024 from overload and got rescued by Germany's Sovereign Tech Fund — pressure converted into hardened posture. Ingress-Nginx retired November 2025 after two maintainers couldn't sustain it on weekends, despite running in ~50% of cloud-native environments — same pressure, no backing. Tracks institutional backing more than anything intrinsic to OSS. The wrinkle Mythos adds: same product is both weapon and salve. Pay to run it against your own systems, or be vulnerable to what it finds in everyone else's — discovery and protection collapsed into one SKU. We'll need to watch the locksmiths to see if they end up selling lockpicks in addition to keys. Going to be an interesting summer.
Say I had $1000, how do I get the best value for money to discover vulnerabilities? Are there any worthwhile LLM powered services that are turnkey and ready to go?
From what I've heard, every LLM before Mythos (which you can't get, they'll call you if you're big enough) will have far too many false positives to be helpful, so I guess the best option would be to use an agent to help you (not lights-off vibe coding!*) take advantage of all the older tools like valgrind and closing all the compiler warnings?
* I presume I'm not the only one to find the agents tasked with adding unit tests will sometimes try to sneak through "open source code and apply regex to confirm presence or absence of specific string literal".
They can speed you up significantly, but you absolutely do need to pay attention to what they produce.
With all respect to the Anthropic folks, that's just marketing. (If they're reading this: let us into the program so I can be proven wrong here.)
I'm sure what they have is awesome, but it's clear that there are people out there with some decent prompts that are getting results out of widely available models as well.
The big thing we're sharing is: bulk scanning by random people in random geographies got a _lot_ better around January, it's widely distributed, and it's going to get a lot better regardless of whether that specific version of Mythos becomes widely available or not.
> prompts that are getting results out of widely available models as well.
Absolutely, and the "false-positive" issue people keep citing as why Mythos is so good is easily solved in the harness, simplest solution is starting fresh context with another prompt to evaluate if it's a false-positive or not, just adding that drastically cuts down the rate.
That is false. A year ago every LLM generated report was slop - more likely a false positive than correct. However in the past few months nearly every LLM generated report is real.
If your assertion of falsehood were true, the current top story on HN wouldn't be Turso shutting down their bug bounty due to overwhelming slop.
This is not good reasoning. You're offloading your thinking to "Turso" for some reason.
You're also assuming that they haven't made the alternative judgement that instead of triaging the haystack of slop that they get in order to potentially pay out to someone, they should instead be spending that cash and effort on tokens to find bugs in their own codebase.
You should read the mentioned article. They have hired some of the people they paid out to, and some of those people were LLM-assisted.
The claim I'm rebutting is "in the past few months nearly every LLM generated report is real." If that were true, there would be no need to close the bounty. The bounty is to address approaches that they themselves may not have considered, so would still hold value if the claim held true, as outside individuals may still hold unique LLM-assisted approaches and perspectives.
Everyone is going to see different results. Overall the general trend is AI is getting better. Although that might be partially people are shutting down their bounty programs which gives the incentive to generate slop.
Not sure about turnkey solutions for finding vulnerabilities that doesn't involve having to hand over a bunch of identity proofs for them to store on their insecure infra and also enrolling in programs.
Besides that, hiring a beefy GPU instance at Vast.ai or similar places then running your own uncensored models on it, I've had great success with AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-NVFP4, smart + uncensored, but there are lots of options, probably some are already tailored for security research.
> Most are not serious, and we’ve quietly fixed them, thanked the researcher, and went our merry way... These come from a wide variety of locations and people, and sometimes, but not always, are looking for bug bounties.
I take it that Metabase is both not paying bug bounties and not using these tools internally?
If that's the case, Metabase is not going to get meaningful investment from researchers who want to fix issues, but they'll get increased attention from malicious attackers who have no qualms exploiting the vulnerabilities for profit.
LLMs have made it a lot easier for people to find vulnerabilities in software. Open-source makes it easier, but we already have non-AI tooling (IDA Pro, Ghidra) that's good at binary reverse engineering, and LLMs can use that output to find vulnerabilities as well.
This year, as I select products to use for sensitive data, I've been paying a lot more attention to whether they offer bug bounties and for how much. For example, I like Kagi for search and thought about trying Orion, their web browser. Then, I saw that Kagi's been paying $100 for UXSS vulnerabilities.[0] For comparison, Firefox pays $8-10k,[1] and Chrome pays up to $10k for the same class of bug.[2]
[0] https://help.kagi.com/kagi/privacy/bug-bounty-program.html
[1] https://www.mozilla.org/en-US/security/client-bug-bounty/
[2] https://bughunters.google.com/about/rules/chrome-friends/chr...
Thankfully we've historically had a fair amount of attention (and investment in our security) by both customers, our oss users and people our ecosystem.
The interesting thing is that the business model seems to have changed. Why collect a 10k bounty when you can advertise a 3k/month scanner?
[dead]
> Did you have other plans for the weekend? Or a long term project you’re prioritizing? That’s nice, you have a new plan — fix every vulnerability that comes in NOW.
Or you know, provide the security companies and businesses using your software for free with all the fix timelines and out of hours support they’ve paid for (none).
It's not for the benefit of the security company though. In fact they get zero benefit from it. It's for the benefit of the users of the software which makes the calculus more complicated.
Yeah ... this gets into the question of what exactly an OSS creator's responsibility is towards users that don't pay them.
In theory, nothing.
In practice, it's in our long term interest that bad things don't happen to them.
How sustainable all of this is, I have my doubts?
I'd buy the core thesis and appreciate the concern.
I do think security is going to require more, not, less human investment as attackers may be running automated vulnerability screens from the outside that you must counter, as well. Without rigorous internal processes to manage and screen all changes and upgrades, companies risk leaving themselves open.
One design change which limits exposure is to have more local-first apps or experiences so there's less cloud / server to computer interactions to secure.
> Did you have other plans for the weekend? Or a long term project you’re prioritizing? That’s nice, you have a new plan — fix every vulnerability that comes in NOW.
Umm... no? It's called OPEN source. Expecting people to cancel their plans to make your free software more secure is pretty audacious. Luckily, many WILL, but the expectation is just foolish.
That line was aimed at other OSS maintainers.
These alerts are absolutely not being shared publicly before we have a fix for them.
Sorry for all caps, but for some reasons OSS licenses think this is the proper way to style this paragraph
MIT:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
BSD:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OSS maintainers don't owe anyone shit. Anyone who thinks fixing the bug is important is free to fix it and submit a patch.
This is something I struggle with as someone building a tool for debugging and security.
I have dog-fooded it heavily on my own projects, client projects and friends projects. It finds things that are really quite clever and not obvious. It really helps me.
But when I try to do the obvious thing for sales of using an OSS project to get hype, show off etc. I find that it becomes really hard to really know that I am helping and not just spamming.
To be clear - I think for an AI tool like mine to actually give you clever results that finds not obvious issues and security flaws - it needs to have some level of false positives.
I find myself struggling to justify the approach of firing off defects to an OSS maintainer without verifying them - which takes considerable time if I am going to do a good job. Even with tools to help pull apart the code, the core problem is always you don't know what you don't know.
The same process working on my own projects I can eat through a ton of defects and find some really great stuff. But that's only possible because I can tell at a glance what is real, what is fake, and also what is an oh ** issue.
So I think this is true, but the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing.
This stuff is more complicated than people give credit - and it's so easy to kid yourself into thinking any bug report is helpful.
So you slop-coded a tool, you're slop-generating reports, you know it has hallucinations ("false positives").. and you're complaining it's too much work to even verify the output?
And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
> And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
How do you get that from:
> the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing... and it's so easy to kid yourself into thinking any bug report is helpful.
So what does this mean for the open source ecosystem? Unmaintained or “finished” projects will be labeled as to unsafe to use?
If you're using unmaintained OSS projects in this day and age, I'm sorry to say you might deserve what happens next.
The problem on the side of closed source software is that if there had been leaks of source code, the vulnerabilities and exploits may remain unknown for long time.
I would go to say that most closed source software code gets leaked. Most companies hold that info close and don't disclose it, even if legally required unless it's made public.
Side conversation -- This is all stuff we're seeing in white/grey hat land. What's going on in blackhat land?
Nobody really knows of course. However it is safe to assume they are not so stupid as to ignore what is happening in the other areas (at least some of them), and so they are running their own targeted scans and then trying to figure out how to make money (or whatever their goal is) by exploiting them. They are also using LLMs to try things on closed source that are more than a brute force attack, though I have no idea what those would be.
A focus on security in 2026 is driving code quality improvements in long-lived software. There is a step-function increase in the identification and remediation loop among disciplined engineers.
Defining an "era" as a "summer" is short-sighted. Calling an industry-wide efforts to find and fix security vulnerabilities with better tools "strip mining" is backwards thinking, from where I sit.
People who prefer 0days in their code baffle me.
This needs to be read after the article from Turso on how they're retiring their bug bounty program because of being inundated with useless AI slop reports. It's the top story on HN right now.
https://turso.tech/blog/the-wonders-of-ai
AI hype. Don't bother
Good luck getting anyone who values their time to even triage the results. I would rather lick the bottom of a NYC dumpster that a rat had just died in.
That was true last year -- things changes.
Ignore (admittedly low-effort LLM generated) reports at your own peril.
Software will eventually become "unmaintainable due to lack of interest", because of this very thing. People not invested in this are not "in peril" in any way.
A lot of people are invested without realizing it. I'm typing this on a computer running linux, with all the standard services/software. I maintain one OSS project (icecc - we have always said only run on trusted networks. I'm sure there are a lot of issues in our code but nobody has bothered run a scan yet to my knowledge), but I don't pay attention to everything. I'm sure there are known easy to exploit (with a LLM) issues on this computer just because my distro hasn't updated yet. (I need a better distro, but even the most up to date will constantly have these issues)
What you just described may be accurate. But it also is the essence of a "trap". My comment about investment was more to that point.
If software "is a trap", even my ever-computing loving wrote first programs on an Apple II in the 80s will only be as you sort of describe invested in by reference (minimal usage).
But no-one will sign up for a "trap" as a career, and only those who do will deal with its problems. The first thing that comes to mind is "Johns", "Hotels", and the trappings of the sex trade.
Apparently the AI company Metabase has a very poor code base. Like so many others, instead of questioning their own (or AI) output, they help their AI overlords by promoting security scans.
Fact is that Mythos found only one issue in curl and nothing at all in most code bases. It is getting quiet around Mythos, and the AI companies will move on to the next scam.
Mythos found only one issue in curl - but it didn't start until many other LLMs had been run and found a lot of issues that were fixed. If Mythos was run a year ago it would have found over 100 issues (of course it didn't exist a year ago, nor did the other tools).
Curl had many old protocols and code from the 1990s that no one used. Besides, Mythos was claimed to be better than existing tools.
In most open source projects, Mythos or similar tools have found nothing. The AI people only contact the projects where they find something, because it would be bad for marketing otherwise.
This is now the open source problem. And why my personal opus of work has been removed from online repositories.
Who gave them "the right to scan"? You did by hosting your open source in public. But scanning a public service prior to AI was still covered by "Unauthorized System Access".
But what if they are wrong, and given the self-serving nature of these scans, now your repo is just OJ Simpson? And your software is banned due to an external scan you did not ask for?
Is there no one in this world who will be accountable for any thing at all? Can we sue the scanners if they are wrong and publish their results for defamation even in a public PR?
These things will happen. IF I had source in the open and a scan result was incorrect that nobody asked for and the results had false positives, I would sue Anthropic for defamation and I would win.
The open source problem argues for a modification of licenses to exclude certain uncompensated use in training commercial LLMs (which may arguably already be a violation).
With careful prompting, LLMs will give up some of their sources and methods. Claude describes the legally and ethically suspect methods Anthropic used acquiring training materials for its models.
The IP law and courts are starting to catch up (re: Anthropic settlement September 2025), but licensing language and enforcement has not.
Thats how "theft" works. You take the stuff and run away as fast as you can.
Do you even believe this cope in your heart? With each month that passes you're going to keep seeing increasingly advanced bugs and mathematical proofs found by AI. And you'll have to keep coming up with increasingly silly excuses why that isn't real progress. Maybe save yourself the cognitive dissonance and face reality now. It's not just a parrot.