Vulnerabilidades de back-end en MCP: fallos clásicos reaparecen en los puentes IA-bases de datos

What is this?

El 12 de mayo de 2026, Tomer Peled, de Akamai, publicó One Is a Fluke, 3 Is a Pattern: MCP Back-End Vulnerabilities, una divulgación coordinada sobre tres fallos hallados en cerca de 300 servidores MCP (Model Context Protocol) oficiales. El estudio destaca CVE-2025-66335 (inyección SQL en Apache Doris MCP, asignada el 7 de enero de 2026, parcheada el 30 de diciembre de 2025), una vía de ejecución SQL no autenticada en el servidor MCP de Apache Pinot mantenido por StarTree (versiones ≤ 1.1.0) y una divulgación de información en el componente RAG de Alibaba RDS MCP que Alibaba ha decidido no corregir.

Los bugs en sí son de manual: validación de entrada ausente, autenticación inexistente sobre un transporte HTTP y un endpoint RAG sin autenticación que expone metadatos de esquema. Lo que vuelve interesante el informe es el patrón. MCP, el protocolo abierto que Anthropic introdujo en 2024 para permitir que los LLM hablen con sistemas externos, deja casi cada decisión de seguridad del back-end — autenticación, gestión de credenciales, alcance de privilegios, validación de consultas — en manos del implementador. Los tres servidores rotos por Akamai no son la excepción; son una muestra.

How it works

Un servidor MCP se sitúa entre un agente de IA y un sistema back-end (aquí, una base de datos). Cada servidor expone «tools» que el modelo puede invocar, y cada servidor decide por su cuenta cómo autenticar al llamante y cómo validar los parámetros antes de hablar con el back-end.

CVE-2025-66335 — inyección SQL en Apache Doris MCP. Doris MCP envuelve un Security Manager que autentica un JWT, asigna un nivel de habilitación y ejecuta un validador SQL. La firma interna:

async def exec_query_for_mcp(
        self,
        sql: str,
        db_name: str = None,
        catalog_name: str = None,
        max_rows: int = 100,
        timeout: int = 30
    ) -> Dict[str, Any]:
    # Cinco parámetros, pero solo `sql` se envía al validador.
    # `db_name` se concatena tal cual a la consulta final.

El validador analiza el argumento sql y se detiene ahí. El parámetro db_name — también concatenado a la consulta final — nunca se sanea. Cualquier cliente conectado al servidor MCP puede entonces pasar a db_name valores con punto y coma, comentarios o instrucciones completas y ejecutar SQL arbitrario contra la instancia de Doris. La práctica del validador de inspeccionar solo el principio de la sentencia analizada amplifica el problema. Apache corrigió en v0.6.1 (30 de diciembre de 2025); el CVE se asignó el 7 de enero de 2026.

Apache Pinot MCP — bypass de validación de autenticación. La integración de Pinot de StarTree (≤ 1.1.0) admite un transporte HTTP enlazado a 0.0.0.0:8080. Cuando HTTP está activo, el servidor no exige autenticación y el «validador» incluido se limita a comprobar que la consulta empieza por SELECT:

# Ilustrativo — parafraseado desde la publicación.
if path == server_config.endpoint and method == "POST":
    await transport.handle_post_message(scope, receive, send)
# Sin control de autenticación antes de invocar tools.
# Validador: query.upper().startswith("SELECT")

Cualquier atacante remoto que pueda alcanzar el endpoint puede emitir consultas SELECT arbitrarias — suficiente para la exfiltración completa de datos y, combinado con trucos de concatenación, una toma de control más amplia. StarTree añadió OAuth como opción de autenticación el 14 de octubre de 2025, lo que reduce la severidad para despliegues bien configurados pero no elimina la carencia subyacente de validación SQL.

Alibaba RDS MCP — endpoint RAG no autenticado. El servidor RDS MCP de Alibaba incluye un componente RAG FastMCP que escucha en 0.0.0.0:8006 y expone una única herramienta get_table_struct que realiza una búsqueda por similitud vectorial sobre un índice interno de esquemas de tablas. Sin autenticación, sin validación de consulta: cualquier cliente capaz de alcanzar el endpoint puede extraer los metadatos del esquema — nombres de tablas, estructuras de columnas y otros datos de fingerprinting operativo. Alibaba marcó el problema como «not applicable» para una corrección; Akamai escaló a CERT/CC el 25 de noviembre de 2025.

Why it matters

Tres observaciones hacen que esta divulgación sea útil más allá de los bugs individuales.

Primero, MCP hereda las vulnerabilidades web clásicas y las amplifica. Una inyección SQL en una herramienta de administración de bases de datos independiente está acotada por quién puede llegar a la herramienta. Una inyección SQL en un servidor MCP es accesible desde cualquier elemento que pueda hablar con el agente — incluido, en algunos despliegues, contenido inyectado vía prompt que llega por un canal completamente distinto. La superficie de exposición crece con cada nuevo conector.

