La clave maestra de LiteLLM que nadie revocó permitió a un atacante publicar una versión maligna del paquete en PyPI, Docker Hub y GHCR. El error se detectó el mismo día en que la clave quedó expuesta, el 27 de mayo de 2026. Alguien escribió en la lista interna que había que revocarla. La revocación nunca ocurrió.
LiteLLM publicó el viernes el análisis completo de causa raíz, firmado por Oliver Jensen y Mateo Wang. La historia es incómoda porque no hay un asalto espectacular: hay una clave en un archivo de configuración, un repositorio público y cuatro meses de olvido. El programa conecta aplicaciones con modelos de lenguaje de distintos proveedores: por sus manos pasan claves de inferencia de medio sector.
Clave maestra de LiteLLM: del archivo público al dueño de GitHub
El 27 de mayo, un archivo de configuración llegó al repositorio público LiteLLM-Labs/lite-harness con la clave maestra de una instalación de LiteLLM Agent Platform, una herramienta interna para orquestar agentes. El equipo reescribió el historial para tapar el error y marcó las claves expuestas como pendientes de revocación. La clave maestra quedó viva.
El 10 de octubre, un atacante desde la dirección 69.48.229.143 usó esa clave contra la plataforma. A las 21:27 UTC, una consulta a la interfaz del servicio devolvió la configuración de los agentes gestionados, incluido un token OAuth de GitHub CLI perteneciente a uno de los dos dueños de la organización. Ese token no tenía límites de alcance y, al ser posterior a la verificación en dos pasos, tampoco pedía confirmaciones extra para acciones sensibles. Traducción práctica: el atacante pasó a mandar como dueño en todos los repositorios.
La noche siguió con limpieza de huellas. Entre las 22:11 y las 22:12 UTC, dos ramas desechables con nombres que empezaban por ci-tmp- ejecutaron flujos automáticos que enviaron a un servidor externo controlado por el atacante los tokens de dos ingenieros con permisos de mantenimiento. Las ejecuciones se borraron minutos después. El 12 de octubre hubo otra ronda: claves de Anthropic, OpenAI, AWS Bedrock, Tavily y hasta de GitGuardian, el servicio que vigila secretos filtrados, además de datos de PostgreSQL y Redis, detalló Socket.
Publicar una versión nueva exigía dos candados: que un ingeniero autorizado la lanzara y que una cuenta especial, atada a un dispositivo físico guardado en la oficina, la aprobara. Esa exigencia se había relajado esa misma semana para publicar correcciones con más frecuencia, dejando la aprobación en manos de dos ingenieros cualesquiera. El atacante tenía dos tokens de ingenieros. Tenía la llave y tenía la copia.
Clave maestra de LiteLLM y la versión maligna del 21 de octubre
El 21 de octubre a las 10:08 UTC, el atacante desactivó la protección de la rama principal y redirigió el sistema de publicación hacia un repositorio de imitación, Berri-AI/litellm, casi idéntico en nombre al oficial BerriAI/litellm. Disparó la publicación con un token robado y la aprobó con el otro a las 11:11 UTC. Entre las 11:39 y las 11:40 UTC salieron siete paquetes de la versión 1.107.0 hacia PyPI; a las 11:46 UTC llegaron las imágenes a Docker Hub y GHCR. Los registros de ambas ejecuciones se borraron entre las 11:53 y las 11:54 UTC.
La respuesta llegó rápido. El investigador Lidor Machluf, de Upwind, abrió el aviso público a las 12:06 UTC. PyPI puso la versión en cuarentena a las 13:23 UTC y a las 14:20 UTC las etiquetas afectadas de Docker Hub —v1.107.0, latest, main-latest y main-stable— ya estaban retiradas o apuntando a imágenes limpias verificadas. La ventana de exposición en PyPI rondó una hora y tres cuartos. Corta. Suficiente.
El contenido de la versión maligna explica la prisa. El código se ejecutaba al arrancar Python, aunque la aplicación nunca importara LiteLLM, gracias a un archivo de arranque colocado fuera de la carpeta del programa. Microsoft advirtió de ese detalle: borrar los archivos de la aplicación puede dejar vivos los componentes de arranque. El paquete incluía un módulo que robaba credenciales de herramientas de desarrollo, nubes, navegadores, claves SSH y tokens de gestores de paquetes, y una puerta trasera para sistemas Unix que pedía código nuevo cada hora. Los datos salían hacia un dominio de imitación registrado el 13 de octubre.
Qué hacer si instalaste la versión maligna de LiteLLM
Quien haya instalado litellm 1.107.0 o descargado las etiquetas de contenedor afectadas el 21 de octubre debe tratar el entorno como comprometido: detener procesos, reconstruir la máquina o el contenedor desde una imagen limpia y rotar todas las credenciales al alcance de ese entorno, empezando por las claves de los proveedores de modelos. LiteLLM dice estar revocando cada token de sus sistemas internos y de sus plataformas externas, y al inicio de la respuesta expulsó de su organización de GitHub a todos los miembros menos una cuenta verificada como sana. La empresa también corrigió su primera hipótesis: los tokens no salieron de los registros de una instalación interna, salieron de aquella clave de mayo.
El análisis de causa raíz se publicó el 23 de octubre a las 21:00 UTC y la empresa promete contar la semana próxima qué cambiará en sus procesos. La lección para cualquier equipo que use agentes con permisos amplios es seca: borrar un archivo de un repositorio no revoca nada. La clave siguió funcionando 136 días después de que alguien escribiera, por escrito, que había que revocarla.
Fuente: The Hacker News
Foto: The Hacker News
La entrada Clave maestra de LiteLLM y versión maligna en PyPI se publicó primero en Tecnología Geek.