MCP Injection Attacks: SQL, Command, Path and SSRF

Why model-supplied input is worse than user input

Application security has thirty years of practice at treating user input as hostile. The instinct is right and most of the techniques transfer. Three differences make the agent case harder rather than merely equivalent.

The input source can be argued into anything. A human attacker has to reach your input field. An attacker who can place text where an agent will read it — a support ticket, a shared document, a web page — can specify a payload and have the model construct it. The model is not compromised; it is doing what it was asked, by content it had no basis to distrust.

Tool schemas are permissive by convention. Tools are written to be useful to a model, and free-string parameters are more useful than enums. A schema that would never pass review on a public API is normal in an MCP server, because the author was thinking about capability rather than about a hostile caller.

The call looks legitimate. There is no unusual endpoint, no malformed request, no authentication anomaly. An entitled agent calls a permitted tool with a syntactically valid parameter. Every layer above the interpreter sees nothing wrong.

So the control has to sit at the parameter, and it has to be structural rather than behavioural.

Five injection classes

Same weaknesses as always. What differs is which schema patterns make an MCP tool reachable.

A useful heuristic when reviewing a third-party server: look at the parameter names before the tool names. A tool called get_report with a filter parameter typed as a free string is more interesting than a tool called execute_query with a bounded enum. Names describe intent; schemas describe capability.

Fix the schema before writing a validator

The instinct is to validate input. Better first move: narrow the type so the dangerous value cannot be expressed. A validator is code that can have a bug; a schema constraint is a structural property.

In order of strength.

Defences at the interpreter

Schema constraint reduces what can arrive. Interpreter-side defences ensure that what does arrive cannot change structure.

• 01Parameterise, always. Bound parameters for SQL, argument arrays rather than shell strings for commands, path-joining APIs that reject traversal rather than string concatenation. Parameterisation separates data from structure at the mechanism level; escaping tries to do it with string manipulation and has a losing historical record.
• 02Never invoke a shell. Where a subprocess is genuinely required, execute the binary directly with an argument array and no shell interpretation. Most command injection depends on a shell being in the path.
• 03Canonicalise then check, for paths. Resolve the path fully, then verify it is inside the permitted root. Checking before resolution is defeated by traversal sequences and symlinks.
• 04Run the interpreter with minimal privilege. A database user that can only read the three tables the tool needs bounds a successful injection to those three tables. This is the control that limits damage when the others fail.
• 05Cap results and time. A row limit and a timeout turn a successful bulk-extraction injection into a partially successful one, and make it visible in latency metrics.

SSRF: the class nobody scores

SSRF deserves its own section because it is the one most often missed in MCP tool review, and because its consequence is unusually large: the tool becomes a proxy that reaches your internal network from a position of trust.

Any parameter the server fetches is an SSRF surface — a URL to retrieve, a webhook to call back, an image to render, a document to import, a link to preview. A model can be induced to supply an internal address by content it reads, and the server’s own network position does the rest.

Four defences, and the ordering matters.

The specific addresses to deny if you must use a denylist as a secondary layer: loopback, link-local (including cloud metadata endpoints), all private ranges, and anything resolving to your own service mesh. But treat that as defence in depth behind an allow-list, never as the primary control — encoded, shortened and redirect-chained addresses have defeated denylists consistently.

Network-layer egress restriction is the control that holds when application logic fails, and for third-party servers it is the one to insist on. A container that can only reach its one backing system cannot be a proxy into anything.

Testing for reachability

The question is not whether a tool validates input. It is whether a parameter reaches an interpreter at all — which is often unknown, particularly for third-party servers.

Run the last test at least once with the team watching. It connects two things that are usually discussed separately — that a model can be persuaded, and that a parameter reaches an interpreter — and seeing the enforcement point refuse the resulting call is what makes the case for parameter policy concrete.

Glossary

Tool parameter injection

Supplying a crafted value through an MCP tool parameter so that it is interpreted as code, a query, a path or a URL by a downstream component.

Interpreter reachability

Whether a tool parameter’s value ultimately reaches a component that interprets structure — the property that turns a string into a vulnerability.

Schema constraint

Narrowing a parameter’s declared type, format, enumeration or length so that dangerous values cannot be expressed at all.

SSRF

Server-side request forgery: inducing a server to make an HTTP request to a location of the attacker’s choosing, typically reaching internal services.

Parameterisation

Passing values to an interpreter through a binding mechanism that keeps data separate from structure, rather than by string concatenation.

Sources and further reading

The weakness classes are defined by CWE and OWASP, which are authoritative. What is specific to this article is how model-supplied parameters change the threat model and which schema patterns make MCP tools reachable.

1. 01 · MITRECWE — Common Weakness Enumeration ↗Named weakness classes — injection, path traversal, SSRF — that reappear when a model supplies the parameters.
2. 02 · MITRECWE-89 — SQL Injection ↗The canonical description of the weakness a model-supplied parameter can reach.
3. 03 · MITRECWE-78 — OS Command Injection ↗What happens when an unbounded string parameter reaches a shell.
4. 04 · MITRECWE-918 — Server-Side Request Forgery ↗Why a URL parameter on a tool is an internal-network reachability question.
5. 05 · OWASPOWASP Application Security Verification Standard ↗Input-validation, authorization and logging requirements restated here in MCP terms.
6. 06 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
7. 07 · JSON SchemaJSON Schema Specification ↗How tool parameter contracts are expressed, and what a validator can enforce.
8. 08 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.

Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.