Anatomy of a credential leak — four patterns across 38 of 101 MCP servers

What the engine looks for

The matcher fires on string literals that look like credentials. The provider-prefix list covers OpenAI / Anthropic-style keys (sk-…, sk-ant-…), GitHub personal access tokens (ghp_…), GitHub OAuth tokens (gho_…, ghs_…, ghu_…), AWS access keys (AKIA…), Stripe test secrets (sk_test_…), and Slack tokens (xoxb-…, xoxp-…). Anything matching the shape is flagged HIGH; the surface tier (where the file lives in the tree) determines the deduction weight.

Across the 18 repos that hit on this pattern, the breakdown by secret type is:

The most-hit category — OpenAI/Anthropic-style API keys — is also the most-installed-by-developers category, because every example notebook for any LLM-adjacent product ships with a "paste your key here" placeholder that ends up in git add. The lastmile-ai/mcp-agent repo has 8 such findings spread across examples/basic/mcp_basic_agent/main.py, examples/basic/mcp_tool_filter/mcp_agent.secrets.yaml.example, tests/cli/fixtures/test_secrets_deploy.sh, and tests/utils/test_config_preload.py — a textbook spread of "documentation copy + integration-test fixture + scaffold template." All eight sit in the low-weight examples/ and tests/ tier and add up to a -30 to credentials, leaving the repo at C overall.

The high-impact end of the distribution looks different. mcp-use/mcp-use (9,804 stars) has five HIGH findings in docs/python/client/authentication/bearer.mdx and docs/typescript/client/authentication.mdx — those files render to the public docs site as authentication-flow examples. Every reader of the bearer-token documentation sees a real-looking sk-… string in the example. The .mdx path means the surface tier classifies as production (docs are part of the user-facing surface), so each finding deducts -30 — and the credentials axis crashes from 100 to 0. The repo grades F overall because of these five lines alone.

The four worst single-repo offenders are named in the table below:

The github/github-mcp-server (29,213 stars) case is the cleanest illustration of how surface tiering matters. All five hardcoded GitHub PATs sit in pkg/http/middleware/pat_scope_test.go — the test file for the PAT-scope middleware. The tokens are real-shape (ghp_… + gho_…) test fixtures used by the unit tests; they are not credentials anyone ever uses against a real GitHub account. The engine still flags them HIGH because the entropy + prefix match is positive, but the test-tier surface classification deducts only -5 per finding, so the credentials axis drops to 75 instead of 0. The repo grades C overall on that axis (and C overall on the rubric, capped by the security axis). Compare with awslabs/mcp's production-source AWS key in src/dynamodb-mcp-server/awslabs/dynamodb_mcp_server/model_validation_utils.py:70 — same shape of finding, but the production tier deducts -30 in one shot, and the credentials axis drops to 0.

Bad vs. good code shape

// docs/typescript/client/authentication.mdx
const client = new MCPClient({
  apiKey: "sk-ant-api03-AbCd1234EfGh...",
  authentication: { type: "bearer" },
});

// docs/typescript/client/authentication.mdx
const client = new MCPClient({
  apiKey: process.env.ANTHROPIC_API_KEY,
  authentication: { type: "bearer" },
});
// Required: set ANTHROPIC_API_KEY in your env.

The fix is the standard one — read from process.env / os.environ and document the env-var name once. The surprise in the corpus data is how often the bad shape lives in documentation rather than in runtime code. Authors carefully read env vars in src/server.ts and then paste a literal key string into the .mdx example showing how to call their library. Six of the seven repos that emit OpenAI/Anthropic-style HIGH findings have at least one finding in a docs path (docs/, .mdx, or a README.md).

What the engine looks for

This is the install-blocker. console.log(process.env) in a tool handler streams the entire process environment into stdout, into the JSON-RPC response, into the LLM's context window, and into every transcript downstream. print(os.environ) in a Python tool handler does the same. The matcher fires on the AST shape — any call expression whose callee is in console.* / print and whose argument expression contains an env-bag read.

Eight console.* findings across 6 repos:

Five print findings, all in one repo (pydantic/pydantic-ai at C):

• scripts/verify_bedrock_access.py:18
• scripts/verify_bedrock_access.py:19
• scripts/verify_vertex_gcs.py:58
• scripts/verify_vertex_gcs.py:59
• scripts/verify_vertex_gcs_all_types.py:71

All five sit in the scripts/ tier so they deduct at low weight (-5 each). The scripts are operator-run verification utilities that print AWS / GCP credentials so an engineer can confirm the right env was loaded; they never run inside the MCP tool surface and so do not bleed into the LLM context. The pattern still gets flagged because the bad shape lives in the repo and could move into the tool surface in any refactor. Pydantic AI grades C on the credentials axis as a direct consequence (and C overall, capped by the maintenance axis at 503 open issues — the repo with the largest open-issue backlog of any C in the corpus).

The three production-source HIGH cases are the install-blockers. Klavis-AI/klavis has two — one inside the Shopify integration's tool handler at mcp_servers/shopify/index.ts:1171 and one inside the WooCommerce integration at mcp_servers/woocommerce_toolathlon/src/server.ts:1236. Both are in MCP-tool-handler code paths. Anyone running the Klavis-AI Shopify tool through Claude or Cursor sees the entire process env land in their conversation log on the first invocation. PipedreamHQ/mcp's app/(chat)/api/chat/route.ts:47 is in a Next.js app-router chat-handler — the Pipedream MCP demo app's server response handler, which gets called on every chat turn. honeycombio/honeycomb-mcp's two findings sit in eval/scripts/run-eval.ts — eval scripts that the engine classifies production-tier because they live outside any of the test/examples/scripts top-level directories.

