Attack scenario 2: Over-privileged credentials enable lateral movement

Attack scenario 2: Over-privileged credentials enable lateral movement

A compromised MCP server is dangerous. An over-privileged compromised MCP server is catastrophic.

How the attack works

A team deploys a GitHub MCP server to help developers search for code and manage issues. The server needs read access to repositories and the ability to create and update issues. Instead of creating a fine-grained personal access token scoped to repo:read and issues:write, the team uses a classic GitHub PAT with full repo scope, which grants read and write access to every repository in the organization, including private ones that contain infrastructure-as-code definitions, secrets configuration, and deployment scripts.

An attacker who compromises this MCP server via any of the other vectors described in this article now has write access to every repository in the organization. They can modify CI/CD pipeline configurations, inject malicious code into deployment workflows, or access credentials stored in private repositories.

Why the attack succeeds

The attack works because the credential has far more permissions than the MCP server actually needs. The following diagram illustrates the gap between required and granted permissions.

The dangerous gap between the permissions an MCP server needs and what it is typically granted.

This over-provisioning is endemic to MCP deployments. Astrix Security's research found that 53% of MCP servers rely on static API keys or personal access tokens, and these tokens are rarely scoped to the minimum required permissions because fine-grained scoping requires more setup effort.

A related risk is the confused deputy problem. If the MCP server uses a global service token instead of a user-scoped credential, it may have permissions the user does not. The AI can then trigger actions using the server's privileges rather than the user's, effectively performing operations the user was never authorized to execute.

What to look for

• Write operations (push, merge, deploy) from tokens that should only be reading
• API activity outside of normal working hours or from unexpected IP addresses
• GitHub API calls to repositories that the MCP server's documented functionality does not require
• Access to repository branches that contain infrastructure or secrets configuration

How to defend against it

• Use fine-grained personal access tokens: GitHub, GitLab, and most modern platforms now offer tokens that can be scoped to specific repositories and specific permission sets. Apply the principle of least privilege by creating API keys or SSH keys that grant exactly the permissions needed and nothing more.
• Separate read and write credentials: If your MCP server needs both read access (e.g., for searching) and write access (e.g., for creating issues), use two separate tokens with distinct scopes. This limits the damage if either token is compromised.
• Use token exchange for user-scoped access: Exchange a user's identity token for a short-lived service token scoped to that user's permissions. This prevents the MCP server from executing actions that the user themselves cannot perform.
• Audit token permissions periodically: Permissions requirements change as MCP server functionality evolves. A token that was appropriately scoped at creation may have become over-privileged as features were added. Schedule quarterly reviews of every token used by MCP servers.