MCP Security: What to Check in Your mcp.json

A design flaw in the Model Context Protocol (MCP) STDIO transport passes configuration values directly into shell execution without sanitization, allowing anyone who can influence the config file to execute arbitrary shell commands on the host machine, according to a cybersecurity analysis. The issue is present across the Python, TypeScript, Java, and Rust SDKs and affects tools like claude_desktop_config.json or mcp.json, where inline secrets and commands create a massive attack surface. The author recommends auditing deployments by checking for STDIO servers with inline secrets using a jq command to verify transport methods and credential exposure.

MCP Security: What to Check in Your mcp.json claude desktop config.json or mcp.json to get your tools running, you're likely running code with a design flaw baked into the reference architecture.The issue is simple: MCP /en/tags/mcp/ 's STDIO transport passes configuration values directly into shell execution without sanitization. This means anyone who can influence your config file—via a compromised npm package or a malicious toolchain—can execute arbitrary shell commands on your host machine. This isn't a bug in a single implementation; it's present across the Python, TypeScript, Java, and Rust SDKs. The Tool Layer Risk In any AI workflow, I view the "Tools" layer as the most dangerous. A hallucination in the Model layer gives you a wrong sentence, but a flaw in the Tool layer leads to a wrong action on a live system. MCP was designed to standardize how models reach outside themselves to hit databases or APIs. While this kills the need for custom integration code, it also kills the manual review process. We've gone from requiring an engineer's sign-off on a custom integration to blindly pasting a JSON block that grants an agent full read/write access to production. Take this typical config: { "mcpServers": { "postgres-prod": { "command": "npx", "args": "-y", "@some/postgres-mcp-server" , "env": { "DATABASE URL": "postgres://user:pass@prod-host:5432/db" } } } } This is a massive attack surface compressed into a few lines of text. Practical Audit for Your Config Since this is a reference architecture decision, you can't just "update" it away. You have to audit your own deployment. I've started running a quick check to identify which of my servers are using STDIO with inline secrets. crude pass at spotting STDIO servers with inline secrets in your config jq -r '.mcpServers | to entries | select .value.command = null | .key' ~/.config/ /mcp.json 2 /dev/null Note: Adjust the file path based on where your specific client stores the config. The goal here is to stop trusting a server based on its name and start verifying the transport method and credential exposure for every single entry. If you're using a remote transport with a proper auth boundary, you're in a much better spot than those relying on local STDIO. Next Cybersecurity Interview Prep: A Complete Guide → /en/threads/3171/