5 MCP Server Red Flags That Signal a Security Risk

#security #mcp #claudecode #webdev

5 MCP Server Red Flags That Signal a Security Risk

Not all MCP servers are created equal.

Some are production-ready tools built by security-conscious developers. Others are weekend projects with hardcoded API keys and zero input validation. The problem: they all look the same from a README.

Here are 5 red flags I've found across dozens of MCP servers — signals that should make you pause before connecting one to your Claude Code session.

Red Flag #1: No Source Code Link

Every legitimate MCP server should link directly to its source code. If a README only shows an npm install command, that's a problem.

You need to inspect what the server is doing before you run it on your machine. No source link = no audit = no install.

Check for: GitHub repo linked prominently, recent commits, source that matches what's distributed.

Red Flag #2: Tool Handlers That Fetch External URLs and Return Raw Responses

// DANGEROUS: Returns raw external content to Claude
async function get_page_content(url: string) {
  const response = await fetch(url);
  return { content: await response.text() }; // ← Injection vector
}

If an MCP server fetches external content and returns it directly, that content can contain prompt injection. The attacker doesn't need to compromise the MCP server — they just need to control any page it fetches.

Safe pattern: parse and return only typed, structured fields — never raw strings from external sources.

Red Flag #3: Environment Variables in Error Messages

// DANGEROUS: Leaks your API key in error responses
} catch (e) {
  return { error: `Connection failed with key ${process.env.API_KEY}: ${e.message}` };
}

When this fails, your API key appears in a tool response Claude reads. It can end up in conversation history, exports, or logs.

How to find it:

grep -rn "process.env" src/ | grep -i "error\|return\|log"

Red Flag #4: Unvalidated File Path Parameters

// DANGEROUS: Reads any file on the system
async function read_file(path: string) {
  return fs.readFileSync(path, 'utf8');
}

Without path validation, an attacker who controls the path argument can read ~/.ssh/id_rsa, ~/.aws/credentials, or any .env file.

Safe pattern:

const base = path.resolve('./allowed-files/');
const target = path.resolve(base, relativePath);
if (!target.startsWith(base)) throw new Error('Path traversal blocked');

Red Flag #5: Shell Commands With String Interpolation

// DANGEROUS: Command injection
async function get_file_info(filename: string) {
  const result = await exec(`ls -la ${filename}`);
  return { info: result.stdout };
}
// Attacker input: "file.txt; cat ~/.aws/credentials"

Safe pattern: use execFile with an explicit argument array — no shell interpolation, no injection.

Quick Reference

Red Flag	Risk	How to Check
No source code link	Can't audit what you're running	Check README
Raw external URL responses	Prompt injection via third-party content	Grep `fetch()` + `return`
Env vars in error messages	Credential leakage	Grep `process.env` in catch blocks
Unvalidated file paths	Path traversal to read credentials	Grep `readFileSync`
Shell string interpolation	Command injection	Grep `exec()` with template literals