Identifier-position SQL injection in Amazon's MCP gateway registry

What is this?

On July 6, 2026, Amazon published a security advisory for mcp-gateway-registry, an open-source gateway and registry for Model Context Protocol (MCP) servers. The project centralizes discovery, authentication and authorization, and proxies MCP tools for AI agents and coding assistants — in effect, a control plane that sits between agents and the tools they call. The advisory describes an authenticated SQL injection in the gateway’s metrics-service retention-policy component. It was assigned CWE-89 and scored CVSS 8.1 (v3.1) / 8.6 (v4.0), both HIGH, and it was fixed in version 1.0.13. This is a disclosed, patched vulnerability; the write-up below is defensive and reproduces no working exploit.

How it works

The retention-policy management code lets a caller specify which metrics table a policy applies to. That caller-supplied table_name value is interpolated into a SQL statement in identifier position — where a table or column name goes — without proper neutralization. Affected versions are 1.0.3 through 1.0.12.

The subtle part is why the usual defense does not apply. Parameterized queries — the standard cure for SQL injection — bind untrusted input in value position only:

# Safe: the value is bound, never parsed as SQL
cursor.execute("SELECT * FROM metrics WHERE day = %s", (user_day,))

# Unsafe: an identifier cannot be bound, so it is string-formatted in
cursor.execute(f"DELETE FROM {table_name} WHERE ts < now() - interval '30 days'")

Most database drivers offer no placeholder for a table or column name, so developers reach for string formatting — and retention logic, which naturally iterates over a set of table names, is a classic place for that pattern to appear. Because the injected text is parsed as part of the query structure rather than as data, an authenticated remote user can break out of the intended identifier and run arbitrary SQL against the metrics database. Per the advisory, that includes reading stored data — up to and including API key material — and deleting or altering stored rows.

Why it matters

An SQL injection in a generic web app leaks rows. The same flaw in an MCP gateway leaks the material that authorizes agents to reach downstream tools. This is the same lesson seen across the 2026 wave of AI-infrastructure flaws, including the pre-auth injection in the LiteLLM proxy: gateways are tier-1 credential surfaces because they aggregate secrets that used to sit behind separate boundaries.

Two details raise the practical risk. First, “authenticated” is a lower bar in an agent ecosystem than in a human one — a gateway of this kind fronts many agent identities, service accounts and tokens, any of which could be the authenticated caller. Second, the injection reaches a store that, by the advisory’s own description, may hold key material. A read primitive there can cascade into the systems those keys unlock, turning a single component flaw into a multi-tool compromise.

Defenses

The fix in 1.0.13 is the right model, and the general lessons transfer to any service that builds SQL from names:

• Allowlist identifiers. Validate table_name against a fixed, known set of metric tables and reject anything else. Never interpolate caller input into identifier position, even after escaping.
• Do not trust parameter binding to cover identifiers. Placeholders protect values, not table or column names. If a name must be dynamic, map it through a lookup, not string formatting.
• Least-privilege database accounts. The metrics service should connect with a role that can touch only metrics tables — not the tables holding credentials or configuration — so an injection cannot pivot to secrets.
• Separate secrets from telemetry. Do not co-locate API key material with metrics data, and encrypt secrets at rest so a read primitive on one store does not yield the other.
• Restrict and audit admin surfaces. Gate retention-policy management behind strong authorization, and log its use.
• Upgrade and rotate. Move to 1.0.13 or later. Any instance that ran an affected version and was reachable by untrusted authenticated identities should have its stored keys rotated and its metrics data integrity reviewed.

Status

Item	Detail	Status
Reference	CVE-2026-14471 (GHSA-79qc-vqfr-xx5q)	Public
Affected versions	1.0.3 – 1.0.12	Confirmed
Fixed version	1.0.13	Available
Advisory published	Jul 6, 2026	Public (AWS)
Severity	CVSS 8.1 v3.1 / 8.6 v4.0, CWE-89	HIGH
Workaround	None — upgrade required	—

The takeaway is narrow and reusable: parameterized queries are necessary but not sufficient. Anywhere an agent platform lets a caller name a table, a column, or a sort field, that name needs an allowlist — because an identifier can never be safely bound, only validated.