CISA añade la omisión de autenticación MCP de LiteLLM a KEV: bastaba con cualquier token Bearer

El 2 de septiembre de 2026, la Agencia de Seguridad de Ciberseguridad e Infraestructura de Estados Unidos añadió CVE-2026-59822 a su catálogo de Vulnerabilidades Conocidas y Explotadas como la "Vulnerabilidad de autenticación incorrecta de BerriAI LiteLLM", una de las siete fallas del lote de ese día. El error está en el endpoint HTTP Streamable de MCP de LiteLLM: cuando fallaba la validación de una clave de LiteLLM, el mecanismo de reserva de paso directo de OAuth2 sustituía un objeto UserAPIKeyAuth() vacío en lugar de rechazar la solicitud, por lo que cualquier encabezado Authorization Bearer fabricado abría una sesión MCP autenticada. Un atacante que llegara a ese endpoint podía enumerar y llamar todas las herramientas MCP con las que estaba configurada la puerta de enlace y, a través de esas herramientas, llegar a los servicios que había detrás. Todas las versiones anteriores a la 1.84.0 están afectadas, y las agencias civiles federales tuvieron hasta el 16 de septiembre para remediarlo. Este registro —la inclusión en KEV del bypass de autenticación MCP de LiteLLM— es una entrada en el Archivo de Incidentes de IA de OrcaRouter, que contiene el conjunto completo de registros y las entradas vecinas de este incidente.

La razón por la que un fallo en un proxy importa más de lo que sugiere su puntuación CVSS es lo que hay detrás del proxy. El equipo de investigación de amenazas de Wiz lo dice sin rodeos: «Un proxy LiteLLM puede contener claves para todos los proveedores de modelos a los que enruta, incluidos OpenAI, Anthropic, Azure y Gemini. También puede ejecutarse con permisos de IAM en la nube y conectarse a servicios internos mediante servidores de herramientas MCP. Un único compromiso puede dar a un atacante acceso a las credenciales y los servicios que están aguas abajo del proxy, no solo al propio proxy». Wiz Research afirma que descubrió la vulnerabilidad, y los honeypots de Wiz registraron posteriormente intentos de usarla.

El mecanismo: una comprobación fallida que devolvió una sesión válida

El propio aviso de BerriAI, GHSA-7488-6r32-c95q, describe el defecto en dos frases: «El controlador de autenticación MCP admitía el paso directo de OAuth2 para servidores MCP upstream, pero la ruta de respaldo podía sustituir la validación fallida de la clave de LiteLLM por un objeto UserAPIKeyAuth() vacío. Esto permitía que solicitudes con un encabezado Authorization fabricado llegaran a las herramientas MCP sin una clave de LiteLLM válida». La palabra importante es respaldo. El código tenía una rama para implementaciones que pasan directamente el token OAuth de un servidor MCP upstream, y cuando una clave de LiteLLM no se validaba, esa rama devolvía un objeto de autenticación vacío en lugar de un error.

Un objeto de autenticación vacío no es lo mismo que ningún objeto de autenticación. El código posterior vio un UserAPIKeyAuth construido correctamente y continuó, sin tenant, sin usuario y sin alcance asociados. El artículo de Wiz es más contundente sobre la consecuencia práctica: «cuando falla la validación del token, en lugar de rechazar la solicitud, el servidor devuelve un objeto UserAPIKeyAuth() vacío y sin restricciones. Cualquier token Bearer (incluso un solo carácter, p. ej., x) otorga acceso completo al MCP».

Lo que eso le ofrece a un atacante es un menú. El protocolo MCP expone un listado de herramientas, por lo que una sesión que se autentica devuelve los nombres y esquemas de cada herramienta que la puerta de enlace ha sido configurada para alcanzar —bases de datos, repositorios de código, API internas, en los ejemplos de Wiz. El aviso del proveedor indica el efecto sin rodeos: «Un atacante podría usar esto para listar y llamar herramientas MCP configuradas y acceder a servicios conectados expuestos a través de MCP». Las llamadas a herramientas se ejecutan entonces con la autoridad que el propio proxy tenga hacia esos backends, que es el problema de concentración de credenciales que describe Wiz.

