GitHub MCP Vulnerability: How a Public Issue Can Expose Your Private Repositories

One Routine Request That Could Empty Your Private Codebase

Imagine this scenario: you ask an AI agent to check the issues in your GitHub repository. It's about as routine as development tasks get. But what if one of those issues is a carefully crafted trap? The result could be your private repository getting fully leaked to a public channel.

This is exactly the attack technique recently disclosed against GitHub MCP (Model Context Protocol) servers. No system was "broken" in the process — the GitHub MCP server functioned exactly as designed, and the agent only performed actions within its granted permissions. The root cause is simpler and more unsettling: the agent had access to everything.

Breaking Down the Attack Chain: From Public Issue to Private Leak

What makes this attack clever is that it doesn't exploit a code vulnerability — it exploits an agent's "excessive trust" and "excessive authorization." The attack chain breaks down into a few steps:

• An attacker creates an issue in a public repository;
• You ask your AI agent to check the issues;
• The issue's content is actually a set of instructions that tricks the agent into reading your private repository;
• The agent complies, then publishes the retrieved private content in a public Pull Request.

This is a classic combination attack: indirect prompt injection paired with permission abuse. The issue text becomes the injection vector, and the agent lacks any boundary awareness around "data flow direction" — so private data crosses the public-private boundary and is exposed to everyone.

Why the MCP Server Isn't "At Fault"

It's worth emphasizing that the GitHub MCP server didn't malfunction or get bypassed at any point. It faithfully executed the API calls issued by the agent. The real problem lies in the authorization model — when an agent is given a token that can simultaneously access public and private resources and operate across repositories, it inherently has the ability to move private data to a public location.

In other words, this isn't a "bug." It's an architectural trust assumption failure. The agent is trusted by default, but never constrained to a reasonable scope of operation.

Indirect Prompt Injection is a variant of prompt injection attacks. Unlike directly entering malicious instructions into a chat interface, the attacker embeds malicious instructions into external content that the agent will proactively read — web pages, documents, emails, code comments, or in this case, GitHub issues. When the agent retrieves and processes this content, the malicious instructions are executed as legitimate contextual directives rather than being recognized as external data.

The danger of this attack class lies in its extremely distributed attack surface: any external text the agent has permission to read is a natural potential injection vector. LLMs don't inherently distinguish between "data" and "instructions" — they process all input as a unified token sequence. This means that even seemingly harmless content-retrieval operations can trigger high-risk cross-system actions, provided the agent has sufficient permissions.

MCP (Model Context Protocol) is an open protocol led by Anthropic, designed to standardize how AI models interact with external tools and data sources. Think of it like a USB interface — it doesn't dictate what a device does, only how the device connects. MCP servers act as a middleware layer, wrapping the API capabilities of external resources like GitHub, databases, and file systems into a unified interface for AI agents to call.

GitHub's official MCP server lets agents perform operations like reading issues, creating PRs, and querying code via natural language instructions. Its design goal is "maximum capability" — exposing as much of the GitHub API's functionality as possible so agents can flexibly complete tasks. This goal is in natural tension with security's "principle of least privilege": the protocol itself has no built-in permission sandbox, and access boundaries are entirely determined by the scope of permissions bound to the token passed by the caller.

The Core Defense Principle: Scope Beats Trust

The core defensive philosophy proposed against this class of attacks can be summarized in one line: Scope beats trust.

Rather than assuming the agent will "behave properly," strictly limit what it can reach from the very beginning. A few concrete implementations:

Single-Repository Session Isolation

Grant access to only one repository per session (one repository per session). Even if an issue contains malicious instructions, the agent has no way to cross over to other private repositories and read data. The attack chain is severed at the first step.

Leased Privilege Tokens

Use leased privilege tokens — short-lived, least-privilege temporary authorizations rather than long-lived, broad-scope tokens. Permissions are revoked as soon as the task is done, dramatically shrinking the attack window.

The design philosophy behind leased privilege tokens comes from the Temporary Credentials model in cloud security — AWS STS (Security Token Service) is the most canonical implementation. Compared to long-lived static tokens, temporary credentials have built-in expiration times (typically on the order of minutes to hours) and can be actively revoked after task completion, effectively compressing the impact window of a "credential leak" from months down to minutes.

This model is especially significant in AI agent scenarios. A static broad-scope token, once captured by a malicious prompt injection and forwarded externally, can be continuously abused by an attacker for its entire validity period. But if each agent session dynamically issues a short-lived token carrying only the minimum permissions needed for that specific task, even a successful injection yields credentials that expire almost immediately and are strictly scoped — preventing the attacker from expanding their foothold.

Require Approval for Private-to-Public Data Movement

Any operation that moves private data to a public location should trigger explicit approval (approve anything that moves private data into public). This is the last line of defense against data crossing the public-private boundary. Even if every prior safeguard fails, this human or policy-based approval can still prevent the leak from actually occurring.

The Principle of Least Privilege (PoLP) is one of the foundational principles of information security. It requires that any program, user, or system component should have only the minimum permissions necessary to complete its current task — not a single permission more. The principle traces back to Saltzer and Schroeder's systematic work on secure design in the 1970s, and has since become a core pillar of Zero Trust Architecture.

Applying this principle to AI agents means completely abandoning the deployment mindset of "give the agent a universal token and trust it to do the right thing." An agent's "intelligence" and "self-discipline" cannot substitute for technical permission constraints — when facing carefully crafted prompt injections, the success rate of relying on model judgment to reject malicious instructions is far from reliable. Scope restrictions are a fallback mechanism that remains effective even when model judgment fails.

Implications for AI Agent Security

This case is a wake-up call for every team deploying AI agents and MCP toolchains. As more and more development workflows get handed off to agents for automation, what permissions an agent holds is far more worth scrutinizing than how smart the agent is.

A few points worth remembering:

• Indirect prompt injection is a real threat; any externally controllable text (issues, comments, documents) can become an attack vector;
• Agent permissions should follow a minimization principle — default deny, not default trust;
• Boundaries around data flow direction (especially private to public) must have independent control mechanisms.

As described in the referenced content, the Certified MCP Security Expert lab environment lets learners reproduce this attack hands-on — and then patch it themselves. This "attack first, defend second" training approach is tremendously valuable for understanding MCP security boundaries.

Conclusion

The most profound insight from this vulnerability is this: no software malfunctioned, everything "worked as designed," yet the result was a catastrophic data leak. It reveals an underappreciated risk in the age of AI agents — when we hand execution authority to an agent, what truly needs hardening is the boundary of permissions, not our trust in the agent's behavior. Scope beats trust. That principle should be the default assumption for every MCP deployer.