Atacantes superaron múltiples controles de seguridad independientes para publicar la versión 1.107.0 con un stealer de credenciales y backdoor en repositorios oficiales.
LiteLLM, proveedor de infraestructura para integración de modelos de lenguaje, divulgó el 21 de octubre de 2026 que su pipeline de release fue comprometido durante la madrugada de ese mismo día. Los atacantes lograron publicar una versión maliciosa del paquete Python — identificada como 1.107.0 — en Docker Hub y Python Package Index (PyPI), los dos repositorios oficiales de distribución. El paquete contenía un credential stealer y un backdoor. La compañía indicó que el incidente ocurrió aproximadamente a las 4:00 a.m. y que los atacantes superaron múltiples controles de seguridad independientes, lo que sugiere un nivel de preparación y reconocimiento previo del entorno de desarrollo.
Cómo un token filtrado en logs pudo habilitar el acceso al pipeline
LiteLLM sospecha que la causa del compromiso fue un GitHub token leak en los logs del AI Gateway, el componente que gestiona el enrutamiento de solicitudes a diferentes proveedores de modelos. Los tokens de GitHub con permisos de escritura en repositorios permiten ejecutar acciones automatizadas, incluida la publicación de nuevas versiones en registros de paquetes. Si un token con estos privilegios queda expuesto en logs — ya sea por error de configuración o por falta de sanitización — cualquier actor con acceso a esos logs puede utilizarlo para autenticarse como el sistema de CI/CD legítimo.
El hecho de que los atacantes hayan logrado superar múltiples controles de seguridad independientes indica que no se trató de un simple uso de credenciales filtradas. Es probable que hayan necesitado eludir validaciones de firma de commits, revisiones automatizadas de código o políticas de aprobación de releases. Esto sugiere que el token comprometido tenía permisos amplios o que los controles de seguridad del pipeline no estaban configurados para detectar publicaciones desde contextos anómalos — por ejemplo, desde direcciones IP no esperadas o sin la firma criptográfica de los mantenedores habituales.
Qué contenía la versión maliciosa y cómo operaba
La versión 1.107.0 incluía dos componentes maliciosos: un credential stealer y un backdoor. El stealer de credenciales está diseñado para extraer tokens de API, claves de acceso a servicios en la nube y otros secretos almacenados en variables de entorno o archivos de configuración. En el contexto de LiteLLM — una herramienta que gestiona credenciales para múltiples proveedores de modelos de lenguaje como OpenAI, Anthropic o Cohere — el impacto potencial es directo: cualquier organización que haya instalado la versión comprometida pudo haber expuesto sus claves de API a los atacantes.
El backdoor, por su parte, permite a los atacantes mantener acceso persistente al entorno comprometido incluso después de que se elimine el paquete malicioso. Esto es crítico en infraestructuras de producción donde LiteLLM actúa como gateway centralizado: un backdoor en ese punto de control puede interceptar tráfico, modificar respuestas de modelos de lenguaje o exfiltrar datos de usuarios finales sin que las aplicaciones cliente lo detecten. La combinación de ambos componentes — exfiltración inmediata de credenciales y persistencia a largo plazo — es característica de operaciones de supply chain attack con objetivos de espionaje o monetización posterior.
Exposición en América Latina por dependencia de infraestructura Python compartida
Aunque LiteLLM no reportó datos específicos sobre descargas o instalaciones en América Latina, la región enfrenta una exposición estructural significativa. PyPI es el repositorio estándar para paquetes Python en todo el mundo, y Docker Hub es el registro de imágenes de contenedores más utilizado. Cualquier equipo de desarrollo en Argentina, Brasil, México, Chile o Colombia que haya actualizado LiteLLM durante la ventana de compromiso — entre las 4:00 a.m. del 21 de octubre y el momento en que se retiró la versión maliciosa — pudo haber instalado el paquete comprometido sin ninguna señal de alerta visible.
El riesgo es particularmente alto en startups y equipos de inteligencia artificial que operan con ciclos de actualización rápidos y sin procesos de validación de integridad de paquetes. En Brasil, donde el ecosistema de IA generativa ha crecido aceleradamente en sectores financiero y de salud, la dependencia de herramientas como LiteLLM para gestionar múltiples proveedores de modelos es común. Si alguna de esas organizaciones instaló la versión 1.107.0 en entornos de producción, sus credenciales de API — que en muchos casos incluyen acceso a datos sensibles procesados por modelos de lenguaje — pudieron haber sido exfiltradas sin que el equipo de seguridad lo detectara en tiempo real.
Por qué los controles de seguridad tradicionales no detuvieron el ataque
El hecho de que los atacantes hayan comprometido múltiples controles de seguridad independientes revela una brecha en la arquitectura de defensa del pipeline de release. Los controles tradicionales — como la revisión de código, las pruebas automatizadas o la firma de commits — están diseñados para detectar errores o modificaciones no autorizadas en el código fuente. Pero si un atacante tiene acceso a un token con permisos de publicación directa en registros de paquetes, puede eludir todo el flujo de revisión y publicar una versión maliciosa sin que el código fuente en el repositorio de GitHub refleje ningún cambio sospechoso.
Esto es lo que se conoce como un ataque de publicación directa: el código malicioso nunca pasa por el repositorio de control de versiones, sino que se inyecta directamente en el artefacto final que se distribuye a los usuarios. En este escenario, los controles de seguridad que operan sobre el código fuente — como análisis estático, revisión de pull requests o escaneo de dependencias — son completamente ineficaces. La única defensa efectiva es la validación de integridad en el momento de la publicación: verificar que el artefacto publicado coincida con el código fuente aprobado y que esté firmado criptográficamente por un mantenedor autorizado.
Nuestro análisis
Este incidente confirma un patrón que ya se observó en compromisos anteriores de supply chain en el ecosistema Python: los atacantes no necesitan explotar vulnerabilidades técnicas complejas si pueden acceder a credenciales con permisos de publicación. El caso de LiteLLM es particularmente relevante porque demuestra que incluso proyectos con múltiples controles de seguridad pueden ser comprometidos si esos controles no están diseñados para detectar publicaciones anómalas en los registros de distribución. La sospecha de que un GitHub token filtrado en logs fue la causa inicial del compromiso refuerza la necesidad de sanitización estricta de logs en aplicaciones que manejan credenciales de terceros — algo que en el contexto de gateways de IA, donde se gestionan tokens de múltiples proveedores, es crítico.
Lo que todavía no se sabe es cuántas instalaciones de la versión 1.107.0 ocurrieron antes de que se retirara el paquete, ni si los atacantes lograron exfiltrar credenciales de entornos de producción. LiteLLM no ha divulgado datos sobre el alcance del compromiso ni sobre las medidas de remediación implementadas más allá de la eliminación del paquete malicioso. Tampoco está claro si los controles de seguridad que fueron superados incluían validación de firma criptográfica o si el pipeline dependía únicamente de autenticación basada en tokens. ¿Qué pasaría si este patrón — filtración de tokens en logs, publicación directa sin revisión, compromiso de múltiples controles — se repitiera en otros proyectos de infraestructura crítica para IA en la región?