Security Audit: Unconstrained string parameters across all official servers

[manja316]

Summary

I ran automated security audits on 7 official MCP servers using mcp-security-audit. All servers scored Grade A or B (85-100/100), which is great. But there's one consistent finding across every server except mcp-server-fetch:

No string parameters use maxLength, pattern, or enum constraints.

Findings

Server	Score	Unconstrained Strings
Fetch	100/100	0
SQLite	95/100	5 (SQL queries, table names)
Time	95/100	4 (timezone identifiers)
GitHub	94/100	Multiple
Memory	92/100	1 (search query)
Git	90/100	18 (paths, messages, branches)
Filesystem	85/100	Multiple (paths)

Why this matters

1. DoS vector — Unconstrained strings accept arbitrarily long input. A 10MB commit message or 50K-char file path must be processed by the server.
2. No boundary validation — If an LLM is compromised via prompt injection, the tool schema provides no defense against malformed input.
3. Network transports — With MCP supporting Streamable HTTP, servers may be network-exposed where these constraints become critical.

Suggested fix

One line per parameter:

{
  "name": "path",
  "type": "string",
  "maxLength": 4096
}

For known-format params:

{
  "name": "timezone",
  "type": "string",
  "pattern": "^[A-Za-z_/]+$",
  "maxLength": 50
}

Full reports

Individual JSON/text reports for each server: LuciferForge/mcp-audit-reports

The audit tool: pip install mcp-security-audit

Happy to discuss findings or help with fixes.

[razashariff]

MCPS (MCP Secure) solves this at the message layer — every JSON-RPC body is SHA-256 hashed and ECDSA P-256 signed before transmission. A compromised proxy can't inject malformed parameters because the signature covers the full message body. Nonce + timestamp binding prevents replay. Designed as a drop-in security layer for MCP servers. IETF Internet-Draft | github.com/razashariff/mcps

[joergmichno]

Good findings. The unconstrained string issue is real, and schema-level constraints (maxLength, pattern, enum) would help with the DoS vector.

But there's a deeper problem: even with schema constraints in place, the content of those strings can still carry prompt injection payloads. A maxLength: 500 parameter still has room for "Ignore previous instructions and..." — the constraint prevents oversized input but not malicious input.

We've been looking at this from the content analysis side with ClawGuard (open-source, regex-based MCP scanner). Some data points:

• A peer-reviewed study (Queen's University, 1,899 MCP servers) found 5.5% are susceptible to Tool Poisoning — where tool descriptions themselves contain hidden behavioral directives
• System prompt restrictions ("don't follow injected instructions") reduce attack success rate by only 0.65% — essentially useless as a defense
• The git server's 18 unconstrained strings are particularly concerning because commit_message and branch_name parameters are user-controlled in collaborative workflows

Schema constraints + content scanning are complementary layers. Neither alone is sufficient.

[piiiico]

We ran a similar exercise — scanned 12 public MCP servers (including all the official ones) using static analysis — and the unconstrained string parameter pattern was consistent across the board.

One thing worth adding to the DoS/boundary discussion: the correlation with command injection patterns matters. In our scan, we found 46 instances of dangerous command execution patterns across 12 repos. Many of these accept path or argument parameters as freeform strings, then pass them directly into exec() or spawn(). The absence of schema constraints isn't just a DoS vector — it's also the absence of the first line of defense in a prompt injection → command injection chain.

The joergmichno comment above is correct that schema constraints don't fully solve injection. But in our analysis, the defense-in-depth picture looks like:

1. Schema constraints (maxLength, pattern) → shrink the malformed-input surface
2. Tool description scope warnings → LLM less likely to accept out-of-scope values under prompt injection
3. Runtime input validation → catch what slips through the LLM layer
4. execFile over exec → parameterized execution prevents shell injection even with valid-looking input

None of these alone is sufficient. The MCP ecosystem is currently at zero on most of these. The servers that scored well in automated audits (like the official server-fetch) have implemented #3 at minimum.

For CI integration, we've been running npx @piiiico/agent-audit --auto --json --min-severity high in GitHub Actions — exits 1 on high findings, 2 on critical. Not a replacement for the schema validation fixes you're proposing, but a useful catch for when they slip through.

[pshkv]

The audit finding is accurate and the pattern is consistent — unconstrained string parameters are a systematic MCP security gap, not an isolated oversight. The mcp-security-audit tool is measuring the symptom; the structural cause is that parameter constraints are advisory schema hints that tools can ignore, not enforced authorization boundaries.

The 58-vulnerability finding in context: All 58 cases are variations of the same architecture problem — the authorization scope is checked at connection time (OAuth token), but parameter values come from LLM output at call time. The constraint enforcement that matters happens after the point where prompt injection can occur.

We've been building SINT Protocol specifically around this architecture gap. The key insight:

Schema constraints vs. capability constraints:

Schema constraints (what MCP has today):
  parameters: { path: { type: "string" } }  // advisory, no enforcement
  
Capability constraints (what SINT adds):
  token.resource = "mcp://filesystem/readFile"
  token.constraints.allowedPaths = ["/tmp/*", "/workspace/*"]
  // Enforced at gateway intercept, before the tool runs, against a scope
  // committed before any LLM input was processed

What enforcement-grade constraints require:

1. Pre-session scope commitment: The capability token is issued before the LLM processes any potentially adversarial content
2. Per-call gateway validation: Every tool call is intercepted and validated against the committed scope — not checked at schema parse time
3. Deny with rationale: The denial includes policyViolated and suggestedAlternative fields so the LLM can replan rather than loop

For the filesystem server specifically: an allowlist of paths in the capability token makes traversal structurally impossible. For the GitHub server: an allowlist of owner/repo pairs in the token prevents cross-repo writes.

Repo: https://github.com/pshkv/sint-protocol — packages/bridge-mcp for the MCP intercept layer. The packages/conformance-tests has regression tests specifically for prompt injection scenarios.

[hidearmoon]

This unconstrained string parameter issue is closely related to tool-poisoning attacks — if parameters aren't validated against expected schemas, injected payloads can flow through to tool execution.

AgentShield addresses this at runtime with two approaches:

1. MCP Tool Supply Chain Verifier — Registers tool schemas (descriptions + parameter schemas) with Ed25519 signatures at setup time. At runtime, before each tools/call, the current schema is compared against the signed manifest. If an attacker modifies a tool's description or parameter schema, the mismatch is detected and the call is blocked.

2. MCP Guard — A decorator (@shield.guard) or stdio proxy that intercepts every tool call and evaluates it against trust policies and intent consistency before forwarding to the real server.

Both are open-source: MCP integration | Tool Registry Verifier