71–80 of 228 posts
Earlier quoted context omitted.
What do you mean by "was" and "fixed it" ? It is still very much an issue and remains in the OWASP Top 10. https://owasp.org/Top10/2025/A05_2025-Injection/
You can write your code so SQL injections are not possible. You can't do the same with prompt injections.
> Responsible Disclosure GitLost was responsibly disclosed to GitHub. Vulnerability details are shared here with their knowledge. Why does this section not have when it was fixed or GitHub acknowledge/rejected this? Did they not fix this?
Fix what? They setup LLM with access to private data and ability to read public comments. That's simply misconfiguration.
It seems like the proper fix is for GitHub not to allow their agentic workflow to execute in a public repo context if it also has private repo access. Or, to use your phrasing, for GitHub to flag and disallow this easily-detectable and dangerous type of misconfiguration.
Earlier quoted context omitted.
What do you mean by "was" and "fixed it" ? It is still very much an issue and remains in the OWASP Top 10. https://owasp.org/Top10/2025/A05_2025-Injection/
You can write your code so SQL injections are not possible. You can't do the same with prompt injections.
The same way here, i see the main issue isn't prompt injection, it is publicly accessible agent having access to private repos. What is the important use case for such a config that it warrants such basic security violation?
Earlier quoted context omitted.
Exactly. SQL injection was caused by treating user input as part of the instruction instead of as the pure data that it was intended as. Separating those two fixed it. Prompt injection is unavoidable because the user input is intended as instruction.
What do you mean by "was" and "fixed it" ? It is still very much an issue and remains in the OWASP Top 10. https://owasp.org/Top10/2025/A05_2025-Injection/
Earlier quoted context omitted.
Exactly. SQL injection was caused by treating user input as part of the instruction instead of as the pure data that it was intended as. Separating those two fixed it. Prompt injection is unavoidable because the user input is intended as instruction.
What do you mean by "was" and "fixed it" ? It is still very much an issue and remains in the OWASP Top 10. https://owasp.org/Top10/2025/A05_2025-Injection/
You can avoid SQL injection by just coding the same features with a bit of care. You loose nothing. Mistakes can always happen, but it's not even tricky to prevent SQL injection.
Right now the only way to avoid Prompt injection is to not let your agents see user input at all. A very wide range of features that we'd like to implement are unsafe and there isn't a way to prevent this reliably.
I guess we'll need to get used to control the agent's permissions very tightly, and taylor them per-conversation. The agent I speak to for customer support must only have access to my data, and not because of instructions in the system prompt, these will need to be hard limits.
Earlier quoted context omitted.
What do you mean by "was" and "fixed it" ? It is still very much an issue and remains in the OWASP Top 10. https://owasp.org/Top10/2025/A05_2025-Injection/
You can write your code so SQL injections are not possible. You can't do the same with prompt injections.
How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information? This is like setting up a normal CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensi…
Who thought having a LLM with access to private information, with public access to ask it questions, would ever be a secure process? Look I like interacting with these tools as much as the next guy, but I'm certainly not going to trust them with access to information and then allow anyone to send them prompts. Edit/further thoughts: So (assumable as they said this is disclosed with github's knowledge) this has been p…
Yea agreed. LLM guardrails are either just written prompts as in "Please do not bad stuff :(" or other LLMs verifying that the first LLM didn't so some bs. Both of wich methods do not work sufficiently as time shows again and again. Funnily enough, nobody expects quality software anymore and errors became tolerable. So thats a win (for someone like me that lost all passion for the industry).