“Prompt injection attacks have become, to agentic AI, what SQL injections were to web applications: a systematic, category-wide vulnerability class that requires the same systematic strategies and defenses.”
???
Isn’t prompt injection far more fatal to LLMs than SQL injection is to SQL databases?
Like, the problem of SQL injection was that user input was forming part of the instruction string given to the SQL engine, and so malicious user input could include various SQL grammar terminals to end the current SQL command, followed by complete SQL commands of their own, and the engine would simply execute both commands. The fix was prepared statements: fixed/static/pre-compiled instruction strings, that can only ever perform fixed/static/pre-defined logic, and that logic can then be (more) safely applied to arbitrary user-input data.
The analogous mitigation for agents is to have fixed behaviors they can perform, such as “read repo 1” “read repo 2”, etc., and the user input is used as data to select which of these fixed behaviors to execute. But we already have this technology - it’s called a menu. The value of LLMs is specifically and intrinsically predicated on being more than a menu, while the value of SQL does not depend on being more than “pre-set logic operating on arbitrary data” - user input being part of the instruction string to SQL was incidental, for developer convenience.
fwlr
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 sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.
jakewins
'No Way to Prevent This,' Says Only Programming Concept Where This Regularly Happens
voidUpdate
Its funny to see how researchers bypass Githubs praised guardrails with a simple word like "Additionally". It just proves that any attempt to build hard security boundaries inside an llm context window is bound to fail. The model is naturally built to follow instructions, so if you mix system rules and user input together, the newer or more persistent instruction will always win
SwtCyber
> 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?
jofzar
Large corporations like Microsoft under constant pressure from investors are slapping AI onto every single product offering just so they can claim they're an AI company now. Just like what Adobe did. So yeah, that didn't end well and probably this wouldn't either. Consumers are getting tired of these half-assed AI integrations and there will be a breaking point soon.
neya
This reads like a marketing stunt for Noma. The cute name, the logo, the clickbait title, the dramatic tone in an article that seems targeted at a non-technical audience... And the actual vulnerability is what, that if you give an LLM private data and let random people interact with it, it may leak the data? Well, duh.
pkkm
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 patched. But how many different word combinations will it take to find another way to have this occur?
marak830
Why would anyone ever trust private repos on GitHub or other cloud solutions to offer any real privacy for codebases? Of course they are going to steal your code as soon as you upload it by pushing it, LLMs just enables them to obfuscate their intentional theft and let them get away with it and profit from it.
commentry
These are the same people who will give the LLM full write access on the disk and complain that it performed destructive actions.
If you don’t want an AI Agent to read private repos then you do not give the AI agent access to the private repos. This is not a permission bypass issue but a prompt injection issue which can’t be reliably solved at the Agent layer
comments (10)
Isn’t prompt injection far more fatal to LLMs than SQL injection is to SQL databases?
Like, the problem of SQL injection was that user input was forming part of the instruction string given to the SQL engine, and so malicious user input could include various SQL grammar terminals to end the current SQL command, followed by complete SQL commands of their own, and the engine would simply execute both commands. The fix was prepared statements: fixed/static/pre-compiled instruction strings, that can only ever perform fixed/static/pre-defined logic, and that logic can then be (more) safely applied to arbitrary user-input data.
The analogous mitigation for agents is to have fixed behaviors they can perform, such as “read repo 1” “read repo 2”, etc., and the user input is used as data to select which of these fixed behaviors to execute. But we already have this technology - it’s called a menu. The value of LLMs is specifically and intrinsically predicated on being more than a menu, while the value of SQL does not depend on being more than “pre-set logic operating on arbitrary data” - user input being part of the instruction string to SQL was incidental, for developer convenience.
fwlr
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 sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.
jakewins
voidUpdate
SwtCyber
Why does this section not have when it was fixed or GitHub acknowledge/rejected this?
Did they not fix this?
jofzar
neya
pkkm
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 patched. But how many different word combinations will it take to find another way to have this occur?
marak830
commentry
If you don’t want an AI Agent to read private repos then you do not give the AI agent access to the private repos. This is not a permission bypass issue but a prompt injection issue which can’t be reliably solved at the Agent layer
me551ah