> An attack doesn’t have to be surprising to be an attack.
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.
> it's no surprise
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!
In principle, I agree with you. The problem I have with articles like this and people commenting is that it's framed as if MCP's vulnerability is discovered, that MCP "needs fixing." When it's not. It's not the database's fault if you don't hash your password - it's yours.
It's a fundamental user experience flaw with the MCP server. It does indeed need fixing - e.g. it could have a permissions system itself, so even if the GitHub token has permissions, different projects have their tool calls filtered to reduce access to different repos. Or it could have a clearer UX and instructions and help making multiple tokens for the different use cases. The MCP server could check the token permissions and refuse to run until they're granular.
At a high level I think it's still appropriate to question the role MCP is playing, even if you can still blame AI enthusiasts for being cavalier in their approach to installing MCP servers and giving them blanket permissions.
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.
The role is very simple. It provides an interface for the AI to access the data. Whatever it has access to (via MCP), it will access. Simple as that.
> The problem I have with articles like this and people commenting is that it's framed as if MCP's vulnerability (...)
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.
It's not even an exploit. MCP is doing what it is MADE TO DO. It's made for interacting with the GitHub API. Whatever it has access to, it will access. If it has access to delete the repo, it will delete the repo. If it has access to the private repo, it will access the private repo.
> It's not even an exploit. MCP is doing what it is MADE TO DO.
You still don't understand the problem, do you? I mean, do you even understand the concept of an exploit?
SQL attack is different. There's clearly zero expectation that someone can, for example, enter something on a web page and extract database info or modify the database beyond what was intended by the API (e.g., update a single record).
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.
I don't understand your logic. Should security reports never be published that say "hash the password before storing it in the DB". Boring research is boring most of the time, that doesn't make it unimportant, no?
No, but it's not the database's fault if you don't hash your password. Same here, it's human error, not "MCP vulnerability". It's not that GitHub MCP needs fixing, but rather how you use it. That's the entire point of my reasoning for this "exploit."