La primera CVE de MCP en la lista KEV cumplió su plazo federal: LiteLLM y la bóveda de claves predeterminadas

CVE-2026-59822 es una elusión de autenticación en el proxy LiteLLM de BerriAI — la pasarela de código abierto que enruta el tráfico entre aplicaciones y más de 100 proveedores de modelos — y alcanzó su plazo federal de remediación el 16 de septiembre de 2026. CISA añadió la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas el 2 de septiembre con fecha de vencimiento hoy bajo la BOD 26-04, convirtiéndola en la primera implementación de Model Context Protocol jamás catalogada como explotada activamente por una autoridad nacional de gestión de vulnerabilidades (NVD; The Hacker News). La explotación no es teórica: la infraestructura honeypot de Wiz observó CVE-2026-59822 siendo usada en la naturaleza el 7 de julio — 56 días antes de la inclusión en la lista KEV (Wiz). Y la CVE ni siquiera es la forma más común de entrar en estas pasarelas. El escaneo de Wiz de febrero de 2026 sobre 3,074 instancias de LiteLLM expuestas a internet encontró 294 — 9.6% — aceptando la clave maestra de ejemplo sk-1234 impresa en la propia documentación de LiteLLM, y 191 sin ninguna autenticación configurada (Wiz; The Hacker News).

Este artículo cubre cuatro cosas que un Head of Engineering o líder de plataforma necesita antes de que la próxima auditoría encuentre una instancia de LiteLLM en su red: cómo funciona la elusión en una sola petición, por qué la clave maestra convierte la pasarela en una bóveda de credenciales en la nube, qué exige realmente el plazo KEV, y los seis puntos de verificación que cierran la exposición — más el patrón de código que hay que prohibir en cada gestor de autenticación MCP que poseas.

Puntos clave

• CVE-2026-59822 es la primera CVE específica de MCP en la lista KEV de CISA — añadida el 2 de septiembre de 2026 con un plazo federal de remediación del 16 de septiembre de 2026, con CVSS 8.8, y afecta a todas las versiones de LiteLLM anteriores a la 1.84.0.
• El honeypot de Wiz observó explotación el 7 de julio de 2026 — 56 días antes de la inclusión en la lista KEV — con un token Bearer de un solo carácter estableciendo una sesión MCP completamente autenticada.
• 294 de 3,074 pasarelas LiteLLM expuestas a internet (9.6%) aceptan la clave maestra de ejemplo documentada sk-1234 o ninguna autenticación — 191 de ellas no requieren credencial alguna, según el escaneo Shodan de Wiz de febrero de 2026.
• La clave maestra es una bóveda de credenciales en la nube: un administrador válido (o un atacante con la clave) puede usar el enrutamiento pass-through para leer los metadatos de instancias AWS y recuperar credenciales IAM, y el IMDSv2 no lo detiene porque el proxy reenvía las cabeceras con prefijo x-pass-.
• La elusión es un patrón de código, no solo un error: capturar una autenticación fallida y sustituirla por un objeto de autenticación vacío. La investigación "Puppet" publicada en ACM muestra que esta clase de confuso deputy alcanza un 90.89% de éxito en secuestro de selección de herramientas mientras permanece invisible para MCP-Scan y McpSafetyScanner.

El reloj de 24 horas, y cómo funciona la elusión en una petición

La cronología importa porque muestra que la explotación corrió por delante de la respuesta federal en cada etapa. Wiz reportó la vulnerabilidad a los mantenedores de LiteLLM el 18 de febrero de 2026; la corrección llegó en LiteLLM 1.84.0 el 25 de abril; el honeypot de Wiz registró explotación real el 7 de julio; la vulnerabilidad se publicó el 8 de julio; CISA la añadió al catálogo KEV el 2 de septiembre — y fijó el plazo de remediación 14 días después (Wiz; NVD).

