An attack doesn’t have to be surprising to be an attack.
> The only way to prevent these kind of "leaks" is not to provide the data feed with private data to the agent.
Yes. That is exactly what the article recommends as a mitigation.
If you open an API to everyone, or put a password as plain text and index it, it's no surprise that someone accesses the "sensitive" data. Nor do I consider that an attack.
You simply can't feed the LLM the data, or grant it access to the data, then try to mitigate the risk by setting "guardrails" on the LLM itself. There WILL ALWAYS be a prompt to extract any data LLM has access to.
> Yes. That is exactly what the article recommends as a mitigation.
That's common sense, not mitigation. Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB. Common sense. Obvious.
The amount of your surprise is not a factor weather it is an attack or not.
You have been already asked about sql injections. Do you consider them attacks?
They are very similar. You concatenate an untrusted string with an sql query, and execute the resulting string on the database. Of course you are going to have problems. This is absolutely unsuprising and yet we still call it an attack. Somehow people manage to fall into that particular trap again and again.
Tell me which one is the case: do you not consider sql injection attacks attacks, or do you consider them somehow more surprising than this one?
> That's common sense, not mitigation.
Something can be both. Locking your front door is a mitigation against opportunistic burglars, and at the same time is just common sense.
> Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB.
That is actually a real world security advice. And in fact if you recall it is one many many websites were not implementing for very long times. So seemingly it was less common sense for some than it is for you. And even then you can implement it badly vs implement it correctly. (When i started in this business a single MD5 hash of the password was often recommended, then later people started talking about salting the hash, and even later people started talking about how MD5 is entirely too weak and you really ought to use something like bcrypt if you want to do it right.) Is all of that detail common sense too? Did you sprung into existence fully formed with the full knowledge of all of that, or had you had to think for a few seconds before you reinvented bcrypt on your own?
> Common sense. Obvious.
Good! Excelent. It was common sense and obvious to you. That means you are all set. Nothing for you to mitigate, because you already did. I guess you can move on and do the next genious thing while people less fortunate than you patch their workflows. Onward and upward!
You're extrapolating. The problem is clearly described as a MCP exploit, not a vulnerability. You're the only one talking about vulnerabilities. The system is vulnerable to this exploit.
You still don't understand the problem, do you? I mean, do you even understand the concept of an exploit?
The more people keep doing it and getting burned, the more it's going to force the issue and both the MCP spec and server authors are going to have to respond.
If you are working in an organization and you tell a junior coder "do everything on this list" and on the list is something that says "do something to some other list" and the junior coder does it...that's a fundamentally different kind of "bug". Maybe you expected that the junior coder should say "oh hmm, it's weird that something in this repo mentions another repo" but in that case, you can imagine a high level todo list that points to other low level todo lists, where you would want the junior coder to proceed. Maybe you're looking for "common sense" where there is none?
Actual organizations have ways to mitigate this. For example, OWNERs files would prevent someone from committing code to a repo of which they are not an OWNER without review. And then we're back to what many in these comments have proposed: you should not have given the agent access to another repo if you didn't want it to do something in that repo after you told it--albeit indirectly--to do something in that repo...
-- Actually, arguably a better analogy is that you go to share a file with someone in, e.g., Google Drive. You share a folder and inadvertently grant them access to a subfolder that you didn't want to share. If, in sharing the folder, you say "hey please revise some docs" and then somehow something in the subfolder gets modified, that's not a bug. That's you sharing a thing you weren't supposed to share. So this automatic detection pipeline can maybe detect where you intended to share X but actually shared X and Y.
The attacker is some other person who can create issues on a public Repo but has no direct access to the private repo.
You're the only one talking about GitHub MCP vulnerabilities. Everyone else is talking about GitHub MCP exploits. It's in the title, even.
Do you believe that describe a SQL injection attack an attack also does not make sense?
You can. Read the article. A malicious prompt is injected into an issue to trigger the repo owner's LLM agent to execute it with the agent's credentials.
"injected" is so fancy word to describe prompting - one thing that LLMs are made to do - respond to a prompt.
Or to come back to the SQL injection analogy, no one is surprised that the web app can query the database for password hashes. The surprise is that it can be instructed to do so when loading the next image in a carousel.
The attack is not via the prompt the victim types to the AI, but via [text in an issue or PR in the repo] that the victim is unaware about.
You can not HIDE the data MCP has access to. With a database and SQL, you can! So it can not be comparable with SQL injection.