El 2 de septiembre de 2026, la CISA añadió por primera vez una vulnerabilidad del Model Context Protocol a su catálogo de Known Exploited Vulnerabilities. Cinco días después apareció un segundo fallo, más grave, en otro servidor MCP muy utilizado. Ninguno de los dos es un fallo exótico específico de MCP — uno es un fallback de autenticación que falló abierto, el otro es un bypass de privilegios de base de datos — y ese es precisamente el punto: MCP ya está lo bastante desplegado como para que clases de bugs corrientes, en infraestructura corriente, sean lo que lo tumba.

La primera entrada de MCP en la lista de explotación de la CISA

CVE-2026-59822 es un bypass de autenticación en LiteLLM, el proxy de código abierto que buena parte de las stacks de IA autoalojadas usa para enrutar llamadas a modelos y, para muchos equipos, a sus servidores MCP. La CISA lo añadió al catálogo Known Exploited Vulnerabilities el 2 de septiembre, con plazo de corrección el 16 de septiembre para sistemas federales de EE. UU. — un plazo ajustado que, bajo la nueva Binding Operational Directive 26-04 de la agencia, se reserva para fallos confirmados como explotados, accesibles desde internet y fáciles de automatizar. Hasta donde sabemos, es la primera implementación del Model Context Protocol que aparece en esa lista.

Cómo funcionaba el bypass

El endpoint MCP Streamable HTTP de LiteLLM comprueba la clave de quien llama y tiene una ruta de fallback para el passthrough de OAuth2 aguas arriba. Cuando la validación de la clave fallaba, el fallback no rechazaba la petición — la sustituía por un objeto UserAPIKeyAuth() vacío y dejaba pasar la llamada igualmente. Una petición con nada más que una cabecera Authorization fabricada podía llegar a cualquier herramienta MCP configurada, sin necesitar clave válida. La corrección, publicada en la versión 1.84.0, cierra ese fallback. LiteLLM publicó el aviso ya en junio; la entrada de la CISA, dos meses después, confirmó que el fallo se estaba usando de verdad contra despliegues reales, no solo que fuera teóricamente explotable.

Un segundo fallo, más grave, cinco días después

El 9 de septiembre, AWS Labs reveló el CVE-2026-87911 en su propio postgres-mcp-server: un fallo crítico, CVSS 9,6, en el que la validación SQL detrás del modo de solo lectura del servidor podía burlarse con una sentencia COPY ... TO PROGRAM construida a propósito, permitiendo ejecutar comandos del sistema operativo en la máquina de la base de datos. Solo afecta cuando el servidor MCP se conecta con un rol que tiene privilegios de superuser o pg_execute_server_program — un atajo que toman muchas configuraciones rápidas, por ser el camino de menor resistencia hasta que alguien lee el aviso primero. Corregido en la 1.1.7.

Por qué le está pasando esto justo a MCP

Ninguno de los dos fallos es un defecto de la especificación MCP — un fallback de autenticación que falla abierto y una escalada de privilegios vía COPY TO PROGRAM son clases de bugs tan antiguas como las tecnologías que hay debajo. Lo que ha cambiado es que corregirlos con un plazo acelerado ya merece la pena para la CISA y para AWS, porque los servidores MCP están exactamente donde está una base de datos o un gateway de API: accesibles, con credenciales, y ahora suficientemente comunes como para ser una categoría objetivo y no una curiosidad. El lote del 2 de septiembre de la CISA registró siete fallos explotados; tres, incluido este, se reportaron como dirigidos específicamente a infraestructura de IA.

Qué hacer, en la práctica

  • Actualiza LiteLLM a la 1.84.0+ y postgres-mcp-server a la 1.1.7+ si usas alguno de los dos — ambas correcciones ya están disponibles.
  • Sea cual sea el servidor MCP que toque una base de datos, conéctalo con un rol limitado a las tablas y operaciones que realmente necesita, nunca superuser. El modo de solo lectura es una red de seguridad, no un sustituto de los permisos a nivel de base de datos.
  • Prueba la ruta de fallo de tu autenticación, no solo la de éxito. Un validador que falla abierto es peor que uno que revienta, y desde fuera son indistinguibles hasta que alguien encuentra el hueco.
  • Si no puedes corregirlo de inmediato, pon el proxy MCP detrás de un gateway que pueda limitar o controlar las rutas /mcp/ por su cuenta.

Esto también refuerza lo que nuestra propia checklist de OAuth viene diciendo desde agosto: la especificación exige OAuth 2.1 en todos los servidores MCP, y muchos siguen recortando esa esquina. Estos dos CVE son lo que cuesta recortarla en la práctica — no una hipótesis, una entrada fechada en el catálogo de la CISA con un plazo de corrección asociado.