Ciberseguridad

CloudSEK vincula la filtración de marzo de LiteLLM a 2.500 organizaciones

mm
Añade Unite.AI a tus fuentes preferidas en Google

La empresa de inteligencia de amenazas CloudSEK informó en un informe publicado el 11 de agosto de 2026 que ha identificado a más de 2.500 organizaciones potencialmente expuestas por el compromiso de la cadena de suministro de LiteLLM en marzo de 2026, y ha reconstruido aproximadamente 434.000 pipelines de CI/CD afectadas por la exposición.

Las cifras provienen de un informe de investigación de CloudSEK basado en un conjunto de datos de víctimas que la empresa dice que su equipo de inteligencia de amenazas obtuvo sobre la campaña de marzo. El conjunto de datos de CloudSEK contiene coincidencias de alta confianza vinculadas a dominios corporativos, repositorios, credenciales o infraestructura que pertenecen a organizaciones como NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales y London Stock Exchange Group. La empresa es explícita sobre lo que significan las coincidencias: la alta confianza describe la fuerza de la evidencia que vincula la información expuesta a una organización, no la prueba de que la organización fue vulnerada o de que un atacante utilizó lo que se extrajo.

El incidente que se encuentra en el centro de la investigación comenzó el 24 de marzo de 2026, cuando un grupo rastreado como TeamPCP publicó versiones maliciosas de LiteLLM 1.82.7 y 1.82.8 en el Índice de Paquetes de Python. Las versiones con malware estuvieron disponibles durante aproximadamente 40 minutos antes de ser eliminadas. Esa ventana fue suficiente: las pipelines de CI/CD instalan dependencias automáticamente y a menudo se ejecutan con amplios privilegios, por lo que un paquete envenenado se propaga a través de los sistemas de compilación corporativos a velocidad de máquina sin que ningún desarrollador lo revise.

Cómo un token filtrado llegó a 434.000 pipelines

LiteLLM nunca fue atacado directamente. La cadena documentada en el informe de CloudSEK comienza un paso más arriba, con Trivy, un escáner de seguridad de código abierto ampliamente utilizado. Un token de automatización filtrado asociado con el escáner se rotó pero no se revocó completamente, lo que dejó una ventana de aproximadamente 20 días en la que los atacantes forzaron el envío de código malicioso sobre las etiquetas de versión publicadas del escáner. Dado que la propia pipeline de compilación de LiteLLM instaló Trivy sin bloqueo desde el administrador de paquetes del sistema, el escáner comprometido fluyó directamente hacia la compilación, y la compilación envenenada produjo y publicó las versiones maliciosas 1.82.7 y 1.82.8 en PyPI. Un token no revocado, tres herramientas más abajo.

El diseño de la carga útil hizo que la ventana corta contara. La versión 1.82.8 dejó un archivo malicioso .pth en el entorno de Python, y los archivos .pth se ejecutan siempre que se inicia el intérprete de Python, ya sea que se importe o no LiteLLM. Eso evita por completo las protecciones de script en el momento de la instalación. En los ejecutores comprometidos, el ladrón de credenciales que el FBI llama SANDCLOCK se elevó a root y barrió claves SSH, credenciales de AWS, Google Cloud y Azure, tokens de cuenta de servicio de Kubernetes, archivos de entorno y secretos de CI/CD, raspando valores de la memoria del proceso que normalmente intenta ocultar la herramienta. Las claves de la nube vinieron directamente del servicio de metadatos de la instancia, utilizando el acceso que ya tenía el ejecutor en lugar de cualquier exploit. Para las compilaciones de AI específicamente, la captura incluyó claves de API de LLM y configuración de pasarela: las credenciales de toda la pila de AI de una organización.

Los datos robados se cifraron con una clave codificada de forma rígida y se exfiltraron a un dominio de typosquatting. Donde la exfiltración falló, el malware creó un repositorio público dentro de la cuenta de GitHub de la víctima y subió el material robado allí como un activo de lanzamiento, lo que significa que algunas organizaciones publicaban sus propios secretos a la vista de todos.

Por qué el riesgo sobrevivió al paquete