Bad vs. good code shape

// mcp_servers/shopify/index.ts
server.tool("get_orders", schema, async (args) => {
  console.log("env:", process.env);  // ← all secrets leak
  const res = await fetch(`${SHOPIFY_API}/orders`);
  return { content: [{ type: "text", text: await res.text() }] };
});

// mcp_servers/shopify/index.ts
server.tool("get_orders", schema, async (args) => {
  console.log("[shopify] get_orders", { args });  // no env
  const res = await fetch(`${SHOPIFY_API}/orders`);
  return { content: [{ type: "text", text: await res.text() }] };
});

The fix is a one-line change. Never log process.env as a whole — log the specific keys you need by name, and only the ones that are not credentials (NODE_ENV, LOG_LEVEL, etc.). If you are debugging a missing credential, log the env-var name and a boolean for whether it was set, never the value: console.log({ key: "ANTHROPIC_API_KEY", set: !!process.env.ANTHROPIC_API_KEY }). The bytes-on-the-wire saving is enormous and the value of the log line is identical.

What the engine looks for

The narrowest leak shape, and the easiest to miss in code review. The pattern is a template-literal error string that includes an env-var value in the interpolation — typically the result of a well-meaning "let me show what I tried" diagnostic. The thrown error propagates up the call stack, into the MCP tool handler's catch block (if any), into the JSON-RPC error response, into the LLM context. Even with structured logging and a redaction policy on stdout, an unhandled throw still ships the env value in plain text.

One repo in the corpus emits this finding:

JetBrains/mcp-jetbrains is the official JetBrains-published MCP server for the JetBrains IDE family — Claude calls it to query and act on an open IntelliJ / WebStorm / PyCharm session. The error path at src/index.ts:103 is in the IDE-discovery flow that runs at server startup. When the server cannot find a connectable IDE on the configured port, it builds the error string by interpolating the env-var value the user set. If the user set the env to anything sensitive (an API token, a path containing credentials, etc.), the value lands in the error message that the LLM reads back as part of the tool's startup-failure log.

The vendor-official label matters here. JetBrains/mcp-jetbrains is the kind of repo a team installs without thinking — "official JetBrains plugin" is a strong install signal — and the error path is reachable on every failed connection, which means it fires more often than a happy-path code path would. The audit page reports it as the only HIGH finding on the credentials axis, deducting -30 to land at 70 on credentials, but the overall grade lands at F because the security axis carries other findings.

Bad vs. good code shape

// src/index.ts
const port = process.env.IDE_PORT;
if (!await connectable(port)) {
  throw new Error(
    `Cannot connect to IDE on port ${port}` +
    ` (token=${process.env.IDE_TOKEN})`
  );
}

// src/index.ts
const port = process.env.IDE_PORT;
if (!await connectable(port)) {
  throw new Error(
    "Cannot connect to IDE. " +
    "Set IDE_PORT and IDE_TOKEN; verify reachable."
  );
}

The reviewer-facing test: every throw / raise with a template literal that pulls from process.env or os.environ is suspect. Either pull the env value into a named local variable that you can audit at one site, or rewrite the message to name the env var without including its value. The most generous interpretation of the bad shape is "the developer wanted to make debugging easy" — the right answer is to log the diagnostic to a per-process logfile (with redaction) and surface a short, value-free message to the caller.

What the engine looks for

The widest pattern by repo count. The matcher fires on any committed file matching .env, .env.example, .env.test, .env.local, .env.dist, or any other prefix-matched variant. The engine emits WARN — not HIGH — because the only verifiable difference between "template" and "live secret" is reading every line of every file. Most .env.example files genuinely contain placeholders (YOUR_API_KEY_HERE); most .env files in a public repo are templates that were committed by mistake but happened to contain placeholder values. The risk is the cases where they do not — and those cases have produced enough real credential leaks across the GitHub ecosystem that the WARN is justified.

Selected production-source .env findings (the install-gate WARNs):

The remaining 39 findings are mostly conventional .env.example files in examples/, tests/, or top-level scripts directories. The engine deducts -0 for those (they sit in low-weight tiers), so the credentials-axis impact is marginal. The reason every one still gets a WARN is that the surface-tier classification is heuristic and the engine cannot tell from the filename alone whether the file contains real credentials or placeholders — and in past large-corpus scans on the open ecosystem, a non-zero fraction of "template" .env files have been found to contain real keys.

The mem0ai/mem0-mcp case is the most-named one in the corpus because the file is bare .env with no suffix at all. Mem0 is also one of the nine archived repos in our maintenance-signal post, which means the file will sit in the tree at that exact shape forever — no future commit will rename it to .env.example or move it under examples/. Buyers running the install-gate against a snapshot of the corpus today get a WARN that will never resolve.

The .env vs. .env.example distinction

The conventional discipline is commit .env.example with placeholders, never commit .env, and add .env to .gitignore. The corpus shows the discipline is followed unevenly. Twenty-six of 28 repos with .env-shaped findings have at least one .env.example path in the list; six have a bare .env or unsuffixed variant. Standardizing on a single shape (.env.example) and gitignoring everything else closes the manual-review surface entirely.

Bad vs. good repo shape

# repo root
.env                # ← committed; may contain anything
.env.test
src/server.ts

# repo root
.env.example        # placeholders only, committed
src/server.ts

# .gitignore
.env
.env.local
.env.test