Una versión envenenada de LiteLLM convirtió una instalación rutinaria de Python en un ladrón de secretos criptográfico que buscaba billeteras, material de validación de Solana y credenciales de la nube cada vez que se iniciaba Python.
El 24 de marzo, entre las 10:39 UTC y las 16:00 UTC, un atacante que había obtenido acceso a una cuenta de mantenedor publicó dos versiones maliciosas de LiteLLM en PyPI: 1.82.7 y 1.82.8.
LiteLLM se comercializa a sí mismo como una interfaz unificada para más de 100 grandes proveedores de modelos de lenguaje, una posición que lo ubica por diseño dentro de entornos de desarrollador ricos en credenciales. PyPI Stats registra 96.083.740 descargas solo en el último mes.
Las dos construcciones conllevaban diferentes niveles de riesgo. La versión 1.82.7 requería una importación directa de litellm.proxy para activar su carga útil, mientras que la versión 1.82.8 instaló un archivo .pth (litellm_init.pth) en la instalación de Python.
La propia documentación de Python confirma que las líneas ejecutables en archivos .pth se ejecutan en cada inicio de Python, por lo que 1.82.8 se ejecutó sin ninguna importación. Cualquier máquina que lo tuviera instalado ejecutó código comprometido en el momento en que se lanzó Python.
Búsqueda futura estima 46.996 descargas en 46 minutosde los cuales 1.82,8 representan 32.464.
Además, contó 2337 paquetes PyPI que dependían de LiteLLM, y el 88% permitía el rango de versiones comprometidas en el momento del ataque.
La propia página de incidentes de LiteLLM advirtió que cualquier persona cuyo árbol de dependencia ingresara LiteLLM a través de una restricción transitiva no fijada durante la ventana debería tratar su entorno como potencialmente expuesto.
El equipo de DSPy confirmó que tenía una restricción LiteLLM de “superior o igual a 1.64.0” y advirtió que las nuevas instalaciones durante la ventana podrían haber resuelto las compilaciones envenenadas.
Creado para cazar criptomonedas
SafeDep ingeniería inversa de la carga útil hace que la segmentación criptográfica sea explícita.
El malware buscó archivos de configuración de billetera Bitcoin y archivos wallet*.dat, directorios de almacén de claves de Ethereum y archivos de configuración de Solana en ~/.config/solana.
SafeDep dice que el recopilador le dio a Solana un trato especial, mostrando búsquedas específicas de pares de claves de validación, claves de cuentas de votación y directorios de implementación de Anchor.
La documentación para desarrolladores de Solana establece la ruta predeterminada del par de claves CLI en ~/.config/solana/id.json. La documentación del validador de Anza describe tres archivos de autoridad fundamentales para la operación del validador y establece que el robo del retiro autorizado le da al atacante un control total sobre las operaciones y recompensas del validador.
Anza también advierte que la clave de retiro nunca debe colocarse en la máquina validadora.
SafeDep dice que la carga útil recopiló claves SSH, variables de entorno, credenciales de nube y secretos de Kubernetes en todos los espacios de nombres. Cuando encontró credenciales de AWS válidas, consultó a AWS Secrets Manager y al SSM Parameter Store para obtener información adicional.
También creó node-setup-*pods privilegiados en kube-system e instaló la persistencia a través de sysmon.py y una unidad systemd.
Para los equipos de criptografía, el riesgo compuesto va en una dirección específica. Un ladrón de información que recopila un archivo de billetera junto con la frase de contraseña, el secreto de implementación, el token de CI o la credencial del clúster del mismo host puede convertir un incidente de credencial en una fuga de billetera, una implementación de contrato malicioso o un compromiso del firmante.
El malware reunió exactamente esa combinación de artefactos.
| Artefacto objetivo | Ejemplo de ruta/archivo | Por qué es importante | Consecuencia potencial |
|---|---|---|---|
| Archivos de billetera Bitcoin | wallet*.datarchivos de configuración de billetera | Puede exponer el material de la billetera | Riesgo de robo de billetera |
| Almacenes de claves de Ethereum | ~/.ethereum/keystore | Puede exponer el material del firmante si se combina con otros secretos. | Compromiso del firmante/abuso de implementación |
| Par de claves CLI de Solana | ~/.config/solana/id.json | Ruta de clave de desarrollador predeterminada | Exposición a la cartera o a la autoridad de implementación |
| Archivos de autoridad del validador de Solana | par de claves del validador, claves de la cuenta de votos, retiro autorizado | Central para las operaciones y recompensas del validador | Compromiso de la autoridad del validador |
| Directorios de implementación de anclaje | Archivos de implementación relacionados con anclajes | Puede exponer los secretos del flujo de trabajo de implementación | Implementación de contratos maliciosos |
| Claves SSH | ~/.ssh/* | Abre el acceso a repositorios, servidores y bastiones. | Movimiento lateral |
| Credenciales en la nube | Entorno o configuración de AWS/GCP/Azure | Amplía el acceso más allá del host local | Acceso a la tienda secreta/adquisición de infraestructura |
| Secretos de Kubernetes | cosecha secreta en todo el racimo | Abre el plano de control y las cargas de trabajo. | Compromiso del espacio de nombres/difusión lateral |
Este ataque es parte de una campaña más amplia, como afirma LiteLLM. nota de incidente vincula el compromiso con el incidente anterior de Trivy, y perro de datos y snyk Ambos describen LiteLLM como una etapa posterior en una cadena TeamPCP de varios días que atravesó varios ecosistemas de desarrolladores antes de llegar a PyPI.
La lógica de orientación se ejecuta de manera consistente en toda la campaña: una herramienta de infraestructura rica en secretos proporciona un acceso más rápido al material adyacente a la billetera.
Posibles resultados de este episodio
El caso alcista se basa en la velocidad de detección y la ausencia, hasta ahora, de robo de criptomonedas confirmado públicamente.
PyPI puso en cuarentena ambas versiones aproximadamente a las 11:25 UTC del 24 de marzo. LiteLLM eliminó las compilaciones maliciosas, rotó las credenciales del mantenedor y se comprometió con Mandiant. PyPI actualmente muestra 1.82.6 como la última versión visible.
Si los defensores rotaron los secretos, auditaron litellm_init.pth y trataron los hosts expuestos como quemados antes de que los adversarios pudieran convertir los artefactos exfiltrados en explotación activa, entonces el daño queda contenido en la exposición de credenciales.
El incidente también acelera la adopción de prácticas que ya están ganando terreno. Trusted Publishing de PyPI reemplaza los tokens API manuales de larga duración con una identidad de corta duración respaldada por OIDC; aproximadamente 45.000 proyectos la habían adoptado en noviembre de 2025.
El incidente de LiteLLM involucró el abuso de las credenciales de liberación, lo que hizo mucho más difícil desestimar el caso para el cambio.
Para los equipos de criptografía, el incidente crea la urgencia de una separación de roles más estricta: los retiros de validadores en frío se mantienen completamente fuera de línea, los firmantes de implementación aislados, las credenciales de la nube de corta duración y los gráficos de dependencia bloqueados.
La rápida fijación del equipo de DSPy y la propia guía posterior al incidente de LiteLLM apuntan hacia construcciones herméticas como estándar de remediación.
El caso bajista se vuelve retrasado. SafeDep documentó una carga útil que exfiltró secretos, se propagó dentro de los clústeres de Kubernetes e instaló persistencia antes de la detección.
Un operador que instaló una dependencia envenenada dentro de un corredor de compilación o un entorno conectado a un clúster el 24 de marzo puede no descubrir el alcance completo de esa exposición durante semanas. Las claves de API, las credenciales de implementación y los archivos de billetera exfiltrados no caducan al ser detectados. Los adversarios pueden retenerlos y actuar más tarde.
Sonatype sitúa la disponibilidad maliciosa en “al menos dos horas”; La propia guía de LiteLLM cubre las instalaciones hasta las 16:00 UTC; y la marca de tiempo de cuarentena de FutureSearch es las 11:25 UTC.
Los equipos no pueden confiar únicamente en el filtrado de marcas de tiempo para determinar su exposición, ya que esas cifras no arrojan una luz clara.
El escenario más peligroso en esta categoría se centra en entornos de operadores compartidos. Un intercambio de cifrado, un operador de validación, un equipo de puente o un proveedor de RPC que instalara una dependencia transitiva envenenada dentro de un corredor de compilación habría expuesto un plano de control completo.
Los volcados secretos de Kubernetes entre espacios de nombres y la creación de pods privilegiados en el espacio de nombres del sistema kube son herramientas de acceso al plano de control diseñadas para el movimiento lateral.
Si ese movimiento lateral alcanzara un entorno donde hubiera material de validación caliente o semicaliente en máquinas accesibles, las consecuencias podrían variar desde el robo de credenciales individuales hasta el compromiso de la autoridad del validador.
La cuarentena de PyPI y la respuesta al incidente de LiteLLM cerraron la ventana de distribución activa.
Los equipos que instalaron o actualizaron LiteLLM el 24 de marzo, o que ejecutaron compilaciones con dependencias transitivas no fijadas que se resuelven en 1.82.7 o 1.82.8, deben tratar sus entornos como totalmente comprometidos.
Algunas acciones incluyen rotar todos los secretos accesibles desde las máquinas expuestas, auditar litellm_init.pth, revocar y volver a emitir credenciales de nube y verificar que no se pueda acceder a ningún material de autoridad de validación desde esos hosts.
El incidente de LiteLLM documenta la ruta de un atacante que sabía exactamente qué archivos fuera de la cadena buscar, tenía un mecanismo de entrega con decenas de millones de descargas mensuales y desarrolló persistencia antes de que alguien retirara las compilaciones de la distribución.
La maquinaria fuera de la cadena que mueve y protege las criptomonedas se encontraba directamente en la ruta de búsqueda de la carga útil.