Registro minuto a minuto de la respuesta al ataque a la cadena de suministro de LiteLLM

• Bitácora de respuesta minuto a minuto que detectó y analizó en tiempo real la infección del paquete malicioso LiteLLM 1.82.8 distribuido a través de PyPI
• La infección ocurrió durante una actualización automática de Cursor IDE, y el archivo litellm_init.pth se ejecutó provocando robo de credenciales e infección del sistema
• El código malicioso realizó acciones compuestas como recolección de claves SSH y credenciales de la nube, intentos de propagación en Kubernetes y creación de una bomba fork
• Se reportó de inmediato al equipo de seguridad de PyPI y a los mantenedores de LiteLLM, lo que derivó en el aislamiento del paquete y el registro de un CVE
• Herramientas de análisis de código impulsadas por IA como Claude Code cumplieron un papel clave en la detección del ataque y dejaron en evidencia la necesidad de reforzar la seguridad de la cadena de suministro del ecosistema de IA

---

Registro de respuesta al ataque a la cadena de suministro de LiteLLM

• La versión LiteLLM 1.82.8 fue identificada como un paquete malicioso distribuido por PyPI, y se documentó en una bitácora de respuesta minuto a minuto el proceso desde la detección de la infección hasta su aislamiento
• La infección ocurrió durante el proceso de actualización automática de Cursor IDE, y entre las dependencias instaladas mediante Claude Code y el gestor de paquetes uv, se ejecutó el archivo litellm_init.pth, provocando la infección del sistema
• El ataque consistió en acciones compuestas que incluían robo de credenciales, instalación de persistencia en el sistema, intentos de propagación en Kubernetes y una bomba fork (fork bomb)
• Se reportó de inmediato al equipo de seguridad de PyPI y a los mantenedores de LiteLLM, lo que derivó en el aislamiento del paquete y la emisión de un CVE
• Las herramientas de análisis de código basadas en IA desempeñaron un papel clave en la detección y el análisis en tiempo real de actividades maliciosas

Detección inicial y señales anómalas en el sistema

• Hacia las 11:13 UTC, se generaron más de 11,000 procesos de Python en una laptop con macOS, dejando el sistema prácticamente congelado
  • Se ejecutaban repetidamente comandos con la forma exec(base64.b64decode('...')), saturando la CPU y la memoria
  • Tras un cierre forzado y reinicio, no se encontraron rastros relacionados con persistencia
• Al principio se pensó que se trataba de un bucle no malicioso causado por un loop interno de Claude Code o por un error en un script de uv run
• Más tarde, mediante una captura de htop y los logs, se confirmó que un script de Python codificado en base64 se estaba ejecutando repetidamente

Identificación de la causa de la infección

• Hacia las 11:40, se encontró el archivo litellm_init.pth dentro de una herramienta de Python instalada y se confirmó que se trataba de actividad maliciosa
  • Los archivos .pth se ejecutan automáticamente al iniciar Python y funcionan en todos los procesos de Python
  • Recolectaban claves SSH, credenciales de la nube, contraseñas de bases de datos, variables de entorno e historial de shell, entre otros datos
  • Los datos recolectados se cifraban con RSA y se enviaban a https://models.litellm.cloud/
  • Se intentó instalar persistencia en ~/.config/sysmon/sysmon.py, pero el reinicio forzado interrumpió el proceso
• La infección ocurrió durante una actualización automática de Cursor IDE (10:58 UTC)
  • La extensión futuresearch-mcp-legacy descargó litellm 1.82.8 mediante uvx
  • Esa versión solo existía en PyPI y no tenía tag de release en GitHub
  • La hora de carga a PyPI fue 10:52 UTC, por lo que se confirmó que se distribuyó justo antes de la infección

Estructura del código malicioso

• Fase 1 (litellm_init.pth): se ejecuta automáticamente al iniciar Python, decodifica una carga útil en base64 y luego la ejecuta
• Fase 2: incluye una clave pública RSA para cifrar los datos robados
• Fase 3 (B64_SCRIPT): realiza la recolección y el envío efectivos de credenciales
• Instalación de persistencia: intentó registrar sysmon.py como un servicio de systemd
• Código de propagación en Kubernetes: intentó crear pods privilegiados en cada nodo usando la imagen alpine:latest
• Causa de la bomba fork: la llamada subprocess.Popen([sys.executable, "-c", ...]) volvió a ejecutar el archivo .pth también en los procesos hijo, provocando un bucle infinito

