Una veintena de instituciones nacionales, incluido el sitio del Gobierno, figuran en la lista de dominios potencialmente expuestos por el ataque a LiteLLM, la herramienta de código abierto usada por miles de empresas para conectar sus sistemas con distintos proveedores de inteligencia artificial.
Por Omar Villegas Vega, asesor en Ciberseguridad y Prevención de Fraude Digital
La Agencia Nacional de Ciberseguridad (ANCI) confirmó que está monitoreando un riesgo de exposición que afecta a una veintena de sitios chilenos —entre ellos el del Gobierno de Chile— luego de que se hiciera pública una de las mayores brechas de seguridad en infraestructura de inteligencia artificial registradas a nivel mundial este año: el hackeo a LiteLLM, una popular herramienta de código abierto que actúa como puerta de enlace entre las empresas y distintos proveedores de modelos de IA.
¿Qué es LiteLLM y qué pasó?
LiteLLM es una pieza de software ampliamente adoptada por equipos de desarrollo en todo el mundo. Funciona como un intermediario técnico: permite que una empresa conecte sus sistemas con proveedores de IA como OpenAI, Anthropic o Google sin tener que programar una integración distinta para cada uno.
El problema no comenzó en LiteLLM, sino en un eslabón anterior de la cadena. Según reconstruyeron los investigadores de seguridad, el grupo de atacantes conocido como TeamPCP comprometió primero Trivy, un escáner de vulnerabilidades de código abierto muy utilizado por otros proyectos de software para revisar que su código fuera seguro. Como el propio equipo de LiteLLM usaba Trivy en su proceso automático de construcción y publicación de software (CI/CD) sin fijar una versión específica y verificada, la versión maliciosa de Trivy se ejecutó automáticamente dentro de su entorno.
Eso le dio a los atacantes acceso al token que usa LiteLLM para publicar oficialmente sus actualizaciones en PyPI, el repositorio público desde donde miles de empresas descargan este tipo de herramientas. Con esa llave en su poder, TeamPCP publicó dos versiones adulteradas del programa —identificadas como 1.82.7 y 1.82.8— que permanecieron disponibles para descarga durante apenas 40 minutos antes de ser detectadas y retiradas.
Ese breve margen fue suficiente para provocar un daño de escala global. De acuerdo con el análisis de la firma de ciberinteligencia Hudson Rock sobre un archivo robado de 153 gigabytes, <cite index=»16-1″>se lograron atribuir 118.829 volcados de datos de entornos de desarrollo a 2.488 dominios corporativos distintos</cite>. Otra firma de seguridad, CloudSEK, entregó una cifra algo mayor: <cite index=»17-1″>más de 2.500 organizaciones potencialmente expuestas y cerca de 434.000 pipelines de integración y despliegue continuo comprometidos. </cite>
Entre las organizaciones cuyos nombres aparecen vinculados al material filtrado se cuentan empresas de la magnitud de <cite index=»19-1″>NVIDIA, Volkswagen, Microsoft, FedEx, S&P Global, John Deere, Epic Games, Orange, TomTom, BT Group, ServiceNow, Deloitte y Siemens</cite>, además de gigantes tecnológicos como Amazon, Cisco y Samsung, según reportes coincidentes de distintas firmas de ciberseguridad internacional.
¿Qué buscaban los atacantes?
Lo relevante de este ataque no es que se haya robado información personal de usuarios finales de forma directa, sino algo más estructural: las credenciales que usan las propias empresas para operar internamente. Según el análisis técnico, el software malicioso capturaba en tiempo real:
- Claves de acceso a servicios en la nube (AWS, Google Cloud, Microsoft Azure).
- Tokens de acceso a repositorios de código (GitHub, GitLab).
- Credenciales de clústeres de Kubernetes, la tecnología que administra la infraestructura de muchas aplicaciones modernas.
- Llaves de acceso a proveedores de inteligencia artificial (OpenAI, Anthropic, Google Gemini, entre otros).
- Secretos internos como tokens de Slack o variables de entorno con información sensible de configuración.
En otras palabras, no se trató de un robo de contraseñas de clientes, sino del robo de las «llaves maestras» que usan los sistemas corporativos para comunicarse entre sí de forma automática. Ese tipo de credenciales, si caen en manos equivocadas, pueden ser usadas después para intentar acceder a sistemas más profundos —incluidos, eventualmente, los que sí contienen datos de clientes— o para desplegar ataques de ransomware.
De hecho, el cofundador y director de tecnología de Hudson Rock, Alon Gal, planteó que <cite index=»20-1″>el análisis de los volcados de los entornos de desarrollo comprometidos permite entender con precisión qué información obtuvieron los atacantes antes de lanzar campañas de extorsión.</cite> Un dato preocupante adicional: reportes recientes indican que, cinco meses después del ataque original, buena parte de las credenciales robadas seguían siendo válidas en algunas organizaciones, lo que sugiere que no todas rotaron sus claves a tiempo.
La respuesta de la ANCI en Chile
En nuestro país, la Agencia Nacional de Ciberseguridad tomó conocimiento del caso el 12 de agosto y desde entonces activó un protocolo preventivo. En un comunicado enviado a medios nacionales, la entidad fue clara en un punto que conviene subrayar: se trata de una exposición posible, no de un incidente confirmado.
La ANCI explicó que, tras el análisis correspondiente, identificó un riesgo potencial para aquellas instituciones que hubieran descargado la aplicación comprometida, y que como medida preventiva notificó de inmediato a las organizaciones nacionales que podrían verse afectadas, entregándoles instrucciones para verificar si sus sistemas y credenciales estuvieron expuestos, junto con recomendaciones de mitigación.
Hasta la fecha de esta publicación, la agencia ha señalado que no ha identificado incidentes de impacto significativo derivados de esta vulnerabilidad, aunque continúa monitoreando activamente la situación.
Entre los dominios chilenos que figuran en la lista de posibles afectados —es decir, que pudieron haber estado expuestos, no que hayan sido efectivamente vulnerados— se encuentran sitios asociados a gob.cl (Gobierno de Chile), achs.cl, falabella.cl, nic.cl, udechile.cl, cmpc.cl, scd.cl, derco.cl, pedrodevaldivia.cl, tisal.cl, skc.cl, ione.cl, soho.cl, bdo.cl, bdoinventorysolutions.cl, datamart.cl, envision.cl y sumup.cl.
La diferencia entre «expuesto» y «hackeado»: por qué importa
Como asesor en esta materia, insisto en un punto que suele perderse en la cobertura de este tipo de eventos: estar en una lista de «potencialmente expuestos» no equivale a haber sido hackeado.
- Potencialmente expuesto significa que la institución usó, en algún momento, la herramienta o versión comprometida, por lo que existe la posibilidad —no la certeza— de que sus credenciales hayan sido capturadas por los atacantes.
- Hackeo confirmado con robo de datos implica que ya existe evidencia concreta de que alguien accedió sin autorización a un sistema y sustrajo información específica.
Chile se encuentra, según la propia ANCI, en el primer escenario: una alerta activada por prudencia y buena gestión de riesgo, no una confirmación de filtración masiva de datos ciudadanos. Es una distinción similar a la de un edificio que descubre que la cerradura que instaló tenía una falla de fábrica: no significa que alguien haya entrado a robar, pero sí obliga a revisar de inmediato si alguien lo hizo.
¿Afecta esto a los usuarios comunes?
Es la pregunta que más me hacen quienes siguen este tipo de noticias sin ser expertos en tecnología, y la respuesta honesta tiene matices.
En lo inmediato, este es principalmente un problema técnico interno entre las empresas afectadas y su infraestructura de desarrollo. No implica que, hoy, existan bases de datos de clientes de bancos, retailers o universidades circulando públicamente como consecuencia directa de este incidente puntual.
Sin embargo, no se puede minimizar el riesgo derivado. Las credenciales robadas son las llaves que abren la puerta a sistemas más sensibles. Si una organización no rotó sus claves de forma completa y oportuna —como advierten los propios investigadores que ocurrió en algunos casos meses después del ataque—, ese acceso podría eventualmente ser aprovechado para intentar vulnerar sistemas donde sí residen datos de clientes.
Mi recomendación como asesor es la misma que aplica siempre ante este tipo de alertas: no hay pánico que justificar, pero tampoco corresponde restarle importancia. Lo prudente es mantener las prácticas básicas de higiene digital —verificación en dos pasos, desconfianza ante correos o mensajes inesperados que pidan datos personales o claves, y atención a comunicados oficiales de las instituciones con las que se tiene relación— mientras las empresas afectadas completan sus procesos de auditoría y rotación de credenciales.
Una lección de fondo: la seguridad no creció al ritmo de la adopción de IA
Este episodio confirma una tendencia que como asesor en ciberseguridad vengo observando con preocupación: los ataques a la cadena de suministro de herramientas de código abierto vinculadas a inteligencia artificial se están volviendo más frecuentes, más sofisticados y dañinos.
La razón de fondo es estructural. La adopción de IA en las empresas avanzó a una velocidad que no siempre fue acompañada de la misma rigurosidad en materia de seguridad de las herramientas que la sostienen. Herramientas gratuitas y de código abierto como LiteLLM se volvieron piezas críticas de la infraestructura tecnológica global precisamente porque son fáciles de adoptar —lo que, al mismo tiempo, las convierte en un punto único de fallo: contaminar un solo eslabón de la cadena puede afectar a miles de organizaciones de manera simultánea, en vez de tener que atacarlas una por una.
Un detalle que agrava el diagnóstico: en este caso, la herramienta comprometida en primer lugar (Trivy) era, precisamente, un escáner de seguridad diseñado para detectar vulnerabilidades. Los atacantes convirtieron en arma la misma herramienta en la que las organizaciones confiaban para protegerse.
La recomendación de la industria hacia adelante es clara: fijar versiones específicas y verificadas de las dependencias que se usan en los procesos automáticos de desarrollo, auditar con regularidad los proveedores externos que forman parte de la cadena de construcción de software, y tratar la infraestructura de integración continua (CI/CD) como lo que realmente es: una superficie de ataque tan crítica como cualquier otro sistema expuesto a internet.
Omar Villegas Vega es asesor en Ciberseguridad y Prevención de Fraude Digital. Esta nota fue elaborada en base a información de la Agencia Nacional de Ciberseguridad (ANCI), Hudson Rock, CloudSEK y reportes de prensa nacional e internacional.