MCP SERVER SECURITY AUDIT

An MCP server hands an AI agent real capabilities — files, shells, network, APIs. The trust boundary is the tool call. Every tool description is prompt the model reads, every tool result is data the model may act on, and every side-effecting tool is an action taken on someone's behalf. Audit all three.

THE ONLY QUESTION THAT MATTERS

"Can untrusted input — a tool description, a fetched page, a file's contents, another server's output — cause this agent to run an action the user never approved, leak a secret, or reach a resource outside scope?"

If yes, that's the bug. If no, move on. Theoretical "a malicious server could…" without a reachable path is not a finding — show the path.

0. QUICK KILL CHECKLIST

[ ] Enumerate every tool: name, description, params, side effects, return data
[ ] Flag state-changing tools with NO approval gate (write/delete/exec/send/pay)
[ ] Flag tools whose DESCRIPTION contains instructions to the model (tool poisoning)
[ ] Trace every param that reaches: filesystem, shell, HTTP, SQL, eval
[ ] Check tool RESULTS for: secrets, internal hosts, raw error/stack traces
[ ] Confirm scope enforcement happens server-side, not "the model will behave"
[ ] Check transport: stdio env leakage, HTTP without auth/localhost binding
[ ] Check for token passthrough (client creds forwarded to downstream APIs)
[ ] Check for rug-pull: can tool definitions change after user approval?

1. THREAT MODEL — THREE TRUST BOUNDARIES

The model is a confused deputy: it holds the user's authority and will use it on instructions from any of these channels unless the server constrains it.

2. TOOL POISONING (description-level injection)

The description field of a tool is fed to the model verbatim. A malicious or compromised server can smuggle instructions there.

Hunt:

[ ] Dump every tool description (bughunter mcp tools, or list_tools)
[ ] Grep descriptions for imperative verbs aimed at the model:
    "ignore", "also", "first read", "before responding", "do not tell",
    "<important>", invisible/zero-width chars, base64 blobs
[ ] Check for unicode tag chars (ASCII smuggling) — U+E0000..U+E007F
[ ] Compare advertised behavior vs actual code behavior

Fix pattern: descriptions are documentation, not control. Clients should render them as untrusted; servers should keep them plain and factual.

3. UNSCOPED / OVER-PRIVILEGED TOOLS

The most common real bug. A tool does more than the user authorized.

Rule: scope must be enforced in server code (allowlist, canonicalized path check, arg arrays, parameterized queries) — never "the model won't ask for that."

4. APPROVAL GATES ON SIDE EFFECTS

Read-only tools can run freely. Anything that changes state or spends money/quota needs an explicit gate.

[ ] List every tool with a side effect
[ ] For each: is there an approve=true param, env flag, or client confirm?
[ ] Can the gate be bypassed by the model setting approve itself?
[ ] Are "discovered" resources (new hosts, new files) auto-authorized? (should NOT be)
[ ] Is anything auto-submitted / auto-sent without a human in the loop?

Good sign (this repo's own server): active tools require approve=true or BBHUNT_MCP_APPROVE=1, scope must be set first, reports are never auto-submitted, target content is treated as untrusted data. Use that as the reference bar.

5. RESULT-CHANNEL LEAKS & INJECTION

[ ] Do tool results include secrets? (API keys, tokens, full env, connection strings)
[ ] Do errors return raw stack traces / internal paths / SQL?
[ ] Is fetched/third-party content passed back without a "this is untrusted data" frame?
[ ] Could a returned document instruct the model to call another tool? (indirect injection)

Redact secrets server-side before return (this repo ships a redact.py — check it actually covers the tokens in scope).

6. RUG-PULL & CONFUSED DEPUTY

[ ] Can a server change a tool's definition AFTER the client approved it? (rug-pull)
[ ] Does one server's output get fed as another server's input without revalidation?
[ ] Token passthrough: does the server forward the client's credentials to a downstream
    API, letting the model reach things the user didn't intend? (OAuth confused deputy)

7. TRANSPORT & CONFIG

[ ] stdio: are secrets passed via env? are they logged / echoed in doctor output?
[ ] HTTP/SSE: bound to localhost or 0.0.0.0? any auth? CORS wide open?
[ ] Is the mcpServers config using an absolute pinned command, not a writable relative path
    an attacker could hijack? (supply-chain of the server binary itself)
[ ] Pinned version / integrity of the installed server package?

8. SOURCE-AUDIT GREP (Python FastMCP / Node SDK)

# Python
grep -rnE "os\.system|subprocess.*shell=True|eval\(|exec\(|open\(.*\.\." .
grep -rnE "@(mcp|server)\.tool|def .*\(.*\) ->" .    # enumerate tool defs
grep -rniE "approve|scope|allowlist|BBHUNT_MCP_APPROVE" .  # gate coverage
# Node / TS
grep -rnE "child_process|exec\(|execSync|new Function|fs\.readFile.*\.\." .
grep -rnE "server\.tool\(|registerTool|inputSchema" .

For each tool: map param → sink. No sanitizer between them = candidate finding. Confirm reachability before you write it up.

9. REPORT LINE (per finding)

Tool: <name>
Channel: description | result | param
Untrusted source: <where attacker input enters>
Sink / action: <file | shell | http | sql | state-change>
Gate present?: none | bypassable | ok
Impact: <secret leak | RCE | SSRF | unapproved action>
PoC: <exact tool call + input that proves it>
Fix: <allowlist | arg array | approval gate | redact | pin>

Kill anything you can't prove with a concrete call. "Could be abused" is not a bug — show the call that abuses it.