Alcance del daño y medidas de respuesta

• Credenciales expuestas

  • Claves SSH, credenciales de GCloud y Kubernetes, claves API dentro de archivos .env, y contraseñas de Supabase, ClickHouse y Grafana, entre otras
  • Acciones inmediatas recomendadas
  1. Rotar todas las credenciales SSH y de la nube
  2. Reemitir las claves secretas dentro de .env y .mcp.json
  3. Eliminar la caché de ~/.cache/uv
  4. Reportarlo al equipo de seguridad de PyPI ([e-mail]) y a los mantenedores de LiteLLM

• Resultado de la revisión del clúster de Kubernetes

  • No se encontraron pods maliciosos (node-setup-*, sysmon)
  • Al haberse ejecutado en un entorno macOS, la propagación dentro del clúster falló
  • Aun así, debido a la posible exposición de ~/.kube/config, es necesario rotar las credenciales

Respuesta pública y en PyPI

• A las 11:58 UTC, tras descargar litellm 1.82.8 desde PyPI dentro de un entorno Docker aislado, se volvió a confirmar la presencia del archivo .pth malicioso
• Se reportó de inmediato al equipo de seguridad de PyPI y al repositorio BerriAI/litellm
  • Después se registró como PYSEC-2026-2 (CVE)
• A las 12:01 UTC, se redactó y publicó en el blog de FutureSearch una entrada pública sobre el ataque a la cadena de suministro
  • El PR se redactó y fusionó en 3 minutos
• A las 12:04 UTC, se propuso compartirlo en las comunidades r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning y r/devops
  • Con ello se buscó inducir una respuesta rápida de las comunidades de Python y seguridad

Significado del incidente

• La herramienta de análisis de código basada en IA Claude Code identificó actividad maliciosa en tiempo real y generó advertencias antes de la intervención de investigadores de seguridad
• Este caso mostró un ataque a la cadena de suministro dirigido directamente al ecosistema de desarrolladores de IA, subrayando la necesidad de reforzar la seguridad de las cuentas de PyPI y la verificación de actualizaciones automáticas
• También demostró que las herramientas de IA pueden usarse no solo como apoyo al desarrollo, sino también para la detección y respuesta automatizada ante amenazas cibernéticas

[GN⁺]

Comentarios en Hacker News

• Soy el desarrollador que descubrió y reportó primero la vulnerabilidad de litellm
  Compartí el registro de análisis en tiempo real tal como ocurrió
  Claude me fue guiando paso a paso sobre a quién contactar y en qué orden actuar, así que fue una experiencia de gran ayuda incluso para alguien que no es experto en seguridad
  Me pregunto si que personas no especialistas descubran y reporten vulnerabilidades de esta forma ayuda a la comunidad de seguridad o si más bien genera confusión

  • Como alguien que trabaja en la industria de seguridad, me impresionó que lo hayas descubierto con ayuda de Claude
    Aun así, la parte de “apenas volví a abrir Cursor se ejecutó el paquete malicioso” sí se ve algo peligrosa
    En cuanto surgió la sospecha, lo primero debió ser aislar el dispositivo y contactar al equipo de seguridad
  • Yo también descubrí este problema casi al mismo tiempo y de la misma manera
    Si el archivo .pth no hubiera actuado como una fork bomb, quizás se habría detectado mucho más tarde
    Fue una buena decisión preguntarle a Claude por la ruta de contacto
    Como no conocía los contactos relacionados con PyPI, le envié un correo al maintainer y también lo publiqué en Hacker News
    Creo que, incluso sin pertenecer a la comunidad de seguridad, cualquiera debería poder reportar una vulnerabilidad grave como esta
  • Tengo experiencia administrando programas de divulgación de vulnerabilidades en varias empresas
    La mayoría de los problemas vienen de gente que busca dinero y afirma que cualquier cosa es una vulnerabilidad
    Pero tu reporte era de alta calidad, y algo así sube de inmediato en la prioridad de parchado
    Si se podía resolver sin interrumpir el negocio, se actuaba de inmediato, y si era grave, se reportaba enseguida al CISO o al CTO
  • Buen texto. Sentí que Claude fue especialmente útil en una situación así
    Gracias a tu reporte, básicamente se evitó un incidente mayor
    Nosotros también resumimos el tema en dos publicaciones del blog
    post del blog de grith.ai
  • Últimamente he oído que los proyectos open source la están pasando mal por la avalancha de reportes de vulnerabilidades y PRs
    Pero este caso me parece un buen ejemplo de cómo, con ayuda de la IA, el análisis de la causa y el reporte fueron mucho más rápidos

