MCP Server Security Testing for Bug Bounty Hunters
MCP servers expose tools and resources to AI clients. In bounty scope they show up as IDE plugins, internal agent gateways, or customer-hosted connectors. The security question is simple: what can a tool do, and who is allowed to make it do that?
Inventory tools like an API surface
List every tool name, parameter schema, and resource URI template the server advertises. Treat each tool as an RPC endpoint. Typical danger zones:
- Filesystem read/write with user-controlled paths
- Shell or interpreter execution
- HTTP fetch tools that hit link-local or cloud metadata IPs
- Database queries built from string concatenation
- Browser automation that reuses an authenticated profile
If the server runs beside a developer laptop or a cloud agent with cloud credentials, impact climbs quickly. Confirm scope: attacking a vendor's hosted MCP bridge differs from testing your own connector against their app. Capture the exact server version and transport (stdio, SSE, HTTP) in notes—repro steps change with each.
Authn and authz gaps
Some MCP deployments trust the local socket and skip user binding. Others put a bearer token on the gateway but never map that identity into tool arguments. Try calling a "read mail" or "list tickets" tool while authenticated as user A with an id parameter for user B.
Resource URIs deserve the same IDOR mindset: file:///var/..., ticket://123, s3://bucket/key. Swap identifiers. Request ../ traversal on path-shaped parameters. Watch for URL fetchers that follow redirects to 169.254.169.254 or internal hosts.
I've seen servers validate tool names against an allowlist and then pass raw JSON arguments straight into subprocess or fs.readFile. The allowlist becomes theater. Also probe whether sampling or elicitation flows leak secrets into logs the client can read back.
Prompt-driven abuse vs direct tool calls
When the product only exposes MCP through a model, try prompt injection from untrusted content (a web page the fetch tool reads, a README in a repo the agent indexes). Direct tool invocation through a debug client is cleaner for proof when you have that access—use it if the program allows, and still show a realistic user path if required.
Keep proofs small: read a canary file you created, fetch a canary HTTP resource you control, or show a denied path returning contents it should not. Do not run destructive shell commands to "prove RCE" when a file write or DNS canary is enough.
Reporting without drama
Do not drop ransomware-style payloads or wipe directories. State the tool, arguments, trust boundary, and resulting access. Recommend least-privilege tool design, argument allowlists, per-user credentials for downstream APIs, blocklists for link-local ranges, and human approval for high-impact tools.
When the server proxies OAuth tokens into tools, state whether those tokens are scoped to the invoking user or to a shared service account. Shared bots turn one tool bug into a tenant-wide read.
MCP security is API security with a new handshake. Map the tools, break the assumptions about who invokes them, and stop at a clear canary.