MCP server · GitHub
GitHub MCP Server
GitHub's official MCP server: repositories, issues, pull requests, Actions and code scanning, available locally or as a hosted remote server.
What it is, and what it costs you
This is the highest-leverage MCP server most engineering organisations will connect, and the one whose authorization decisions matter most. It gives an agent the ability to read repository contents, search code, open and comment on issues and pull requests, inspect CI runs, and — depending on the toolsets enabled and the token provided — push changes. GitHub ships both a hosted remote endpoint and a self-hosted local build, and offers toolset selection plus a read-only mode so the granted surface can be narrowed.
The security question is not whether GitHub is trustworthy. It is that this server connects an agent to the richest source of attacker-writable text in a software company. Issue bodies, pull request descriptions, review comments, commit messages, and code comments are all authored by people outside the trust boundary on any public repository — and by anyone with a fork on many private ones. Every one of those fields is content the agent will read and, structurally, cannot distinguish from instruction.
That makes the standard indirect prompt injection chain concrete. An attacker files an issue on a public repository containing instructions. A maintainer asks their agent to triage open issues. The agent reads the payload, and now holds a token that can read private repositories and open pull requests. Public research through 2025 demonstrated exactly this pattern against agent-plus-GitHub configurations, with private repository contents surfaced into attacker-visible pull requests.
Mitigation is mostly about token scope and the read/write boundary, not about the server. An agent that triages issues does not need write access. An agent working in one repository does not need a token valid across the organisation. And a session that has just read a public issue is precisely the session that should not also hold private-repository read access.
Capability profile
What this server can reach, and why a security team cares. These are capabilities the server has by design — derived from the publisher's documentation, not from a scan.
- repository read
Any private repository the supplied token can reach becomes readable content in the agent's context — and therefore exfiltratable if the session has any egress path.
- issue / PR write
The agent can publish content to a location an attacker can read. This is the exfiltration channel in most demonstrated GitHub agent attacks, and it does not require network egress.
- untrusted text ingestion
Issues, PR bodies, review comments and code comments are attacker-authored on public repositories. This is the injection entry point, not an incidental risk.
- CI / Actions visibility
Workflow definitions and run logs frequently contain secret names, internal hostnames, and deployment topology.
Restrict this before you roll it out
- Grant read-only unless writing is the point
The server supports a read-only mode and per-toolset selection. Most agent workflows — review, triage, search, explain — need no write scope at all.
- Scope the token to specific repositories
A fine-grained token limited to the repositories in scope contains the blast radius. An organisation-wide classic token makes every repository reachable from any injected session.
- Separate the public-reading agent from the private-reading one
Do not let one session both ingest attacker-authored public content and hold private-repository access. That combination is the whole vulnerability.
- Enable only the toolsets in use
Every enabled tool's definition also occupies context on every request, so trimming toolsets improves cost and reduces the surface at the same time.
Vincosha Assay assessment
not yet assessedWe have not published a scan verdict for GitHub MCP Server.
Everything above is a capability profile compiled by hand from the publisher's own public documentation on 2026-07-25. It describes what this artifact can reach and what to restrict before rolling it out. It is not a security verdict, and it should not be read as one.
When Vincosha Assaypublishes an assessment for this artifact it will appear here with a verdict, the findings behind it, and the date it ran. We would rather leave this space empty than fill it with a guess — inventing a security verdict about somebody else's software would be both wrong and dangerous.
What an assessment covers
- prompt-injection patterns in descriptions and instructions
- credential reads and outbound egress in bundled code
- over-scoped permissions and manifest claims
- typosquatted and impersonating names
- tool-manifest drift since the last approval
- content hash against the version you approved
Sources
This profile was compiled from the publisher's own documentation. Products change — verify against the source before making a decision that depends on a specific detail.