Eliminar las versiones maliciosas de PyPI no cerró el incidente. Cualquier credencial copiada mientras el paquete envenenado estuvo activo permanece válida hasta que el propietario la rote o la revoque, y la eliminación del paquete no hace nada por sí sola. El FBI hizo el mismo punto en un aviso FLASH del 2 de julio de 2026 sobre TeamPCP, advirtiendo que las organizaciones afectadas por la campaña deben tratar los datos y credenciales exfiltrados como un riesgo persistente porque es probable que los actores afiliados los utilicen mucho después de la intrusión inicial.

El aviso confirma el alcance de la campaña más allá de LiteLLM: TeamPCP trojanizó Trivy, el escáner KICS de Checkmarx, LiteLLM y el SDK de Python de Telnyx, herramientas incrustadas en pipelines empresariales, infraestructura en la nube y flujos de trabajo de seguridad, y emparejó las intrusiones con extorsión, publicando nombres de víctimas en un sitio de fugas público y amenazando con divulgar datos robados.

Las mitigaciones recomendadas por el FBI coinciden casi exactamente con lo que la cadena de LiteLLM explotó: anclar las acciones de GitHub a hashes de confirmación verificados en lugar de etiquetas de versión flotantes, rotar cada secreto de CI/CD y token de publicación accesible durante la ventana de exposición, hacer cumplir el alcance de los privilegios mínimos en cuentas de servicio y tokens de registro, y buscar en las organizaciones de GitHub repositorios con los nombres tpcp-docs o docs-tpcp, que el malware crea con credenciales robadas.

Qué significan las etiquetas de confianza

CloudSEK ordena las organizaciones en su conjunto de datos por fuerza de la evidencia. Una coincidencia de alta confianza se basa en dominios corporativos identificables, repositorios, credenciales o infraestructura; una coincidencia de confianza media lleva indicadores creíbles pero más débiles. Ninguna de las etiquetas es evidencia de un ataque exitoso, y la empresa enfatiza que el conjunto de datos es una exposición reconstruida: aparecer en él significa que la información asociada con la organización se identificó y debe investigarse, no que se confirme una vulneración.

Algunas precauciones sobre la escala son oportunas. Las cifras de 2.500 organizaciones y 434.000 pipelines provienen de un conjunto de datos que CloudSEK obtuvo a través de sus canales de inteligencia y reconstruyó, y la empresa vende la plataforma de monitoreo de exposición, AIVigil, hacia la que apunta esta investigación. Nada de eso socava la campaña subyacente: el compromiso de LiteLLM, su lugar en la operación más amplia de TeamPCP y las clases de credenciales en riesgo están corroborados por el aviso del FBI y por el registro de incidentes de marzo.

CloudSEK ha publicado un verificador de exposición gratuito donde las organizaciones pueden ver si su infraestructura aparece en el conjunto de datos. Su orientación para cualquier coincidencia es tratar cada credencial que el proceso afectado podría leer como potencialmente expuesta hasta que se valide, revisar los registros de acceso en los sistemas de nube, control de código fuente, registro y clúster, y rotar ampliamente en lugar de solo la clave de LiteLLM o la clave del proveedor de modelos. Para las organizaciones que ejecutaron las versiones afectadas en marzo, la decisión de rotación tiene un reloj de cinco meses que ya está en marcha.

Miles Okada es un analista generado por IA en Unite.AI, que cubre inteligencia artificial y ciberseguridad con un enfoque en amenazas emergentes, arquitecturas defensivas y la dinámica en constante evolución entre atacantes y sistemas automatizados. Su trabajo examina cómo la IA está redefiniendo las operaciones de seguridad, desde la detección y respuesta de amenazas autónomas hasta el surgimiento de técnicas de IA adversariales.
Con una perspectiva técnica e investigadora, Miles analiza investigaciones de seguridad, divulgaciones de incidentes y despliegues en el mundo real para entender dónde la IA fortalece las defensas y dónde introduce nuevas vulnerabilidades. Presta especial atención a la explotación de modelos, envenenamiento de datos, automatización de ataques y las realidades operativas de proteger sistemas impulsados por IA a gran escala.
Los artículos escritos por Miles Okada son generados por IA y revisados por el equipo editorial de Unite.AI para garantizar la precisión, el rigor y la cobertura responsable del panorama de seguridad de IA en constante evolución.