mcp-pinot: un servidor MCP sin autenticación como diputado confuso
Una divulgación de junio de 2026 muestra un servidor MCP para Apache Pinot expuesto en 0.0.0.0 sin OAuth, permitiendo a cualquier llamante de la red ejecutar sus herramientas de base de datos privilegiadas.
¿Qué es esto?
El 18 de junio de 2026 se publicó una vulnerabilidad crítica en mcp-pinot, un servidor Model Context Protocol (MCP) de código abierto que permite a un agente LLM consultar y administrar un clúster de analítica en tiempo real Apache Pinot. En la versión 3.0.1 y anteriores, el servidor iniciaba un punto de acceso MCP HTTP enlazado a 0.0.0.0:8080 con la autenticación deshabilitada por defecto. Cualquier llamante capaz de alcanzar ese puerto —una máquina de la misma red, un contenedor vecino o cualquier cosa tras un cortafuegos mal configurado— podía invocar todas las herramientas expuestas por el servidor, sin iniciar sesión.
Los mantenedores (StarTree) corrigieron el problema en la versión 3.1.0, publicada el 25 de mayo de 2026, antes de la divulgación pública. El fallo está calificado como 10.0 (crítico) y es un caso de manual de diputado confuso (confused deputy): son las credenciales del servidor, y no las del atacante, las que causan el daño.
Cómo funciona
Se trata de un defecto de configuración y diseño, no de una corrupción de memoria, por lo que el mecanismo se puede describir sin un payload explotable.
El servidor mcp-pinot se conecta a su clúster Pinot mediante una cuenta de servicio cargada desde variables de entorno (un token, o un usuario y contraseña). Esas credenciales suelen ser privilegiadas, porque el servidor debe leer tablas, listar esquemas y a veces escribir configuración. Cuando un cliente MCP llama a una herramienta como read_query, el servidor reenvía esa llamada a Pinot usando sus propias credenciales.
En la configuración vulnerable por defecto, nada filtraba ese reenvío. El escucha HTTP respondía en todas las interfaces (0.0.0.0) en lugar del bucle local (127.0.0.1), y OAuth estaba deshabilitado. Una petición sin autenticar podía así llegar directamente a la capa de herramientas y usar la identidad del servidor hasta la base de datos. Las herramientas expuestas cubrían toda la superficie del clúster: read_query ejecuta consultas SELECT arbitrarias, list_tables y las diversas herramientas de metadatos enumeran esquemas y configuración, y create_schema, update_schema y update_table_config modifican el clúster allí donde la cuenta de servicio tiene permisos de escritura. Una herramienta, reload_table_filters, incluso devolvía al llamante las listas de filtros anterior y nueva del servidor, filtrando la allowlist destinada a restringir las consultas.
El alcance es lo que lo convierte en un diputado confuso y no en un simple punto de acceso expuesto: el componente MCP vulnerable está en una frontera de seguridad, pero sus credenciales actúan sobre otra (el clúster Pinot). El atacante nunca necesita conocer la contraseña de la base de datos; el diputado la gasta por él.
Por qué importa
Los servidores MCP se están convirtiendo en el pegamento estándar entre los agentes y los sistemas reales, y cada uno es un pequeño proxy que guarda credenciales de algo valioso. Por eso la postura de red por defecto de estos servidores es una decisión de seguridad, no un ajuste de comodidad. Enlazar a 0.0.0.0 «para que funcione desde otra máquina» convierte discretamente una herramienta local en un servicio de red, y si ese servicio antepone una cuenta de base de datos privilegiada sin autenticación, el radio de impacto es todo el backend.
No es un desliz aislado. La misma forma —un servidor HTTP cercano a la IA escuchando en todas las interfaces, con autenticación deshabilitada por defecto— produjo otro fallo crítico de ejecución remota de código en el inspector MCP de MCPJam a principios de 2026, y recuerda al patrón de la «tríada letal» donde un sistema combina acceso privilegiado, entrada no confiable y una vía de exfiltración. Las guías nacionales se han puesto al día: recientes consideraciones de diseño MCP de la NSA y agencias aliadas insisten en la autenticación, la confianza en el servidor y los controles de transporte, precisamente porque estos proxys siguen entregándose abiertos. La conclusión, para quien despliega un servidor MCP, es que su configuración por defecto forma parte de su superficie de ataque, incluso antes de que un agente haga algo ingenioso.
Defensas
Enlazar al bucle local por defecto. Un servidor MCP de desarrollo o de un solo host debería escuchar en 127.0.0.1, nunca en 0.0.0.0, salvo una decisión explícita y revisada de exponer el servicio. Para mcp-pinot en concreto, establezca MCP_HOST=127.0.0.1 si aún no puede actualizar.
Nunca exponer un servidor de herramientas sin autenticación en la red. Si el acceso remoto es realmente necesario, exija autenticación primero. mcp-pinot 3.1.0 rechaza HTTP/HTTPS no-loopback mientras OAuth no esté habilitado; habilítelo (OAUTH_ENABLED=true) y coloque el punto de acceso tras una VPN o un túnel SSH en lugar de la internet abierta.
Conceder al servidor el mínimo privilegio necesario. Trate la cuenta de servicio tras un servidor MCP como si estuviera expuesta a internet. Reduzca sus permisos a solo lectura cuando sea posible, restríjala a las tablas que el agente necesita y separe las tareas de lectura y escritura para que una herramienta de lectura no gane silenciosamente poder de escritura.
Restringir las herramientas, no solo la red. La validación de consultas del lado del servidor importa incluso con la autenticación activada. La corrección 3.1.0 añadió para read_query una validación, apoyada en un parser, de una sola instrucción y de solo lectura, de modo que una herramienta de «lectura» no pueda ser forzada a un comportamiento multiinstrucción o de escritura. Aplique el mismo rigor a cualquier herramienta que acepte entrada libre.
Hacer que la exposición sea opt-in en su tooling de despliegue. La versión corregida también hizo su exposición Helm opt-in y condicionada a OAuth. Configure por defecto sus manifiestos de Kubernetes y contenedores en modo cerrado, para que un chart copiado y pegado no publique un proxy con credenciales por accidente.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Aviso | GHSA-73cv-556c-w3g6 / CVE-2026-49257 | 18 jun 2026 | Falta de autenticación para una función crítica (CWE-306); CVSS 3.1 = 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) |
| Afectado | mcp-pinot < 3.1.0 | — | Servidor MCP HTTP enlazado por defecto a 0.0.0.0:8080, OAuth deshabilitado por defecto |
| Corregido | v3.1.0 | 25 may 2026 | Enlace por defecto 127.0.0.1; no-loopback rechazado sin OAuth; exposición Helm opt-in y condicionada a OAuth; validación de solo lectura de una instrucción para read_query |
| Causa raíz | Diputado confuso | — | Credenciales de la cuenta de servicio Pinot del lado del servidor usadas para atender a llamantes sin autenticar |
La lección práctica es concreta y trasladable: un servidor MCP es un proxy con credenciales, y su dirección de escucha y su postura de autenticación por defecto son controles de seguridad. Compruebe en cada servidor MCP que ejecute dónde se enlaza y si autentica antes de reenviar una llamada de herramienta, porque las credenciales que presta son las suyas.