CISA añadió CVE-2026-42271 a su catálogo Known Exploited Vulnerabilities el 8 de junio de 2026, confirmando explotación activa en la naturaleza y dando a las agencias civiles federales hasta el 22 de junio para remediar. La vulnerabilidad es una falla de inyección de comandos en LiteLLM, el proyecto open-source de BerryAI que da a los equipos una sola interfaz formato-OpenAI frente a docenas de model providers, desplegado ya sea como Python SDK o, más relevante aquí, como gateway AI y proxy standalone que gestiona API keys, tracking de costo y routing de tráfico. Si corres un LLM proxy en producción, hay una chance significativa de que sea LiteLLM, y eso es exactamente por qué este importa más de lo que su línea CVSS sola sugeriría.
El mecanismo es específico y vale la pena entenderlo. Dos endpoints, POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list, aceptaban configuraciones de servidor completas y luego spawneaban los comandos suministrados como subprocesses corriendo con los privilegios del proceso proxy mismo, sin sanitización propia del input. Eso es inyección de comandos textbook: el input que se suponía describiera un servidor MCP a testear se convierte en cambio en un comando que el host ejecuta. El acceso inicial requiere nominalmente una valid proxy API key, lo cual suena como una barrera significativa hasta que lees la segunda mitad: ese requirement puede ser bypasseado enteramente vía CVE-2026-48710, un BadHost authentication bypass en Starlette (el framework ASGI debajo), que convierte un bug authenticated-only en uno unauthenticated para cualquier deployment que no haya también parcheado Starlette. El fix aterrizó en LiteLLM v1.83.7, que tanto sanitiza los endpoints como añade un control de autorización restringiendo los MCP test endpoints a los users con el rol PROXY_ADMIN.
La razón por la que esto se eleva por encima de un CVE rutinario es dónde LiteLLM sit en el stack. El proxy es el único component que, by design, tiene los credentials para cada model provider que ruteas a través: tu key OpenAI, tu key Anthropic, tus keys de cloud-inference, y a menudo los secrets para cualquier otra cosa a la que el proxy esté wired. La ejecución de comandos en ese host por lo tanto no es un evento contenido, es un acceso inmediato al montón de credentials más concentrado en tu infraestructura AI, más un foothold para moverse lateralmente en todo lo que esos credentials alcanzan. El writeup help-net es blunt sobre la cadena de impacto: ejecución de comandos arbitraria, robo de credentials y secrets de model-provider, y movimiento lateral en sistemas AI conectados. Y el contexto lo hace peor, esta es la segunda vulnerabilidad LiteLLM weaponizada en un solo mes después de un incidente de mayo 2026, y BerryAI también sufrió un ataque supply-chain de marzo 2026 vía paquetes PyPI maliciosos. La capa gateway está siendo activamente sondeada, y los atacantes han notado que es donde viven las keys.
Lunes por la mañana, las acciones no son sutiles y no son opcionales si self-hosteas LiteLLM. Primero, upgrade a v1.83.7 o posterior hoy, este es el que realmente cierra el hueco. Segundo, si no puedes upgrade inmediatamente, bloquea el acceso de red a los endpoints /mcp-rest/test/connection y /mcp-rest/test/tools/list en tu reverse proxy o load balancer como medida interina. Tercero, rota cada credential que el proxy haya tocado, sobre la asunción de que si estuviste expuesto deberías tratar las keys como comprometidas, provider keys, connector secrets, cualquier cosa en el environment del proxy. Cuarto, restringe la exposición de red del proxy a segmentos de confianza en vez de dejar las superficies admin y test alcanzables desde el internet abierto, que es la configuración que transforma esto de un mal día en un breach. Y parchea Starlette también, porque CVE-2026-48710 es lo que quita el prerequisito API-key, y una defensa que depende de que el atacante no tenga el bypass no es una defensa. Si trackeas el hilo más amplio de agent-security, esta es la versión concreta de la advertencia que se ha estado construyendo en la research, mientras más las capas gateway y runtime se vuelven infraestructura crítica, más se vuelven el objetivo, y el LLM proxy está ahora demostrablemente en la línea de frente.