El mecanismo es un fallback fail-open en el endpoint MCP de LiteLLM. El endpoint admite dos patrones de autenticación: claves nativas de LiteLLM y tokens OAuth2 pasados a un servidor MCP ascendente. Cuando un token Bearer falla la validación de clave de LiteLLM con un 401 o 403, el handler debería reenviar el token aguas arriba. En su lugar, captura el error y devuelve un objeto UserAPIKeyAuth() vacío — una sesión autenticada sin identidad detrás de ella (Wiz; base de datos de avisos de GitLab). La demostración de Wiz usó Authorization: Bearer *** — un solo carácter — y recibió HTTP 200 con un mcp-session-id` válido.

Lo que esa sesión puede alcanzar depende completamente de la configuración del despliegue. Una pasarela con una herramienta de consulta a base de datos conectada entrega al atacante acceso de consulta; la integración con GitHub entrega lecturas de repositorios y creación de incidencias; los conectores de sistema de archivos entregan acceso de lectura-escritura. La bandera allow_all_keys documentada por LiteLLM — recomendada por el propio LiteLLM para "utilidades de bajo riesgo" — hace que cada servidor MCP configurado sea alcanzable por la credencial vacía que la elusión crea (Hive Security). El radio de impacto no es el proxy. Es cada sistema que los servidores MCP del proxy tocan.

Tres fallos, una pasarela

La investigación de Wiz reveló cuatro problemas distintos en LiteLLM con condiciones previas diferentes — aplanarlos en una sola "cadena mágica" tergiversa tanto la gravedad como la respuesta (Wiz):

1. CVE-2026-59822 — la elusión de autenticación MCP. Sin autenticación, una petición, versiones anteriores a 1.84.0. Corregida en 1.84.0.
2. CVE-2026-59821 — ejecución de código a nivel root vía guardrails personalizados. El endpoint de registro de guardrails pasaba Python enviado por el administrador a exec() sin la sandbox (eliminación de builtins, comprobaciones de patrones prohibidos) aplicada en la ruta de prueba de la UI. Wiz observó código ejecutándose como root en el contenedor del proxy. Corregida en 1.82.0-stable. Esta requería acceso de administrador — pero combinada con el modo de fallo 3, se vuelve efectivamente pre-autenticada.
3. Autenticación predeterminada o ausente. El resultado del escaneo de 294 de 3,074. Cuando no se configura ninguna clave maestra, LiteLLM otorgaba a cada llamador acceso PROXY_ADMIN — un comportamiento de diseño sin CVE corregido junto con CVE-2026-59821.
4. Enrutamiento pass-through a metadatos de la nube. Un administrador autenticado puede apuntar una ruta pass-through al servicio de metadatos de instancias AWS y reenviar la cabecera de token de sesión IMDSv2 a través del comportamiento de eliminación de prefijos x-pass- del proxy. Wiz y LiteLLM clasifican esto como comportamiento intencionado del administrador — sin CVE, sin corrección. Pero una vez que una clave maestra predeterminada o filtrada elimina la suposición de que solo administradores confiables poseen la clave, esta capacidad "intencionada" se convierte en el camino del compromiso de la aplicación al compromiso de la cuenta de nube (CSA).

El compounding es la historia. LiteLLM guarda claves API de cada proveedor de modelos configurado — OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI — y aproximadamente un tercio de los entornos de nube encuestados ejecutan un despliegue (CSA). La nota de investigación de CSA llama a la configuración de la clave maestra "una bóveda de credenciales en la nube". La bóveda ya ha sido vaciada una vez: en un compromiso divulgado públicamente en agosto de 2026, un atacante con ejecución de código en un host de pasarela leyó las variables de entorno del contenedor, recuperó la clave maestra y una cadena de conexión a base de datos, y copió registros directamente de la base de datos PostgreSQL que respalda la pasarela (CSA).

Una instancia parcheada no es una instancia segura. Una pasarela parcheada a 1.84.0 que todavía responde a sk-1234 está comprometida por cualquiera que conozca la predeterminada — que es todo el que ha leído el README.

Lo que exige realmente la inclusión en la KEV

El catálogo de Vulnerabilidades Explotadas Conocidas no es una clasificación de gravedad. Es un hallazgo de explotación activa con un reloj vinculante: bajo la BOD 26-04, las agencias civiles federales deben aplicar las mitigaciones del proveedor para la fecha de vencimiento o dejar de usar el producto, y las agencias deben priorizar las instancias expuestas a internet primero. El plazo que llega hoy se aplica directamente a las agencias federales — pero su efecto alcanza más lejos, porque un número creciente de pólizas de ciberseguro y cuestionarios de riesgo de proveedores referencian el catálogo KEV como línea base (Tech Insider). Una instancia sin parchear de CVE-2026-59822 es ahora un hallazgo de auditoría para cualquier organización cuyo régimen de cumplimiento herede la lista KEV, sea o no una agencia federal.

El hito importa para el protocolo, no solo para el producto. CVE-2026-42271 — la inyección de comandos en el endpoint de pruebas de LiteLLM, añadida a KEV en un lote anterior — era MCP-adjacente. CVE-2026-59822 es MCP-específica: la superficie explotada es el endpoint MCP Streamable HTTP y su handler de autenticación. La primera vulnerabilidad MCP con mandato federal de remediación señala de dónde vendrán las siguientes. El aviso de amenazas de UltraViolet Cyber cuenta más de 40 CVEs divulgadas contra implementaciones MCP solo en 2026 (UltraViolet Cyber), el escaneo de internet de Bitsight encontró alrededor de 1,000 servidores MCP expuestos sirviendo inventarios completos de herramientas sin autorización (Bitsight), y Practical DevSecOps midió un 30–82% de servidores MCP públicos con fallos explotables (Practical DevSecOps). La pila de exposición detrás de la primera inclusión en la lista KEV no es un caso atípico. Es la población.

El diagrama de abajo comprime el incidente en un minuto: la cronología que corrió por delante de la respuesta federal, los cuatro modos de fallo que comparten una pasarela, y los seis puntos de verificación que cierran la exposición.

Los seis puntos de verificación

La lista de comprobación de endurecimiento MCP que destila el artículo principal en 12 controles gana ahora un suplemento específico para pasarelas. Seis puntos, cada uno verificable en minutos:

1. Falla cerrado, de forma demostrable. Envía Authorization: Bearer *** al endpoint /mcp/` de la pasarela. Una instancia correctamente configurada devuelve 401 o 403. Una instancia vulnerable devuelve 200 con un ID de sesión. Esta es la prueba de CVE-2026-59822, y toma una petición.
2. Inventaría y actualiza. Encuentra cada instancia de LiteLLM — incluidos despliegues sombra en pilas de desarrolladores — registra su versión y digest de imagen, y fija una versión estable actual. 1.84.0 corrigió primero CVE-2026-59822; 1.82.0-stable corrigió CVE-2026-59821; existen avisos posteriores, así que no te congeles en ninguno de los dos mínimos (Hive Security). Si una actualización inmediata es imposible, la mitigación provisional del aviso es bloquear /mcp/ y rutas relacionadas en el borde.
3. Rota la clave maestra y todo lo que hay detrás. Reemplaza sk-1234 y cualquier clave reutilizada. Si se sospecha exposición o acceso sospechoso, rota las credenciales de proveedores de modelos, base de datos, OAuth y servicios conectados por MCP, y revoca las sesiones derivadas — la cadena de compromiso documentada muestra un compromiso de pasarela que se convierte en cascada directamente en una fuga de claves de proveedor y un volcado de base de datos (CSA).
4. Acota el acceso a herramientas MCP. Elimina allow_all_keys de las integraciones sensibles, separa las herramientas de lectura de las de escritura, y exige autorización por equipo. La elusión concede lo que la sesión pueda alcanzar — la configuración de herramientas es el radio de impacto.
5. Contén el plano de control. Elimina la exposición pública salvo que se requiera explícitamente, deniega el acceso de la carga de trabajo a los servicios de metadatos de nube, lista blanca los destinos de salida, y ejecuta el contenedor como no-root sin montajes privilegiados. IMDSv2 no defiende esta ruta, porque el proxy puede hacer la petición de token y reenviar las cabeceras él mismo (Wiz).
6. Caza en los logs antes de que expiren. Revisa los logs del proxy inverso y de LiteLLM en busca de sesiones /mcp/ autenticadas con tokens de aspecto basura, llamadas a herramientas inesperadas, eventos de creación de guardrails y cambios de configuración pass-through. Correlaciona con logs de proceso, DNS y auditoría de nube — y preserva la evidencia antes de reiniciar, dado que un reinicio limpia el estado en memoria pero no revoca una credencial robada (Hive Security).