Una corrección en mayo, un CVE en julio, una fecha límite federal en septiembre

Las fechas no cuadran de la forma en que un lector podría suponer, y lo interesante son los intervalos. LiteLLM 1.84.0 —la primera versión que el aviso señala como parcheada— se subió a PyPI el 14 de mayo de 2026, según los propios metadatos de publicación del índice de paquetes. El identificador CVE se reservó con el CVE Program el 7 de julio de 2026 y el registro se publicó al día siguiente, el 8 de julio; la entrada de OSV PYSEC-2026-3479 le siguió el 23 de julio. La inclusión en KEV se produjo el 2 de septiembre, con una fecha límite de remediación el 16 de septiembre.

Dos cosas se desprenden. Primero, la compilación parcheada estuvo pública durante más de tres meses antes de que CISA catalogara la vulnerabilidad como explotada, así que las organizaciones a las que vinculaba la fecha límite tuvieron una actualización funcional disponible todo el tiempo, y la inclusión en KEV no fue el momento en que apareció una solución. Segundo, la brecha de versiones se ha ampliado desde entonces: la versión actual de LiteLLM en PyPI es la 1.106.5, subida el 27 de octubre de 2026. Un despliegue que siga en cualquier versión inferior a la 1.84.0 está ahora más de veinte versiones menores por detrás, no solo un parche por debajo.

Lo que el listado establece, y lo que no.

La alerta de CISA sobre el lote dice que las incorporaciones se realizan "basadas en pruebas de explotación activa", y la entrada legible por máquina del catálogo para CVE-2026-59822 incluye una fecha de incorporación del 2 de septiembre de 2026, una fecha límite del 16 de septiembre de 2026, un valor de "Desconocido" en el campo de uso conocido en campañas de ransomware, y dos debilidades: CWE-287 (autenticación incorrecta) y CWE-306 (falta de autenticación para una función crítica).

• Establecido: CISA evaluó que la vulnerabilidad se estaba explotando activamente y la incluyó en la lista federal de remediación. El registro SSVC de NVD, atribuido a un Coordinador de CISA y con marca temporal del 2 de septiembre de 2026, registra la explotación como "activa", la automatización como "sí" y el impacto técnico como "parcial".

• Confirmado: se observó explotación en un entorno controlado. Wiz publicó tráfico de honeypot que mostraba solicitudes con tokens de un solo carácter sondeando un endpoint de enumeración de modelos: un GET a /v1/models con "Authorization: Bearer x". The Hacker News, al informar sobre el lote de KEV el 3 de septiembre, describió la misma actividad como Wiz observando "esfuerzos de explotación relacionados con CVE-2026-59822 contra sus honeypots para sondear endpoints de enumeración de modelos".

• Confirmado: ambas puntuaciones de gravedad existen y difieren según el marco. El aviso de BerriAI califica la vulnerabilidad con CVSS 4.0 en 8,8, alta, con confidencialidad alta, integridad baja y disponibilidad nula; la propia evaluación CVSS 3.1 de NIST, que es la principal en NVD, la sitúa en 8,2. Ambas cifras describen el mismo defecto bajo sistemas de puntuación distintos y no deben compararse como si una sustituyera a la otra.

• No determinado:ninguna víctima identificada. Ni la alerta de CISA, ni el aviso de BerriAI, ni el informe de Wiz, ni la cobertura de The Hacker News identifican a una organización cuyas herramientas MCP hayan sido alcanzadas mediante esta vulnerabilidad, ni informan de credenciales o datos extraídos de alguna de ellas. El registro público de explotación es telemetría de honeypots y una determinación federal, no una brecha revelada.

• No establecido: que ningún grupo de ransomware lo utilice. El campo KEV indica "Unknown", que es un valor que asigna CISA, no una constatación de ausencia en ningún sentido.

El precedente de junio, y la cadena de ejecución remota de código que esto no es

