GitHub MCP Exploited: Accessing private repositories via MCP
42 points by op
42 points by op
Why are we still doing this? What is even the point?
“Yes I’d like to shove an unproven technology literally everywhere I can with almost zero regard for user privacy or agency.”
“Yes I’d like to be able to ask the bot nicely to give me private data.”
The post detailing the attack and findings is here: https://invariantlabs.ai/blog/mcp-github-vulnerability
An important excerpt:
Importantly, this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level. This means that GitHub alone cannot resolve this vulnerability through server-side patches.
Wow the original report is not very clear about this, too busy trying to push their product I guess. The simple mitigation here if you are using github-mcp or something similar:
What makes this a bit difficult, in particular with GItHub, is that there are about 15 different ways you can integrate “Copilot” into your workflow, and determining how things are actually integrated and what they have access to is not easy at all. There needs to be much better education and UI/UIX around this.
Social engineering our AI overlords to hurt each other. I like the gallows humor.
@simonw: Do you know if the harmful behavior here will happen in the default configuration? Do I need to turn something on in one of my repos to make myself vulnerable or am I screwed regardless?
I mean, the first thing is that if you’re not running Github MCP, you’re not vulnerable. You have to specifically add this MCP tool to your MCP-compatible LLM and give it a github auth token before any of this matters.
The “default configuration” for calling MCP tools, at least in Claude Desktop, includes an “Allow calling tool” dialogue. If you always review that carefully, and don’t ever click “always allow”, and then deny any request to call a tool which you don’t expect, that seems sufficient for avoiding this attack.
Ah, good. Thank you. I use GitHub for one thing I’d be concerned about with this, but I don’t use MCP or LLM tools at all and I was mainly worried if I needed to do anything to protect myself from this.
I’ll confess that I have not done any development with MCPs, agents, or AIs. So, I’m just pontificating based on what I’ve read over the last few years.
It seems inappropriate to implement access controls by parsing a prompt for malicious intent or scoping what data should be used, modified or accessed when following through on the prompt. Aren’t all prompts evaluated statistically, and as such, their behavior is non-deterministic and a loosey-goosey way to control access to data?
Now, I imagine there are at least two types of data the LLM has access to. The first category is training data, and as such, it’s encoded and foundational in its model. I imagine it’s tough to establish guardrails around who can access and use such data. The second category is context data, and the case Simon describes is an example of this. Context data is accessed in real-time and incorporated into the prompt used to extrude the synthetic text response. Would it be easier to martial access to the context data?
I’m considering an RBAC model where users authenticate to the LLM. Then, the LLM connects to its underlying data sources using the user’s identity, assuming the user’s associated access control lists with something like Cedar (https://www.cedarpolicy.com/en) rather than having global access and relying on prompt parsing and intent detection.
I’m considering an RBAC model where users authenticate to the LLM. Then, the LLM connects to its underlying data sources using the user’s identity, assuming the user’s associated access control lists with something like Cedar (https://www.cedarpolicy.com/en) rather than having global access and relying on prompt parsing and intent detection.
I think this should be possible with MCP today. You’d include the auth token in the prompt or context, and define token as an input to the MCP server tool that would reach out to whatever API. That should be enough for the LLM to figure out how to get everything where it needs to be. Tricky bit (as the linked article demonstrates) is making sure you don’t let sensitive data you got back from an API endpoint call leak out where it shouldn’t be.