Inyección SQL en posición de identificador en el gateway MCP de Amazon

¿Qué es esto?

El 6 de julio de 2026, Amazon publicó un aviso de seguridad para mcp-gateway-registry, un gateway y registro de código abierto para servidores del Model Context Protocol (MCP). El proyecto centraliza el descubrimiento, la autenticación y la autorización, y actúa como proxy de herramientas MCP para agentes de IA y asistentes de código — en la práctica, un plano de control situado entre los agentes y las herramientas que invocan. El aviso describe una inyección SQL autenticada en el componente de gestión de políticas de retención del servicio de métricas. La falla está clasificada como CWE-89, con puntuación CVSS 8.1 (v3.1) / 8.6 (v4.0), ambas ALTAS, y corregida en la versión 1.0.13. Se trata de una vulnerabilidad divulgada y parcheada; el análisis siguiente es defensivo y no reproduce ningún exploit funcional.

Cómo funciona

El código de gestión de políticas de retención permite que quien llama especifique a qué tabla de métricas se aplica una política. Ese valor table_name, suministrado por el llamante, se interpola en una sentencia SQL en posición de identificador — donde va un nombre de tabla o columna — sin la neutralización adecuada. Las versiones afectadas van de la 1.0.3 a la 1.0.12.

El punto sutil es por qué no aplica la defensa habitual. Las consultas parametrizadas — el remedio estándar contra la inyección SQL — solo enlazan la entrada no confiable en posición de valor:

# Seguro: el valor se enlaza, nunca se interpreta como SQL
cursor.execute("SELECT * FROM metrics WHERE day = %s", (user_day,))

# Inseguro: un identificador no puede enlazarse, así que se concatena
cursor.execute(f"DELETE FROM {table_name} WHERE ts < now() - interval '30 days'")

La mayoría de los controladores de bases de datos no ofrecen ningún marcador de posición para un nombre de tabla o columna, por lo que los desarrolladores recurren al formateo de cadenas — y la lógica de retención, que por naturaleza itera sobre un conjunto de nombres de tablas, es un lugar clásico donde aparece ese patrón. Como el texto inyectado se interpreta como parte de la estructura de la consulta y no como un dato, un usuario remoto autenticado puede salirse del identificador previsto y ejecutar SQL arbitrario contra la base de datos de métricas. Según el aviso, esto incluye leer los datos almacenados — hasta el material de claves de API — así como eliminar o alterar los registros.

Por qué importa

Una inyección SQL en una aplicación web común filtra filas. La misma falla en un gateway MCP filtra el material que autoriza a los agentes a alcanzar las herramientas posteriores. Es la misma lección observada en toda la oleada de fallas de infraestructura de IA de 2026, incluida la inyección previa a la autenticación del proxy LiteLLM: los gateways son superficies de credenciales de primer nivel, porque agregan secretos que antes residían tras fronteras separadas.

Dos detalles elevan el riesgo práctico. Primero, «autenticado» es una barrera más baja en un ecosistema de agentes que en un contexto humano: un gateway de este tipo atiende muchas identidades de agentes, cuentas de servicio y tokens, cualquiera de los cuales podría ser el llamante autenticado. Segundo, la inyección alcanza un almacén que, según el propio aviso, puede contener material de claves. Una primitiva de lectura allí puede propagarse a los sistemas que esas claves desbloquean, convirtiendo la falla de un solo componente en un compromiso de múltiples herramientas.

Defensas

La corrección de la 1.0.13 es el modelo correcto, y las lecciones generales valen para cualquier servicio que construya SQL a partir de nombres:

• Poner los identificadores en lista blanca. Valide table_name contra un conjunto fijo y conocido de tablas de métricas, y rechace todo lo demás. Nunca interpole la entrada del llamante en posición de identificador, ni siquiera tras escaparla.
• No confiar en que el enlace de parámetros cubra los identificadores. Los marcadores protegen los valores, no los nombres de tabla o columna. Si un nombre debe ser dinámico, páselo por una tabla de correspondencia, no por formateo de cadenas.
• Cuentas de base de datos con mínimo privilegio. El servicio de métricas debería conectarse con un rol que solo toque las tablas de métricas — no las que contienen credenciales o configuración — para que una inyección no pueda pivotar hacia los secretos.
• Separar los secretos de la telemetría. No coloque el material de claves de API junto a los datos de métricas, y cifre los secretos en reposo para que una lectura de un almacén no entregue el otro.
• Restringir y auditar las superficies de administración. Proteja la gestión de políticas de retención con una autorización fuerte, y registre su uso.
• Actualizar y rotar. Pase a la 1.0.13 o posterior. Toda instancia que haya ejecutado una versión afectada y fuera accesible por identidades autenticadas no confiables debería rotar sus claves almacenadas y revisar la integridad de sus datos de métricas.

Estado

Elemento	Detalle	Estado
Referencia	CVE-2026-14471 (GHSA-79qc-vqfr-xx5q)	Público
Versiones afectadas	1.0.3 – 1.0.12	Confirmado
Versión corregida	1.0.13	Disponible
Aviso publicado	6 jul. 2026	Público (AWS)
Severidad	CVSS 8.1 v3.1 / 8.6 v4.0, CWE-89	ALTA
Solución alternativa	Ninguna — se requiere actualizar	—

La conclusión es estrecha y reutilizable: las consultas parametrizadas son necesarias pero no suficientes. Dondequiera que una plataforma de agentes permita a un llamante nombrar una tabla, una columna o un campo de ordenación, ese nombre exige una lista blanca — porque un identificador nunca puede enlazarse de forma segura, solo validarse.