Los paquetes permanecieron 40 minutos en PyPI antes de ser detectados — tiempo suficiente para comprometer infraestructura crítica en escala global
En marzo de 2026, dos versiones comprometidas de LiteLLM — una biblioteca Python ampliamente utilizada para integrar modelos de lenguaje — fueron publicadas en el repositorio PyPI con código diseñado para extraer credenciales de infraestructura crítica. Los paquetes maliciosos permanecieron disponibles durante aproximadamente 40 minutos, un período breve pero suficiente para que sistemas automatizados de actualización los descargaran e instalaran en entornos de producción. La firma de inteligencia de amenazas CloudSEK obtuvo acceso a un dataset construido a partir de aproximadamente 434.000 archivos capturados por los atacantes, revelando una exposición potencial que afecta a más de 2.100 organizaciones a nivel global.
El código malicioso insertado en estos releases estaba diseñado para recolectar credenciales de nube, claves SSH, tokens de Kubernetes y contraseñas de bases de datos — exactamente el tipo de secretos que permiten movimiento lateral en infraestructuras corporativas. La capacidad de exfiltrar este tipo de material en menos de una hora de exposición pública subraya la velocidad con la que las cadenas de suministro de software modernas pueden convertirse en vectores de compromiso masivo.
Cómo 40 minutos bastaron para comprometer infraestructura en escala
La ventana de exposición de 40 minutos no es un detalle menor. En entornos de integración continua y despliegue automatizado, las actualizaciones de dependencias se ejecutan sin intervención humana. Un pipeline de CI/CD configurado para instalar la última versión disponible de LiteLLM habría descargado el paquete malicioso, ejecutado su código de instalación y entregado credenciales a los atacantes antes de que ningún administrador notara la anomalía. Este patrón — compromiso silencioso en ventanas de minutos — es exactamente lo que hace que los ataques a repositorios públicos sean tan efectivos contra organizaciones con prácticas de actualización agresivas.
El dataset de 434.000 archivos obtenido por CloudSEK representa el alcance de la exfiltración lograda en ese período. Cada archivo capturado corresponde a un secreto extraído de un sistema que instaló una de las versiones comprometidas. La cifra de más de 2.100 organizaciones potencialmente expuestas sugiere que el impacto no se limitó a usuarios individuales o proyectos pequeños, sino que alcanzó infraestructuras corporativas con acceso a recursos críticos.
El vínculo con el hack de Trivy y un patrón de compromiso en cadena
CloudSEK vinculó este incidente al hack previo de Trivy, una herramienta de escaneo de vulnerabilidades ampliamente adoptada en pipelines de seguridad. La conexión entre ambos ataques sugiere que los actores detrás de estas campañas están apuntando deliberadamente a herramientas de infraestructura y seguridad — precisamente las que las organizaciones confían para proteger sus sistemas. Comprometer una herramienta de escaneo de vulnerabilidades y luego una biblioteca de integración de modelos de lenguaje no es coincidencia: es una estrategia para infiltrar entornos donde la confianza en las dependencias es estructural.
Este patrón de compromiso en cadena — atacar herramientas que a su vez son usadas para construir o asegurar otras herramientas — amplifica el radio de impacto. Un solo paquete malicioso en PyPI puede propagarse a través de docenas de proyectos downstream que lo incluyen como dependencia, multiplicando la superficie de ataque sin necesidad de comprometer cada objetivo individualmente.
Exposición en América Latina por dependencia de infraestructura compartida
Aunque el dataset obtenido por CloudSEK no desglosa exposición por región geográfica, la adopción de LiteLLM en proyectos de inteligencia artificial y automatización en América Latina es documentada. Empresas de fintech en Brasil, plataformas de e-commerce en México y startups de IA en Argentina utilizan bibliotecas Python de uso general como LiteLLM para integrar capacidades de lenguaje natural en sus productos. La dependencia de repositorios públicos sin mecanismos de verificación de integridad — una práctica común en equipos con recursos limitados de seguridad — deja a estas organizaciones expuestas al mismo riesgo que afectó a las 2.100 organizaciones identificadas globalmente.
La falta de visibilidad sobre qué versiones específicas de dependencias están corriendo en producción es un problema estructural en la región. Equipos que actualizan dependencias manualmente o que confían en herramientas de gestión de paquetes sin políticas de pinning de versiones pueden haber instalado los releases maliciosos sin registro alguno del evento. La ausencia de telemetría sobre instalaciones de paquetes en entornos corporativos latinoamericanos dificulta estimar el impacto real en la región, pero la exposición potencial es equivalente a la de cualquier otra geografía con adopción de Python en infraestructura crítica.
Qué tipo de credenciales quedaron expuestas y por qué importan
El código malicioso apuntó específicamente a credenciales de nube, claves SSH, tokens de Kubernetes y contraseñas de bases de datos. Estos cuatro tipos de secretos representan acceso directo a infraestructura crítica: credenciales de nube permiten aprovisionar recursos o acceder a almacenamiento de datos, claves SSH abren acceso a servidores remotos, tokens de Kubernetes otorgan control sobre clusters de contenedores y contraseñas de bases de datos exponen información sensible almacenada. La combinación de estos vectores en un solo payload de exfiltración indica que los atacantes buscaban maximizar el valor de cada instalación comprometida.
La capacidad de extraer estos secretos en tiempo de instalación — sin necesidad de persistencia posterior — reduce la probabilidad de detección. Un paquete que roba credenciales durante su setup y luego se comporta normalmente es más difícil de identificar que malware que establece backdoors o ejecuta comandos remotos. Esta técnica de hit-and-run es particularmente efectiva contra organizaciones que monitorean comportamiento en runtime pero no auditan el código de instalación de dependencias.
Nuestro análisis
Este incidente confirma un patrón que ya habíamos observado en compromisos previos de repositorios públicos: la ventana de exposición no necesita ser larga para causar daño estructural. Cuarenta minutos en PyPI fueron suficientes para que código malicioso alcanzara infraestructura de más de 2.100 organizaciones, un ratio de impacto que supera ampliamente el de ataques dirigidos tradicionales. La conexión con el hack de Trivy refuerza la hipótesis de que estamos frente a actores que entienden la topología de confianza en cadenas de suministro de software y la explotan sistemáticamente.
Lo que todavía no sabemos es cuántas de esas 2.100 organizaciones detectaron el compromiso y rotaron credenciales antes de que los atacantes las usaran. El dataset de 434.000 archivos representa exposición potencial, no explotación confirmada — pero la ausencia de reportes públicos de incidentes derivados no significa que no haya habido uso malicioso de las credenciales robadas. La falta de obligación de reporte en muchas jurisdicciones permite que compromisos de este tipo permanezcan invisibles hasta que se manifiestan como brechas secundarias meses después. ¿Cuántas de esas credenciales siguen activas hoy, esperando ser usadas en una segunda fase de ataque que nunca llegó a ser pública?