Los puntos 1 y 3 son la prioridad del día del plazo: el primero prueba la vulnerabilidad, el segundo cierra la exposición permanente que sobrevive a cualquier parche.

Lo que esto significa más allá de LiteLLM

Dos patrones se generalizan, y ambos pertenecen a cada revisión de autenticación MCP de aquí en adelante.

Primero: los fallbacks fail-open son un olor a código, no un error de LiteLLM. La elusión son tres líneas — capturar el 401, sustituir por un objeto de autenticación vacío, continuar. Cualquier proxy MCP que delegue la autenticación a un proveedor ascendente mediante un fallback passthrough lleva la misma clase. La corrección es un estándar de revisión, no un cambio de versión: cuando la validación ascendente falla, la petición termina. Nunca procede con una identidad no autenticada.

Segundo: las pasarelas son planos de control, y la investigación de confuso deputy dice que fallan en la capa de metadatos. La investigación "Puppet" publicada en ACM evaluó ataques de confuso deputy en 14 modelos sobre 2 hosts MCP y midió tasas de secuestro de selección de herramientas de hasta 90.89% y ejecución de payload de extremo a extremo de hasta 86.46% — permaneciendo indetectable para MCP-Scan y McpSafetyScanner, que son arquitectónicamente incapaces de detectar manipulación a nivel de metadatos (ACM). Una pasarela que concentra credenciales de modelos, visibilidad de prompts y acceso a herramientas detrás de una sola frontera de autenticación es la misma concentración que la AI Controls Matrix de CSA señala para controles de identidad y gestión de secretos (CSA). La traducción operacional: autentica la pasarela como un plano de control y conténla como una frontera de brecha — IAM de mínimo privilegio, sin credenciales predeterminadas, metadatos inalcanzables, salida en lista blanca.