Esta es la segunda falla de LiteLLM en llegar al catálogo KEV en 2026, y la anterior es fácil de confundir con ella. CVE-2026-42271, añadida el 8 de junio de 2026 con fecha límite el 22 de junio, es una inyección de comandos en los endpoints de prueba del servidor MCP de LiteLLM: Wiz describe endpoints que permiten a un usuario probar la configuración de un servidor MCP antes de guardarla, con el campo command pasado a la ejecución de subprocess sin validación. Los atacantes enviaban una configuración falsa de servidor stdio cuyo comando descargaba y ejecutaba un criptominero, y devolvía un handshake MCP de aspecto válido para que la prueba pareciera exitosa. La entrada de CISA para esta vulnerabilidad enumera CWE-78 y CWE-77 — inyección de comandos y de argumentos, no de autenticación.

Esa falla es la que se encadena. Wiz afirma que CVE-2026-42271 «se puede encadenar con un bypass de validación del encabezado Host de Starlette (CVE-2026-48710) para lograr un RCE totalmente no autenticado», y que investigadores externos han vinculado al grupo de ransomware Qilin con la explotación activa de esa cadena. CVE-2026-48710 se añadió al catálogo KEV en el mismo lote del 2 de septiembre que el bypass de LiteLLM, con la misma fecha límite del 16 de septiembre, y la propia nota del catálogo de CISA sobre la falla de Starlette indica que podría encadenarse con CVE-2026-42271. El vínculo con Qilin pertenece a ese emparejamiento. No es un hallazgo sobre CVE-2026-59822, y nada en las fuentes revisadas vincula al grupo de ransomware con el bypass de autenticación.

Un detalle administrativo separa las dos entradas de LiteLLM: la acción requerida del listado de junio cita la BOD 22-01, la directiva operativa vinculante más antigua, mientras que el listado de septiembre cita la BOD 26-04, «Prioritizing Security Updates Based on Risk». La alerta de CISA no explica el cambio, y el catálogo no lo anota.

¿Qué cambió después?

La ruta de remediación es breve. El aviso de BerriAI recomienda actualizar a 1.84.0 o una versión posterior, y ofrece una solución alternativa para los equipos que no pueden actualizar de inmediato: «deshabilitar las rutas MCP o bloquear el acceso a /mcp/ y a los endpoints MCP relacionados en su proxy inverso o puerta de enlace de API». Esa solución alternativa es un instrumento contundente —elimina la capacidad en lugar de restringirla—, pero es la única mitigación que el proveedor menciona para las implementaciones sin parchear.

El texto de acción requerida de CISA para los puntos de entrada sitúa a las agencias federales ante el mismo dilema: aplicar las mitigaciones conforme a las instrucciones del proveedor y de acuerdo con la BOD 26-04, «o dejar de usar el producto si no hay mitigaciones disponibles», recayendo en cada agencia la responsabilidad de evaluar la exposición a internet de un activo. La directiva solo es vinculante para las agencias del poder ejecutivo civil federal; CISA anima a otras organizaciones a adoptar la misma priorización basada en el riesgo, sin exigirlo.

No se sabe públicamente si alguien fuera de un honeypot actuó ante la fecha límite. Ni CISA ni BerriAI han publicado cifras sobre cuántas implementaciones de LiteLLM quedaron expuestas, cuántas se parchearon antes del 16 de septiembre o cuántas se alcanzaron mediante el bypass.

¿Qué queda abierto?

Vale la pena señalar tres lagunas en lugar de disimularlas. No existe ningún informe público de incidentes que vincule CVE-2026-59822 con una intrusión concreta, por lo que la inclusión en KEV se basa en las pruebas de explotación de CISA y en las observaciones de honeypots de Wiz, no en una víctima documentada. No hay ninguna declaración del proveedor sobre cómo llegó a escribirse así la ruta de respaldo, ni sobre cuánto tiempo existió antes de 1.84.0 —el aviso describe el defecto y su corrección, no su historial—. Y los plazos del lote no eran uniformes: cinco de las siete entradas añadidas el 2 de septiembre tenían un plazo del 5 de septiembre, mientras que las entradas de LiteLLM y Starlette tenían el 16 de septiembre. CISA no dice por qué.

Lo que queda establecido es más limitado y más útil que la puntuación. Un solo carácter en una cabecera Authorization era, en las versiones afectadas, indistinguible de una clave válida para el endpoint MCP — y las versiones que se comportaban así dejaron de ser las actuales en mayo de 2026.