MCP Security Self-Audit Checklist
Walk your own MCP servers through 12 questions. Covers the April 2026 STDIO RCE class of vulnerabilities (10 CVEs). No email required, no data collected. Take the answers into your own security review.
Does any MCP tool build a shell command from unsanitized input?
Search your MCP server code for subprocess, os.system, exec, eval, or child_process.exec where any argument is not a string literal.
If YES: you have the primary vulnerability class. Fix: replace with argument-array form (subprocess.run([...], shell=False) / child_process.execFile) and whitelist the exact arguments allowed.
Are you running STDIO when HTTP+SSE with auth would work?
STDIO is the simpler transport but trusts the subprocess boundary as a security boundary. HTTP+SSE with bearer-token auth is harder to exploit.
If your MCP server is exposed beyond one trusted user on localhost, migrate to HTTP+SSE with auth. If you can’t migrate, add input validation + subprocess sandboxing at every tool entry.
Do your subprocess calls pass a clean environment?
By default, subprocess.run(...) inherits the parent process’s environment, including secrets. A compromised tool can exfiltrate your API keys.
Fix: pass env={} or an explicit allowlist of only the env vars the tool needs. Never inherit by default.
Does every tool validate its arguments against a strict schema?
The MCP SDK accepts JSON Schema per tool. Many implementations declare the schema but never validate against it at runtime.
If your tool takes a filename argument, validate the type, the length, and the pattern (no .., no absolute paths if you want relative-only). Reject before any subprocess call.
Does the MCP server run with write access outside its designated directory?
A tool designed to read docs shouldn’t be able to write to ~/.ssh/authorized_keys.
Run the MCP server as a non-privileged user with write access only to a dedicated working directory. On Linux, a systemd unit with ReadWritePaths= + NoNewPrivileges=true is the minimum.
Could a tool surface environment variables to the model?
If the model can call a shell or env tool, a prompt-injection attack could read ANTHROPIC_API_KEY or STRIPE_SECRET_KEY and exfiltrate via a subsequent tool call.
Keep API keys in a secret manager accessed only by the MCP server process, not by shell tools. Consider Septim Vault ($29, browser-based encrypted store) as a developer-machine alternative.
Does each tool have the minimum permissions it actually needs?
Most MCP servers declare one tool and give it the world. A read_docs tool with filesystem + network + exec = a compromised tool that can do anything.
Audit each declared tool. Pin to the smallest permission set possible. If you can’t separate, split into multiple tools with narrower scopes.
Does any tool do more than its description claims?
LLMs trust the description. Attackers read the code. A tool described as "search local notes" that also has a filesystem-write path is a deception surface.
Match the tool’s declared capabilities to its implementation boundary. If the code can do more, either narrow the code or update the description.
Can you reconstruct what any tool actually did post-incident?
Most MCP servers log tool calls. Few log the arguments and results. Post-incident forensics requires both.
Log every tool call with: timestamp, tool name, arguments (redacted of secrets), result hash, duration. Retain 30+ days.
Are your MCP server dependencies pinned and reviewed?
If your server pulls @modelcontextprotocol/sdk-latest, you’re trusting every future npm publish by that maintainer without review.
Pin exact versions. Review dependency updates before bumping. Check the package’s install script — some MCP packages run postinstall scripts that execute arbitrary code.
Can a single prompt trigger unbounded loops, recursion, or fork bombs?
A tool that retries on failure without backoff, or spawns subagents without caps, will happily burn your Anthropic credits for hours.
Every tool gets: max-call-count per session, max-retry count, max-wall-clock per tool. Exceed = hard fail, not retry. (See Septim Subagent Cost Guard for budget-cap automation.)
After fixing 1-11, can you export a hardened config for your team?
If you fixed all 11 checks once, every teammate running the same server needs the same fixes.
Ship the hardened config as a single versioned file (mcp-config.hardened.yaml). Commit it. Require teammates to use it. Review on every dependency bump.
Want this automated across every server you own?
Septim Spire is a CLI that runs these 12 checks (plus 3 more deferred to v1.1) against every MCP server in your ~/.claude/ config. $199 one-time, founding rate for the first 20 buyers. Ships May 2026.
Disclaimer: this checklist is educational. It is not a penetration test, a SOC 2 audit, or legal compliance advice. For high-stakes environments, engage a qualified security firm. Septim Labs is not a law firm. CVE identifiers and Ox Security research referenced per their public disclosures (April 15, 2026).