-
La versión infectada estuvo disponible menos de una hora y fue detectada por accidente.
-
El malware se propagaba a cualquier proyecto que usara LiteLLM como dependencia.
Este 24 de marzo, la versión 1.82.8 de LiteLLM fue publicada en PyPI, el repositorio oficial de paquetes de Python, con un código malicioso diseñado para robar credenciales financieras, claves de wallets de criptomonedas y accesos a infraestructura cloud. La versión infectada estuvo disponible menos de una hora antes de ser detectada y retirada, según explicó la firma de investigación FutureSearch.
Según la firma, el ataque no requirió ninguna acción adicional por parte del usuario. Bastó con actualizar la librería LiteLLM mientras la versión infectada estuvo activa para que el código malicioso se ejecutara automáticamente.
Conforme al análisis técnico de FutureSearch, el atacante obtuvo las credenciales del mantenedor de LiteLLM y las usó para publicar la versión infectada directamente en PyPI. La señal de alerta se levantó luego de constatar que esta nueva versión no figuraba en el repositorio oficial de GitHub del proyecto, donde normalmente se registran todos los lanzamientos antes de publicarse.
Al momento en que la comunidad abrió un reporte público en GitHub para alertar sobre el ataque, el propietario del repositorio lo cerró sin dar explicaciones ni reconocer el problema, explican desde FutureSearch.
Poco después, cientos de cuentas automatizadas inundaron la discusión con mensajes para ocultar la alerta entre miles de publicaciones. Según el reporte de FutureSearch, esa reacción sugiere que el atacante no solo había tomado control del paquete publicado en PyPI, sino también de la cuenta del propio autor de LiteLLM en GitHub.
CriptoNoticias pudo constatar que al momento de la redacción, el repositorio de LiteLLM estaba disponible:
LiteLLM es una biblioteca de código abierto escrita en Python que actúa como traductor universal entre aplicaciones de inteligencia artificial y más de 100 proveedores de modelos de lenguaje, entre ellos OpenAI, Anthropic, Google y Amazon Web Services (AWS).
En lugar de escribir código distinto para cada proveedor, los desarrolladores usan LiteLLM como capa intermedia que gestiona todas las conexiones con el mismo formato. Con 97 millones de descargas mensuales, es una de las herramientas más usadas en el ecosistema de IA: empresas como Netflix, Character.ai y cientos de startups la integran en sus productos.
Además, un factor que amplificó el riesgo fue la propagación transitoria. LiteLLM no solo se instala directamente: es una dependencia de decenas de proyectos populares. Eso significa que un desarrollador que instalara otro proyecto que dependiera de LiteLLM también quedaba expuesto sin saberlo ni haberlo instalado explícitamente.
¿Cómo funcionaba el malware?
El código malicioso operaba en tres etapas:
- La primera era de recolección: un script recorría la máquina infectada en busca de archivos de wallets de criptomonedas, contraseñas de bases de datos, credenciales AWS, archivos ‘env’ con claves de API, historial de terminal y cualquier archivo que coincidiera con patrones comunes de secretos. También ejecutaba comandos para extraer variables de entorno y consultaba los servicios de metadatos de instancias cloud para obtener credenciales adicionales.
- La segunda etapa era de exfiltración: toda la información recolectada se cifraba y se enviaba a un dominio externo no relacionado con la infraestructura legítima de LiteLLM.
- La tercera etapa apuntaba a persistencia y movimiento lateral: si la máquina infectada tenía acceso a un cluster de Kubernetes, el malware leía todos los secretos del cluster e intentaba crear pods privilegiados en cada nodo para instalar un backdoor permanente. En máquinas locales, hacía lo mismo mediante un servicio del sistema.
De acuerdo con el reporte de FutureSearch, la detección del malware en LiteLLM fue accidental, ya que ese programa malicioso tenía un error. Al ejecutarse, generaba un proceso que se replicaba exponencialmente hasta agotar la memoria RAM y hacer colapsar la máquina.
Un ingeniero de FutureSearch notó el problema mientras LiteLLM se cargaba como dependencia de un plugin dentro del entorno de desarrollo Cursor. «Uno de nuestros ingenieros notó el problema y usó Claude Code para identificar la causa raíz», señala el reporte. Sin ese error, el malware podría haber operado sin ser detectado durante días o semanas.
«Lo más aterrador del software moderno»
Andrej Karpathy, cofundador de OpenAI y ex director de inteligencia artificial de Tesla, escribió el 24 de marzo: «Los ataques a la cadena de suministro son básicamente lo más aterrador que existe en el software moderno. Cada vez que instalas cualquier dependencia puedes estar jalando un paquete envenenado en cualquier punto profundo de su árbol de dependencias».
Karpathy fue más allá del evento puntual y cuestionó el modelo de desarrollo basado en dependencias: «Esto me ha hecho cada vez más reacio a las dependencias, prefiriendo usar modelos de lenguaje para copiar funcionalidad cuando es lo suficientemente simple y posible».
El término que usó Karpathy para describir el modelo alternativo fue «yoink»: copiar o reutilizar código simple con ayuda de modelos de lenguaje en lugar de agregar una dependencia externa. La idea no es nueva, pero el ataque a LiteLLM le dio un argumento concreto y reciente para sostenerla.
Un patrón que se repite en el ecosistema de IA
El incidente de LiteLLM no es un caso aislado. El pasado 16 de marzo, como lo notificó CriptoNoticias, 360 Security, la mayor empresa de ciberseguridad de China, expuso por error el certificado SSL y la clave privada RSA de uno de sus dominios en el instalador público de su nuevo asistente de IA, 360 Safety Lobster.
La clave estuvo disponible para descarga durante dos días, tiempo suficiente para que actores maliciosos la indexaran para ataques de intermediario, es decir, interceptación de tráfico cifrado entre usuarios y servidores legítimos de la empresa.
En ambos casos el vector fue el mismo: código distribuido públicamente en entornos de lanzamiento acelerado, sin auditoría de seguridad suficiente. La diferencia es que el incidente de 360 Security fue un error operativo, mientras que el de LiteLLM fue un ataque deliberado. Lo que comparten es el contexto: la velocidad de despliegue de herramientas de IA está superando los controles de seguridad.