Segundo, la flexibilidad del protocolo es la clase de vulnerabilidad. MCP deja deliberadamente las decisiones de seguridad del back-end a quienes lo implementan. La elección es razonable a nivel de protocolo, pero tiene consecuencias en la práctica: la revisión que Akamai hizo del conjunto oficial encontró gran variabilidad en autenticación, autorización y tratamiento de parámetros. El OWASP GenAI Security Project ha publicado una Practical Guide for Secure MCP Server Development — pero su adopción va por detrás del ritmo de despliegue.

Tercero, rehusar parchear es una decisión política con consecuencias aguas abajo. La calificación «not applicable» de Alibaba para RDS MCP significa que un índice vectorial con metadatos de esquema de clientes permanece accesible sin autenticación para cualquier operador que despliegue el servidor oficial sin modificaciones. Los usuarios finales que adoptan esa integración en producción heredan la decisión.

Defenses

El informe de Akamai y la guía OWASP convergen en un pequeño conjunto de controles. Ninguno basta por sí solo, pero juntos neutralizan la clase publicada.

1. Exigir autenticación en la capa de transporte. Cualquier servidor MCP enlazado a una interfaz de red más allá de localhost debe requerir autenticación antes de exponer sus herramientas. Trate el transporte HTTP desnudo (0.0.0.0:8080, 0.0.0.0:8006) como una mala configuración de severidad crítica, sin importar cuán «interna» parezca la red.
2. Validar cada parámetro en el servidor. Validadores que solo inspeccionan un argumento de cinco (Doris) o que se limitan a comprobar si una consulta empieza por SELECT (Pinot) son casillas, no controles. Use consultas parametrizadas o query builders que no puedan concatenar cadenas no confiables en el SQL final.
3. Aplicar mínimo privilegio a las credenciales del back-end. La cuenta de servicio MCP debe tener solo los permisos que las herramientas expuestas necesiten: lectura sobre las tablas concretas en alcance, sin DDL, sin acceso cross-schema. Una inyección SQL exitosa contra una cuenta de mínimo privilegio queda confinada al esquema; contra una cuenta de administrador es total.
4. Auditar el servidor MCP oficial que se despliega. Los servidores MCP publicados por un proveedor no son implícitamente seguros. Lea el código de autenticación, el bind del transporte, el manejo de parámetros, y fíjese en una versión conocida y parcheada. Para Doris en concreto: actualizar a v0.6.1 o posterior (parche para CVE-2025-66335). Para Pinot: activar OAuth y plantearse bloquear el transporte HTTP. Para Alibaba RDS MCP: no exponga el endpoint RAG fuera de redes autenticadas y de confianza.
5. Segmentar el servidor MCP a nivel de red. Incluso con autenticación, un servidor MCP que se sitúa frente a una base de datos debe quedar tras los mismos controles de red que la propia base. Si su base de datos no está expuesta a Internet directamente, tampoco lo debe estar el servidor MCP que la fronta.
6. Tratar los parámetros de herramientas MCP como entrada de usuario. El modelo no es su validador de entrada. Cualquier cadena que el modelo pase a una herramienta es, desde la perspectiva del back-end, controlada por el atacante — porque el modelo puede estar leyendo contexto controlado por el atacante. Valide en la frontera de la herramienta, cada vez.

Status

Elemento	Referencia	Fecha	Notas
Divulgación Pinot (StarTree)	Cronología Akamai	2025-09-30	Vendor contactado
Mitigación Pinot (OAuth añadido)	StarTree	2025-10-14	Reduce severidad, no cierra la clase SQLi
Divulgación Alibaba RDS MCP	Cronología Akamai	2025-11-17	Vendor contactado
Alibaba rehúsa parchear	Cronología Akamai	2025-11-25	Escalada a CERT/CC iniciada
Divulgación Doris MCP	Cronología Akamai	2025-11-27	Apache contactado
Parche Doris (v0.6.1)	Apache	2025-12-30	Valida db_name
CVE-2025-66335 asignado	NVD	2026-01-07	Inyección SQL (CWE-89)
Issue pública de Pinot MCP abierta	GitHub	2026-05-04	Paso público coordinado
Publicación de Akamai	Blog de Akamai	2026-05-12	Investigación completa, con herramienta de detección
Cobertura de The Register	The Register	2026-05-13	Reportaje independiente
Presentación de la investigación	x33fcon	2026-06 (programada)	Se espera publicación de tooling

La aportación duradera de esta divulgación no son los tres bugs de clase CVE — se parchearán, se ignorarán o se rodearán caso por caso. Es la demostración de que la capa de servidores MCP es una nueva superficie de ataque que hereda décadas de problemas de seguridad back-end sin resolver, vestidos con herramientas nuevas y desplegados más rápido de lo que se difunde la guía de seguridad. La próxima ola de integraciones MCP repetirá el patrón a menos que autenticación, validación y mínimo privilegio se diseñen desde el primer commit del conector.