El contexto más amplio es un protocolo que madura de "autorización opcional" a aplicación federal. El escaneo de diciembre de 2025 de Bitsight encontró alrededor de 1,000 servidores MCP expuestos sin autorización (Bitsight); el análisis honeypot de agosto de 2026 de Wiz documentó campañas activas apuntando a LiteLLM, servidores MCP y marcos de IA mediante RCE, inyección de prompt ciega y robo de credenciales de memoria (Wiz); y una tercera elusión de autenticación de LiteLLM — CVE-2026-49468, una inyección de cabecera Host divulgada el 28 de mayo de 2026 — completa un patrón de 2026 donde el mismo producto envió tres fallos de autenticación distintos en un año (aviso de GitHub). La inclusión en la lista KEV es el punto donde ese patrón deja de ser un tema de investigación y se convierte en un elemento de cumplimiento.

La especificación MCP de 2026-07-28 movió el protocolo a un núcleo sin estado y el trabajo de autorización del ecosistema avanza hacia OAuth 2.1 con tokens vinculados a audiencia. La arquitectura cierra clases enteras de vulnerabilidades. Pero el incidente de LiteLLM prueba que la capa operacional decide los resultados: un despliegue sin estado y conforme a la especificación que todavía acepta su clave maestra de ejemplo sigue comprometido. Parchea la CVE, luego audita los predeterminados — en ese orden, antes del próximo plazo.

Lecturas relacionadas

• Lista de comprobación de endurecimiento de seguridad MCP: 1,467 servidores expuestos y los controles que los cierran — el artículo principal: 12 controles de endurecimiento a través de transporte, autenticación, registro de herramientas, runtime y auditoría, cada uno verificable en menos de cinco minutos
• La paradoja MCP: por qué lo friccional es frágil — el análisis de riesgo a nivel de protocolo: por qué un estándar que hace friccional la integración concentra el radio de impacto de brecha al mismo tiempo
• MCP 2026-07-28: lo que el protocolo sin estado significa para los despliegues de agentes B2B — el núcleo de protocolo sin estado que elimina las superficies de ataque de estado de sesión que explota esta clase de CVE

---

Un distribuidor de mercado medio ejecuta un agente de adquisiciones que cotiza contra NetSuite, BigCommerce y tres catálogos de proveedores, con una pasarela LiteLLM enrutando el tráfico de modelos y exponiendo las herramientas MCP del agente. Una verificación de una petición contra /mcp/ prueba que la pasarela falla cerrada; la clave maestra viene del gestor de secretos, nunca del README; el rol IAM de la pasarela no puede alcanzar los metadatos de instancia; y las herramientas MCP que el agente puede invocar están acotadas a leer precios y escribir cotizaciones — nada más. Cuando la próxima inclusión en la lista KEV llegue, la remediación será un cambio de versión, no una investigación de compromiso.

Solicite una implementación delimitada. Descubrimiento de una semana. Obtendrá un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — independientemente de si construye con nosotros.