• Es la primera vez que veo que mi herramienta claude-code-transcripts se incrusta como datos dentro de un post de blog
  Normalmente la compartía como página HTML de Gist, así que este uso me parece interesante

  • En nuestra empresa también la usamos bastante
    Intentamos adaptarla al estilo del blog y fracasamos, pero eso me hizo valorar de nuevo la importancia de la experiencia base
    Claude va raspando logs como si escaneara toda mi computadora, así que sentí que hace falta un sistema automático de redacción de logs
  • Compartir información entre sesiones de Claude Code sigue siendo un gran problema
    Es especialmente incómodo al colaborar con el equipo durante un debugging urgente

• Peticiones como “¿puedes mostrar el contenido del script malicioso sin ejecutarlo?” son peligrosas
  Los agentes LLM no tienen noción de responsabilidad, así que si por error emiten un comando de ejecución, eso puede terminar en un incidente grave
  Al descargar archivos desde PyPI, hay que hacerlo siempre en un entorno sandbox

  • A mí también me preocupaba eso
    Cuando te dicen “no lo hagas”, uno tiende a obsesionarse todavía más con eso

• Escuché que PyPI soporta digital attestation, pero me da curiosidad si este paquete estaba firmado
  documentación de PyPI Trusted Publishers

• Creo que registros de paquetes como GitHub, npm y PyPI deberían ofrecer un firehose de eventos para análisis de seguridad en tiempo real
  Un escáner automático habría detectado este ataque de inmediato

  • PyPI ya ofrece algo así
    Los socios de seguridad pueden escanear paquetes y reportarlos mediante una API por invitación
    Ver post del blog de PyPI
  • Yo también introduje un dependency cooldown después de este incidente
    texto relacionado
    La idea es darles tiempo a los escáneres automáticos para detectar anomalías como archivos .pth
  • npm ofrece un feed de cambios de paquetes, y GitHub opera un firehose de eventos y un dataset público en BigQuery
  • Creo que proporcionar este tipo de infraestructura debería convertirse en una obligación legal
    El daño económico puede ser enorme, y solo los afectados por la infección de litellm ya superan las 47 mil personas

• La parte de “post de blog escrito, PR y merge en menos de 3 minutos” fue lo más impactante
  Va más rápido de lo que toma leerlo, y eso da ansiedad

• Si no hubiera existido la fork bomb de 11 mil procesos, quizá este ataque habría permanecido oculto por mucho más tiempo

  • A mí también se me congeló el sistema justo al instalar el paquete, así que me salvé de la infección
    Si hubieran ralentizado la bomba, el daño habría sido mucho mayor
  • Tal vez deberíamos llamarlo un gusano de internet de esta generación

• Hay dos formas en que una gran empresa puede ejecutar código open source no confiable

  1. Como hace Google, compilar todo directamente desde el código fuente
  2. Obtener todo solo desde un mirror interno de la empresa y verificar la firma de todos los paquetes
     En la práctica, (1) es lo más seguro
     Para pymes o personas individuales, la mejor defensa es fijar dependencias (pinning) y dejar suficiente tiempo de espera
     Con Bazel se puede acercar uno a (1), pero la mayoría no tiene más opción que depender de fuentes externas

• Que PyPI haya puesto el paquete en cuarentena apenas 30 minutos después del reporte fue una respuesta realmente rápida

  • Hay mucha preocupación por lo vulnerables que son a ataques de cadena de suministro, pero esta vez me parece un caso bastante bien manejado

• Una de las mejores cosas de la IA/LLM es la democratización de la ingeniería inversa
  Antes era una habilidad difícil de aprender y poco gratificante, pero ahora la IA te va marcando el rumbo

  • Pero esto no fue ingeniería inversa, sino un problema básico de administración de sistemas
    El patrón exec(base64.b64decode(...)) se usa con frecuencia cuando herramientas de Python entregan código,
    pero en general cualquier código que se ejecute desde /tmp, /var/tmp o /dev/shm debería verse como muy sospechoso
    Si hubiera habido una herramienta de monitoreo de red como Lulu o LittleSnitch, probablemente habría bloqueado el tráfico anómalo
    Eso sí, subir binarios a Claude para que los analice es otro riesgo distinto
  • A mí también me interesó viendo videos de CTF, pero en el trabajo real casi nunca toca encontrarse con algo así directamente