Un ataque a la cadena de suministro de software, realizado durante el mes de marzo, volvió a demostrar que una organización puede quedar expuesta sin ser el objetivo directo de los atacantes. Una investigación de CloudSEK identificó una campaña asociada a TeamPCP que alcanzó componentes utilizados en entornos de desarrollo y terminó afectando la cadena de distribución de LiteLLM, una herramienta ampliamente utilizada para integrar y gestionar distintos modelos de inteligencia artificial.
El episodio, cuyas víctimas de dieron a conocer recientemente, es especialmente relevante por su escala: CloudSEK identificó potencialmente a más de 2.500 organizaciones y 434.000 pipelines de CI/CD vinculados a la exposición. La cifra, sin embargo, no significa que todas esas organizaciones hayan sido comprometidas ni que todos sus secretos hayan sido robados. Se trata de organizaciones cuyos entornos fueron identificados dentro de la superficie potencial de exposición reconstruida por la investigación.
Una cadena de compromisos
El incidente no comenzó directamente con LiteLLM. Según la investigación, los atacantes primero comprometieron herramientas utilizadas dentro de procesos de desarrollo y seguridad, entre ellas Trivy. Desde allí, el ataque pudo propagarse hacia otros componentes de la cadena de suministro.
En el caso de LiteLLM, los atacantes consiguieron publicar las versiones maliciosas 1.82.7 y 1.82.8 en PyPI. El código incorporado en estos paquetes podía buscar información sensible disponible en los entornos donde fueran instalados, incluyendo credenciales cloud, claves SSH, tokens de Kubernetes, credenciales de bases de datos y otros secretos.
La segunda versión incorporó además un archivo «.pth», un mecanismo particularmente relevante porque puede permitir la ejecución automática de código cuando se inicia Python, incluso sin que una aplicación importe explícitamente LiteLLM.
El resultado es una demostración concreta de cómo una dependencia aparentemente legítima puede convertirse en un punto de entrada hacia sistemas mucho más críticos.40 minutos pueden ser suficientesUno de los aspectos más llamativos del incidente es la velocidad. Las versiones maliciosas permanecieron disponibles durante aproximadamente 40 minutos antes de ser retiradas.
A primera vista, puede parecer una ventana demasiado pequeña para provocar un impacto significativo. Sin embargo, en ecosistemas automatizados de desarrollo y despliegue, 40 minutos pueden ser suficientes para que una versión maliciosa sea descargada por múltiples pipelines, incorporada a procesos de construcción o ejecutada dentro de entornos con acceso a secretos.
Y ahí aparece uno de los principales aprendizajes del caso: el tiempo durante el cual un componente malicioso permanece disponible no necesariamente determina la duración del riesgo.Si durante ese período una credencial fue expuesta, eliminar posteriormente el paquete comprometido no revoca esa credencial. El secreto debe ser identificado, evaluado y, cuando corresponda, rotado. Además, la organización debe determinar si pudo haber sido utilizado posteriormente.
En otras palabras, un incidente de minutos puede convertirse en una investigación de semanas o meses.
Chile también aparece en el mapa
La investigación adquiere especial relevancia para las organizaciones chilenas. Dentro de los dominios identificados en la exposición analizada aparecen empresas como Cencosud, Empresas CMPC, Falabella, Datamart Chile, WherEX, TISAL, SKC, Haulmer, Confuturo, ACHS, Universidad de Chile, SCD, Preuniversitario Pedro de Valdivia, Kaufmann Digital, Derco y Gobierno Digital de Chile, entre otras.
También aparecen compañías internacionales con presencia o entidades en Chile, como Edenred, FEMSA, Alicorp, Intcomex, Fractalia, MineSense Technologies y BDO Chile.
La dimensión internacional refuerza todavía más la escala del fenómeno: entre las organizaciones identificadas figuran BBVA, SumUp y el United States Department of Defense.
Es importante reiterar que aparecer en esta investigación no equivale por sí solo a confirmar un compromiso o una intrusión. La identificación corresponde a la superficie de exposición analizada por CloudSEK y requiere investigación individual para determinar qué información pudo estar disponible y si existió algún uso posterior de las credenciales.
Cuando incluso la industria de ciberseguridad queda dentro de la superficie
Quizás uno de los elementos más reveladores de la investigación es la presencia de numerosas organizaciones vinculadas a ciberseguridad, infraestructura tecnológica y desarrollo de software.
La lista incluye nombres como LUMU, CrowdStrike, Fortinet, Palo Alto Networks, Cisco, Check Point, Zscaler, Cloudflare, Okta, Rapid7, Tenable, Mandiant, Sophos, SentinelOne, Darktrace, Proofpoint, Akamai, Snyk, GitLab, Checkmarx, AWS, Salesforce, ServiceNow, Veeam, Jenkins, Apache Software Foundation, F5 y NIST, entre otros.
Esto permite visualizar un problema que va mucho más allá de una vulnerabilidad puntual: ninguna organización existe aislada dentro de su infraestructura tecnológica.
Incluso una empresa con altos niveles de madurez en ciberseguridad depende de software desarrollado por terceros, repositorios públicos, librerías, herramientas de seguridad, servicios cloud y pipelines automatizados. Cada uno de esos elementos puede convertirse en parte de la superficie de ataque.
La cadena de suministro de IA ya es una superficie crítica
La expansión de la inteligencia artificial está haciendo que esta realidad sea todavía más compleja. Las aplicaciones de IA no dependen únicamente de un modelo. Detrás de ellas existe una cadena formada por frameworks, librerías, APIs, herramientas de desarrollo, repositorios, servicios cloud, sistemas de autenticación y procesos automatizados de despliegue.
Por eso, proteger una implementación de IA no consiste solamente en revisar el modelo o controlar quién puede utilizarlo. También es necesario conocer qué componentes intervienen en su construcción y operación, qué permisos poseen y qué información pueden alcanzar.
El caso LiteLLM muestra precisamente ese problema: una herramienta legítima, integrada en procesos automatizados y con acceso a otros recursos, puede convertirse en un punto estratégico para obtener credenciales y ampliar el alcance de un ataque.
La visibilidad se vuelve parte de la defensaEl principal aprendizaje de este incidente no debería ser simplemente “hay que tener cuidado con los paquetes de código abierto”. El desafío es mucho mayor: las organizaciones necesitan saber qué dependencias utilizan, dónde están desplegadas, qué credenciales pueden alcanzar y qué señales podrían indicar que alguna de ellas fue comprometida.
Esto requiere combinar gestión de dependencias y secretos, controles sobre los pipelines CI/CD, principio de mínimo privilegio, monitoreo continuo e inteligencia sobre amenazas y exposición externa.
También exige cambiar el momento en que comienza la respuesta. Esperar a que una credencial sea utilizada, que aparezca una intrusión o que un atacante publique información robada significa actuar cuando el riesgo ya se materializó.
La cadena de suministro de software y de IA seguirá creciendo y, con ella, también lo hará la cantidad de relaciones que una organización debe ser capaz de monitorear. El caso investigado por CloudSEK deja una conclusión clara: no hace falta que el atacante entre directamente por la puerta principal. A veces basta con comprometer una de las herramientas en las que la organización confía.
Por eso, detectar tempranamente una exposición, comprender su alcance y actuar antes de que se transforme en un compromiso efectivo se vuelve cada vez más relevante para la seguridad de las organizaciones.
Referencias
© 2026 CronUp Ciberseguridad. Todos los derechos reservados. Este contenido está protegido por la Ley Nº 17.336. Se permite su uso informativo citando la fuente y enlazando el artículo original. Su reproducción o uso sin atribución constituye infracción.
