Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No bugs means nothing if bugs get hidden and llms are great at hiding bugs and will absolutely fail to find some fairly critical ones. Your own repo, which is slop at best, fails to meet its core premise

> Another AI agent. This one is awesome, though, and very secure.

it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is.

edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others

Severity - Count - Categories

Critical - 2 - SQL Injection, Path Traversal

High - 4 - SSRF, Auth Bypass, Privilege Escalation, Secret Exposure

Medium - 3 - DoS, Information Disclosure, Injection

You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.



Build a redteam into your feedback mechanism. Seriously. You've identified the problem and even solved it. Now automate it.


it sure can help, but it shouldn't be considered solved. Realistically you should treat it as vulnerable until it's received some attention from natural human folks who do know what they're doing. LLM's are great but they're not experts in any field as of yet.


Right yeah, thanks for the constructive comment. Mind filing those vulnerabilities, or are you just making a point?

How do you know these are actual vulnerabilities? You just ran an LLM and it told you something and you came back to dunk on me, with zero context on the project.

Maybe you need to sit down and really think that you have no idea who you're talking to or what the project does. Next time you make a "omg this code is so shit" comment, include something more than "well my LLM says your LLM is bad" so we can have a discussion with facts rather than LLM-aided trashtalk.

EDIT: Out of curiosity, I've ran Kimi K2.5 on the codebase, and all the things it found are invalid, or explicit design decisions. So, next time you decide to tell someone their project "is slop" by running an LLM and relaying its verdict, consider a) the irony of what you're doing, and b) that the other person might know more than you about their own project that you spent "three minutes" running an LLM on.


The three minutes was my own time. There are thousands of projects like yours, why would i sink serious time into yours over another? I found one myself in three minutes, then ran kimi to see if it finds more. Someone being able to hijack your agent to run arbitrary code on your device seems like an odd design decision. The constructive feedbakc here is to take it seriously and engage with your codebase. Give a man a fish /Teach a man fish, you know?


Yeah except you didn't actually find a vulnerability, you just searched for a pattern, found it, and thought "vulnerability" because you aren't a security researcher and don't realize that context is important.

You should educate yourself more before you go around slandering people.


Attacker payload -> Message to bot -> LLM processes -> arbitrary execute_sql triggered

This can be done via a signal/telegram message, via compromised plug-ins, via file uploads etc. At no stage does there appear to be, as far as I can tell, any attempt to mitigate or limit attack surface. That's just one of the problems. If that's by design, my bad, you do you king.


Seriously? Your attack vector is "trusted user tells bot with access to SQL to run SQL"?

How is the attacker going to message the bot, genius? Do riddle me that.


Look, perhaps I've been to hard on you. Maybe you have an intellectual disability or something, I don't know you or your situation, my bad. I get that you're proud of your project, and I don't want to take that from you. By all means, explore, tinker, hack around and explore, these are great traits/qualities. Just don't tell people what you're offering is safe, or worse, safer than alternative offerings. That claim simply isn't true. To be direct with you, the 'how' of an attack isn't a riddle, it's a documented reality of the modern threat landscape.

You're hyper-focused on the front door, asking how an attacker would even message the bot, but you're ignoring the fact that modern attackers don't bother knocking. Read cloudflare's 2026 threat report, it's eye opening. Between automated session cloning and browser-based info-stealers (among many other modern headaches), the 'whitelisted user' is no longer a static, trusted entity. If a user on your list has their session token scraped via a malicious browser extension or a hijacked desktop app, the attacker effectively becomes that user. At that point, your bot doesn't see an intruder; it sees a 'trusted' account and hands them a loaded gun in the form of arbitrary SQL execution. Now, the problem is you aren't the only one with access to LLM's and obscurity never really was security, even less so now. An llm with credentials could easily probe its way through your bot's capabilities and connected data and exfiltrate everything.

So, the reason I'm calling into question your claims of having a 'safer' personal agent/bot/whatever is a matter of blast radius. A standard bot usually interacts with a restricted API or a set of hard-coded functions, so even if the account is compromised, the damage is capped. By giving an LLM the keys to the entire database, you've created a single point of failure that can result in total data exfiltration or a complete 'drop table' wipe, among any number of other nasty things. That's just _one_ issue in this project.

If you actually want this to live up to the 'safer than average' description, you have to move past the idea that a whitelist is a firewall. You need to distinguish between authentication and authorisation and implement defense-in-depth, starting with a database user that has zero permissions beyond simple 'Select' queries. You should be using a proxy that intercepts the LLM's generated SQL and kills any string containing 'Drop', 'Update', or 'Delete' before it ever touches your server, without some form of parsing/checking. Right now, you’ve built a powerful engine with no brakes, and telling people it’s safer just because it's on Signal is a dangerous misunderstanding of how modern exploits actually work.

Alternatively, fix how the project is described to be more accurate/honest than it is now.


Yeah whatever, either show me an actual attack vector or go learn some more actual skills instead of trolling people here.


without posting something illegal here, I cannot make it more plain than the last comment, I am sorry.


Disclosing vulnerabilities isn't illegal, and you can use the project's bug tracker.


which would be fine / legal, but brings us back to a question many turns ago, why invest time in this particular project? There's a sea of similar projects, what makes yours stand out as worth investing in? The claims made don't stack up, and there's no indication this is anything other than LLM output, which means there's nothing here that can't be re-created quickly to a similar level of quality, however you define that. If we start rewarding everyone who posts mediocre repos to HN with attention, the entire platform will get drowned in no time. Show some personal effort first, then I'll invest mine. Discourse on a public central page like HN at least benefits public discourse. Engaging with your repo? no real benefits as far as I can tell.


No, it's definitely valid to want to spend just enough time to spread inaccuracies but not enough time to figure out why they're inaccurate.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: