mcp-server-pentest

Imported from forefy/.context (skills/llms/mcp-server-pentest/SKILL.md). Install upstream with npx skills add forefy/.context --skill mcp-server-pentest. Copyright stays with the author.

Contents

• Scope & authorization (blast-radius labels)
• Input modes: what a URL gets you, what a repo adds
• Passive:
  1. Inventory & transport fingerprint
  2. Destination-shaped tool parameters
  3. Credential scope & identity blast radius
  4. Config & secret storage (repo/host only)
• Active: 5. Session forgery, unauthenticated access & reachability 6. Confused-deputy SSRF via caller-chosen destination 7. Tool-argument injection
• False-positive gates
• Runnable snippets
• Output

Scope & authorization

Only run against an MCP server you own or are contractually engaged to test. Note the unusual consent shape: these checks speak JSON-RPC to the server directly, which bypasses the agent's tool-approval UI. Anything the operator believed a human would confirm before it ran will run unattended here. Confirm that is in scope before check 5.

Blast-radius labels:

• Passive (1, 2, 3, 4) - reads the server's own manifest, config and schemas. Check 1 completes the MCP handshake, which is one benign request the server is built to answer; nothing else leaves your machine.
• Active (5, 6) - live JSON-RPC to the target. Check 6 also reaches third parties (your OAST host, cloud metadata endpoints).
• Aggressive (7) - sends injection payloads through tools that may execute them. Run last, in a low-traffic window.

Input modes

The protocol is self-describing, so a URL alone carries most of the surface: tools/list returns a machine-readable schema of every tool and parameter before you send a single payload.

Transport decides more than source does. A stdio server has no URL and no listener: spawn it yourself, run 1, 2, 3, 4, 7, and skip 5 and 6 unless it also serves HTTP.

Passive

1. Inventory & transport fingerprint

Complete the handshake and record what the server admits to. POST JSON-RPC 2.0 initialize (Accept: application/json, text/event-stream), then notifications/initialized, then tools/list, resources/list, prompts/list.

Record: transport (streamable HTTP, legacy SSE, stdio), serverInfo name and version, negotiated protocolVersion, declared capabilities, bind address, whether the handshake required a credential (401 vs 200), and whether the server issues an Mcp-Session-Id response header and in what format. That format is the input to check 5.

Not a finding on its own. One thing worth noting while you are here: a server exposing a single *_api_request tool instead of ten typed tools has chosen passthrough, which is exactly what check 2 looks for.

2. Destination-shaped tool parameters

Over every inputSchema in tools/list, flag parameters that let the caller choose where the server connects or what it sends. Report an INSIGHT (this is the gate for check 7, not a finding by itself).

• Destination names: (?i)(^|_)(url|uri|endpoint|base[_-]?url|host|hostname|origin|server|target|address|addr|domain|proxy|callback|webhook|redirect)($|_)
• Passthrough shape: a tool taking method and path and body or headers together. This is full request forgery, not just destination choice, and it is the more dangerous of the two - caller-controlled method plus headers is what turns IMDSv2 back into IMDSv1 in check 7.
• Header override: an object-typed parameter named headers, extra_headers, additional_headers.

Record the tool name, the parameter, and whether the schema constrains it (enum, const, or a pattern anchored to a fixed host).

3. Credential scope & identity blast radius

An MCP server is an identity broker: it turns a caller's instruction into an action performed with the server's own credential and network position. Two questions.

Does one identity serve every caller? If the server holds a single service-account token and does not derive identity per caller, every caller inherits the full grant. Black-box tell: two different callers see the same tools/list and get the same results on an identity-revealing tool (whoami, get_current_user, list_projects).

Is that identity wider than the tools need? Classify each tool read / write / admin from its name and description, then, with explicit authorization, invoke the lowest-impact write tool and see whether it succeeds. A read-only integration whose token can write is over-scoped.

With repo or host access, skip the inference and read the configured token's actual grants.

Report a finding when: one shared identity backs all callers, or the identity's grants exceed the union of what the exposed tools require. Severity rises sharply if check 5 shows the server is reachable unauthenticated, because then the grant is public.

4. Config & secret storage (repo/host only)

Inspect claude_desktop_config.json, .mcp.json, .vscode/mcp.json, container env, compose files, and any systemd unit. Run the secret patterns from ../../applicative-pentest/webapp-probe/references/secret-regexes.md over them rather than duplicating the set here, and apply that file's placeholder gate - ${VAR} and <your-token> are not secrets.

Report a finding when: a long-lived credential sits in plaintext in a config the agent host reads, the file is group- or world-readable (check the mode), or a token is committed to the repo. Note that plaintext env in MCP config is the ecosystem norm, so rate it on the credential's blast radius from check 3, not on its mere presence.

Active

5. Session forgery, unauthenticated access & reachability - active

The MCP spec treats Mcp-Session-Id as a state reference for resumption, not a credential, and tells servers not to authenticate with it. Servers that validate the format and not the caller accept a session that was valid but never issued. Test three variants in order, stopping at the first that succeeds:

• a. No credential at all. Full handshake with no auth header. If tools/list returns a catalog, the server is simply unauthenticated and you do not need forgery.
• b. Fabricated session. Mint a value in the format check 1 observed (commonly mcp-session-<uuidv4>), send it as Mcp-Session-Id on tools/list, then on a read-only tools/call.
• c. Borrowed session. If another caller's ID is observable (logs, a shared proxy, a referrer), replay it. This is fixation/hijack rather than forgery.

Record where the server is reachable from as part of the same check: a loopback binding limits the blast radius of everything above, a routable binding makes it public. Reachability is not a separate finding, it is the multiplier on this one.

Report a finding when: any variant returns a tool catalog or executes a call. Rate the two outcomes separately - a catalog is information disclosure, an executed tools/call is full authentication bypass. Severity is critical when the executed tool then acts with the server's stored credential, which is the chain the Grafana MCP advisory describes: the caller never held the service-account token, and the upstream API still recorded the request as that account.

6. Confused-deputy SSRF via caller-chosen destination - active, active-3rdparty

For each parameter from check 2, in this order:

1. OOB canary first. Point the parameter at a unique subdomain of your OAST host. This proves the server connects without touching anything internal. Hand the listener work to the ssrf-oob skill rather than rebuilding it; encode the tool and parameter name into the subdomain label so the hit attributes itself.
2. Credential-attachment test. Aim the parameter at a host you control and read what arrived. Does the server attach its own token to a destination that is not the configured upstream? A server that strips credentials on host change (Grafana already did) still has an SSRF primitive, but credential-attached SSRF is a full tier more severe. Establish which one you have before rating it.
3. Internal reach. Loopback, private and link-local ranges, and cloud metadata:
   • AWS IMDSv2 is a two-step and needs method plus header control: PUT http://169.254.169.254/latest/api/token with X-aws-ec2-metadata-token-ttl-seconds: 21600, then GET .../latest/meta-data/iam/security-credentials/ carrying X-aws-ec2-metadata-token. A passthrough tool that exposes both is what makes IMDSv2 no better than v1 here.
   • GCP http://metadata.google.internal/computeMetadata/v1/ with Metadata-Flavor: Google.
   • Azure http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01 with Metadata: true.

Report a finding when: the OAST listener records a hit, the response body carries metadata or internal-service content, or an internal-only host answers. Severity: critical for credential-attached SSRF or a returned cloud credential.

7. Tool-argument injection - aggressive

Target tools whose name or description implies a shell, a filesystem, a query language, or template rendering. With repo access, grep for child_process, spawn, exec, subprocess, os.system, eval, and unnormalized path joins first, and test only those tools - blind fuzzing across every tool is noisy and mostly hits validation.

Payload classes: command separators (; id, $(id), backticks, | id), path traversal (../ chains, absolute paths, null byte), SQL/NoSQL where a query is accepted, and template markers where output is rendered.

Report a finding when: the OAST listener fires, or the response carries the artifact (command output, file contents, an evaluated expression).

False-positive gates

Each of these has produced a wrong severity in practice. Apply them before reporting.

• Check 5 must run from an unauthenticated network position. Many deployments front the server with a gateway that injects auth or strips headers. Testing from inside that boundary turns a normal configuration into a false critical. State in the report which network position produced the result.
• Check 2 is not check 6. A url parameter constrained by enum, const, or a host-anchored pattern is not a primitive, and a url used as a data field (a dashboard link stored as text) is never fetched at all. Confirm the server actually connects before promoting an insight to a finding.
• Check 7 rejects echoed errors. MCP servers commonly return the underlying tool's error verbatim, so an error message containing your payload proves parsing, not execution. Require the artifact.
• Check 6 allowlists need three attempts before you call them sound. Resolved-IP literal, a redirect to an internal host, and DNS rebinding. A single blocked hostname proves nothing.
• Check 3 needs evidence, not tool names. delete_dashboard in a catalog is not proof the token can delete. Confirm with an authorized write probe or the config.

Runnable snippets

Set URL to the server endpoint. Streamable HTTP shown; for legacy SSE, GET /sse first and POST to the session endpoint it returns.

# 1 handshake + surface dump
INIT='{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}'
curl -sik -X POST "$URL" -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' -d "$INIT" | tee /tmp/init.txt
SID=$(grep -i '^mcp-session-id:' /tmp/init.txt | cut -d' ' -f2 | tr -d '\r')
echo "issued session: ${SID:-none}"
curl -sk -X POST "$URL" -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' ${SID:+-H "Mcp-Session-Id: $SID"} \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' > /tmp/tools.json

# 2 flag destination-shaped and passthrough parameters
python3 - /tmp/tools.json <<'PY'
import sys,json,re
d=json.load(open(sys.argv[1]))
dest=re.compile(r'(?i)(^|_)(url|uri|endpoint|base[_-]?url|host|hostname|origin|server|target|address|addr|domain|proxy|callback|webhook|redirect)($|_)')
for t in d.get("result",{}).get("tools",[]):
    props=(t.get("inputSchema") or {}).get("properties",{}) or {}
    hits=[p for p in props if dest.search(p)]
    passthru=[k for k in ("method","path","body","headers") if k in props]
    if hits: print(f"{t['name']}: destination params {hits}"
                   f"{' CONSTRAINED' if any(k in props[h] for h in hits for k in ('enum','const','pattern')) else ''}")
    if len(passthru)>=3: print(f"{t['name']}: PASSTHROUGH {passthru} <- method+header control")
PY

# 5 session forgery - (a) no creds, then (b) a session that was never issued
FAKE="mcp-session-$(uuidgen | tr 'A-Z' 'a-z')"
for hdr in "" "Mcp-Session-Id: $FAKE"; do
  echo "--- ${hdr:-no session header}"
  curl -sk -o /tmp/r -w '%{http_code}\n' -X POST "$URL" -H 'Content-Type: application/json' \
    -H 'Accept: application/json, text/event-stream' ${hdr:+-H "$hdr"} \
    -d '{"jsonrpc":"2.0","id":3,"method":"tools/list"}'
  grep -q '"tools"' /tmp/r && echo "  CATALOG RETURNED - session accepted as authorization"
done

Output

Two-part ledger, then a verdict:

• Passive - per class (1, 2, 3, 4): what the surface is, with the tool and parameter names behind each insight. Say which input mode you had, since 4 and half of 3 are unreachable from a URL.
• Active - per check (5, 6, 7): check / blast radius / run? / result, with the confirming request for every hit, and the network position check 5 ran from.

Report each check's true status - run, not-run, not-applicable-for-this-transport, or blocked. A stdio target legitimately skips 5 and 6; say so rather than reporting them clean. A clean check 6 only means the parameters from check 2 did not reach out, and if check 2 found nothing there was nothing to test.

Reference: Pillar Security, "Valid but never issued: session spoofing and SSRF in Grafana MCP" (CVE-2026-19516), which is the source for checks 5 and 6.