4 ms·

> That's not surprising at all 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

> That's not surprising at all 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.

mirzap 1y ago
> 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.
- Xelynega 1y ago
  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?
  - mirzap 1y ago
    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."
- krisoft 1y ago
  > 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!
  - mirzap 1y ago
    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.
    - frabcus 1y ago
      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.
    - motorest 1y ago
      > 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.
      - mirzap 1y ago
        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.
        motorest 1y ago
        > 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?
    - 1y ago

mirzap 1y ago

> 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.

Xelynega 1y ago
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?
- mirzap 1y ago
  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."
krisoft 1y ago
> 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!
- mirzap 1y ago
  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.
  - frabcus 1y ago
    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.
  - motorest 1y ago
    > 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.
    - mirzap 1y ago
      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.
      - motorest 1y ago
        > 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?
  - 1y ago