¿Qué sucedió? El ataque a Mercor y LiteLLM en 48 horas

LiteLLM es una librería Python open source que sirve como proxy unificado para llamar a diferentes modelos de lenguaje (OpenAI, Anthropic, Google, Cohere) con una sola interfaz. La usan miles de empresas para no estar amarradas a un solo proveedor de IA. El problema: fue comprometida.

Entre las 10:39 y las 16:00 UTC del 24 de marzo, TeamPCP logró subir versiones maliciosas 1.82.7 y 1.82.8 a PyPI (el repositorio oficial de paquetes Python). Nadie se dio cuenta hasta tres días después. En esas 48 horas, millones de desarrolladores descargaron una librería que no solo llamaba a LLMs, sino que también robaba sus secretos más valiosos.

Según TechCrunch, Mercor fue “uno de miles de empresas” afectadas. El extortionista Lapsus$ reclama haber robado 4 terabytes de datos de Mercor, aunque no está 100% claro si los datos llegaron a su poder directamente del ataque a LiteLLM o de otra forma (spoiler: probablemente el malware fue la puerta).

Supply chain attack: cómo un atacante se cuela en millones de desarrolladores

Si atacas un sitio web directamente, lo notan. Si atacas una app en el telefónico de un usuario, solo ese usuario se entera. Pero si inyectás malware en un componente que descargue medio mundo, de repente todos están comprometidos sin saberlo. Eso es un supply chain attack, y es casi imposible defenderlo una vez que estás adentro.

El ataque tuvo estructura de tres pasos:

Paso 1 — Robar credenciales de PyPI. TeamPCP compromete Trivy, una herramienta de seguridad que usan desarrolladores para scanear vulnerabilidades en containers. Con acceso a Trivy, roban credenciales guardadas en el ambiente de los mantenedores. Entre ellas, el token PyPI del equipo de LiteLLM. Eso es equivalente a robar la contraseña del cajero automático: el atacante ahora puede publicar paquetes como si fuera el equipo oficial.

Paso 2 — Subir malware a PyPI directamente. Con las credenciales robadas, TeamPCP sube LiteLLM 1.82.7 y 1.82.8 a PyPI sin pasar por GitHub, sin triggerar CI/CD, sin pipeline de seguridad. Es como que alguien entrara al almacén por la puerta de atrás y metiera botellas falsificadas en las estanterías de verdad. Millones de desarrolladores que hacen pip install litellm se llevan el malware sin cuestionarse nada.

Paso 3 — Validar credenciales robadas y exfiltrar datos. Una vez dentro de la máquina de un desarrollador o servidor de producción, el malware cosecha secretos. Lo interesante es que el ataque no fue “genérico” — según análisis de Sonatype, el malware detecta dónde está corriendo (¿es Kubernetes? ¿una máquina local? ¿una función Lambda?) y adapta su comportamiento para extraer exactamente lo que hay de valor en ese ambiente.

El malware de TeamPCP: qué robaba exactamente

Ojo con esto: el malware no hacía una cosa. Tenía tres estadios progresivos, cada uno más invasivo que el anterior (según análisis de ReversingLabs y Trend Micro).

Estadío 1 — Credential harvesting básico. Se ejecutaba cada vez que Python iniciaba una sesión, barriendo variables de ambiente en busca de secretos: API keys de OpenAI, Anthropic, AWS, GCP, Azure, Kubernetes configs, credenciales de Docker, contraseñas de bases de datos, wallets de criptografía, tokens de Slack. Todo eso se guardaba en un archivo oculto y se mandaba al servidor de control de TeamPCP. Para una empresa como Mercor que trabaja con OpenAI y Anthropic, eso significaba credenciales de entrenamiento de modelos expuestas. Cubrimos ese tema en detalle en recomendaciones de seguridad contra ataques.

Estadío 2 — Lateral movement en Kubernetes. Si el malware detectaba que estaba corriendo dentro de un cluster de Kubernetes (chequeaba la variable KUBERNETES_SERVICE_HOST), ejecutaba un segundo módulo: buscaba todos los secrets almacenados en el cluster, exfiltrraba credenciales de APIs externas, certificados TLS, y (esto es lo turbio) creaba pods backdoor en múltiples nodos para mantener acceso persistente incluso si el desenvolvedor sacaba el deploy comprometido.

Estadío 3 — Persistent backdoor. Instalaba un agente que se ejecutaba en /root/.config/sysmon/ (ruta poco monitoreada) para mantener acceso de largo plazo, descargando payloads adicionales bajo demanda. Ese tipo de backdoor es lo que hace que un ataque pase de ser “se detectó y lo sacamos” a “nos comprometieron por tres meses sin darnos cuenta”.

Mercor: quién es y por qué fue un objetivo valioso

Mercor no es una startup random. Fundada en 2023, se especializa en IA recruiting: contrata especialistas domésticos (científicos, doctores, abogados) desde mercados como India para que entrenen y evalúen modelos de lenguaje. Trabaja directamente con OpenAI y Anthropic. En octubre de 2025 levantó USD 350 millones en serie C a valuación de $10 mil millones (los inversores fueron liderados por Felicis Ventures). Facilita más de $2 millones en pagos diarios a sus contratistas.

¿Por qué fue un objetivo tan valioso para TeamPCP? Porque Mercor es un puente directo a tres cosas que los atacantes quieren:

Primero: credenciales de OpenAI y Anthropic. Si los servidores de Mercor tienen API keys activas para llamar a GPT-4 o Claude, eso es oro puro. No necesitás crackear las contraseñas de OpenAI; simplemente usás la API key de Mercor para quemar su presupuesto, entrenar modelos competidores, o recolectar datos de testing sin que OpenAI sepa que fue un ataque.

Segundo: datos de especialistas. Mercor tiene información sobre quiénes son los doctores, científicos y expertos que entrenan los modelos de IA. Direcciones IP, horarios de trabajo, archivos de proyectos, URLs internas. Todo lo que necesitás para hacer spear-phishing dirigido, extorsión, o acceso a cuentas personales de esos especialistas (muchos reutilizan contraseñas entre el trabajo y sus cuentas personales).

Tercero: información sobre cómo entrena IA OpenAI y Anthropic. Los flujos de trabajo, las herramientas internas, los datasets usados para evaluación. Es competencia industrial sensible.

Los 4TB robados: qué información sensible perdió Mercor

Lapsus$ reclama haber sacado 4 terabytes de Mercor. Eso no es “algunos documentos confidenciales”. Es toda la casa. Según los reportes, incluye: En cómo proteger las integraciones con LLMs profundizamos sobre esto.

Bases de datos completas. Código fuente de las herramientas de evaluación de IA. VPN credentials. Toda la data de Slack (mensajes privados, canales internos, compartir de archivos). Sistema de ticketing. Videos de conversaciones entre sistemas IA y contratistas. Formularios de onboarding con información personal de especialistas. Registros de pagos y transferencias bancarias. Configuración de infraestructura en AWS y GCP.

Para Mercor, lo más crítico es que las credenciales de OpenAI y Anthropic fueron expuestas. Eso no es un problema teórico: si el malware estuvo vivo durante tres días antes de detección, TeamPCP tuvo 72 horas para explorar, copiar datos, y validar qué información era valiosa (y probablemente ya haya empezado a exfiltrar información adicional una vez que tuvo los primeros secretos).

El alcance real: no es solo Mercor

Acá está el tema que no cerraba: ¿por qué TechCrunch dice “uno de miles de empresas afectadas” si solo hablan de Mercor? Porque LiteLLM no es una librería de uso marginal.

Según Snyk, LiteLLM se descargaba millones de veces por día desde PyPI. Entre el 24 y 27 de marzo, cualquiera que haya hecho pip install litellm sin especificar versión exacta se llevó automáticamente la maliciosa. Eso incluye:

Empresas de IA que usan LiteLLM para abstraer múltiples proveedores. Equipos de investigación académica. Startups de IA. Consultorías que construyen soluciones con LLMs. Equipos internos de compañías Fortune 500. Básicamente, cualquiera que haya hecho un deploy entre el 24 y 27 de marzo sin pinned versions.

Mandiant estima 1000+ ambientes SaaS impactados activamente. Threat hunters en comunidades de seguridad (vx-underground) estiman 500.000 máquinas con exfiltración de data confirmada. No todos van a tener credenciales jugosas como Mercor, pero todos están en riesgo.

Cómo defenderse: pasos concretos que podes implementar hoy

Si usás LiteLLM, estos son los pasos que tenés que hacer YA:

1 — Revisar qué versión instalaste. Meterle un vistazo a tu requirements.txt, Pipfile, o poetry.lock. Si tenés LiteLLM 1.82.7 o 1.82.8 (especialmente sin versión pinned, tipo litellm>=1.80.0), estás comprometido. Si lo usás en producción, el malware lleva casi dos semanas ahí.

2 — Asumir que tus secretos fueron robados. No es paranoia. El malware cosecha credenciales. Tenés que rotar YA:

• API keys de OpenAI, Anthropic, Google, cualquier proveedor de LLM
• Claves SSH privadas (si están en la máquina donde corre el código)
• Credenciales de AWS, GCP, Azure
• Tokens de Kubernetes
• Credenciales de Docker registry
• Contraseñas de bases de datos
• Tokens de GitHub, Slack, cualquier servicio crítico

3 — Revisar logs de acceso anómalo. Revisá CloudTrail (si usás AWS), GCP Audit Logs (si usás Google Cloud), o Activity Log (si usás Azure). Filtrá por acceso después del 24 de marzo. Buscá API calls anormales, creación de usuarios nuevos, acceso fuera de horario, o cambios en permisos. Si ves algo raro, escalá a tu equipo de seguridad o incident response. Sobre eso hablamos en seguridad en el acceso a APIs de modelos.

4 — Actualizar a LiteLLM 1.83.0+. Según la documentación oficial, la versión 1.83.0 introducción un sistema de CI/CD v2 mejorado que incluye validación de integridad de paquetes y protecciones contra inyección de malware en el build pipeline. No es una garantía de seguridad eterna, pero es mejor que quedarte en malware activo.

5 — Implementar secret scanning en tu CI/CD. Herramientas como Snyk, GitHub Advanced Security, o TruffleHog escanean tu código en busca de credenciales hardcodeadas. Si usás DevOps, agregá un paso en el pipeline que rechace cualquier commit con secretos detectados. Eso no te salva de este ataque, pero previene que vuelva a pasar.

6 — Usar version pinning explícito. En vez de litellm>=1.82.0, escribí litellm==1.83.2 (versión exacta). Sí, significa que tenés que estar atento a updates. Pero también significa que no agarrás accidentalmente una versión maliciosa si el atacante logra contaminar PyPI de nuevo.

Por qué pasó esto: las grietas de la seguridad en open source

Open source es fantástico. No hay que pagar, el código está disponible, miles de ojos lo ven. Excepto que esos miles de ojos miran solo si les interesa, y la mayoría no tiene incentivo de meterle seguridad a un proyecto que no les paga. El mantenedor de LiteLLM probablemente trabaja en eso en su tiempo libre o con presupuesto limitado.

TeamPCP simplemente comprendió eso: si quiero robar credenciales de miles de empresas simultáneamente, no ataco a cada una. Ataco el componente que usan todas. Y si ese componente no tiene presupuesto de seguridad, la puerta está abierta.

La raíz del problema es que los mantenedores de proyectos críticos como LiteLLM no tienen protecciones simples:

• Two-factor authentication requerido en PyPI? No estaba.
• Signaturas criptográficas de cada paquete? Opcional.
• Hardware security keys? Demasiado caro si no tenés presupuesto.
• Auditorías de seguridad? Requieren dinero.
• Proceso de CI/CD robusto que valide integridad del código? Depende del recurso.

Es como tener una casa con puertas sin cerraduras porque el dueño no tiene presupuesto para cerrajería, pero dentro guarda valuables de todas las casas del barrio.

Errores comunes después de un ataque así

Primer error: pensar que no te pasó porque “recién me entero hoy”. El malware estuvo vivo desde el 24. Si instalaste o deployaste entre el 24 y 27 de marzo, te afecta. No importa que recién TechCrunch publique sobre esto el 31. Asumí compromiso inmediato.

Segundo error: “roté las credenciales una sola vez y listo”. Si el malware corre en un pod de Kubernetes o en una Lambda, y no destruís ese pod/función, el malware sigue corriendo y roba las nuevas credenciales que rotaste. Tenés que primero identificar y destruir todos los procesos comprometidos antes de rotar. Eso requiere desmontaje de la infraestructura, no solo cambiar contraseñas. Para más detalles técnicos, mirá protección de credenciales en servicios IA.

Tercer error: confiar en que “el proveedor de LLM va a detectar uso anómalo”. OpenAI y Anthropic no monitoreán acceso por API key tan detalladamente como te gustaría. Si TeamPCP entra con tus credenciales y hace 100 llamadas adicionales, capaz no lo ves hasta que recibás la factura. Asumí que ya pasó.

Preguntas Frecuentes

¿Qué es un supply chain attack en código abierto?

Un ataque a la cadena de suministro es cuando comprometes un componente que miles de otras cosas dependen. En vez de atacar a cada usuario final (imposible), atacas el centro de distribución. Con LiteLLM, el atacante no necesitaba entrar a servidores de Mercor directamente. Sabía que Mercor y miles de otras empresas iban a descargar LiteLLM, así que inyectó malware ahí. Fue descargado automáticamente.

¿Cómo sé si yo fui afectado?

Buscá LiteLLM 1.82.7 o 1.82.8 en tu proyecto. Si está ahí, fuiste afectado. Si usás contenedores, revisá tu imagen base. Si no sabés exactamente qué versión instalaste (porque pusiste litellm>=1.80.0 sin pinning), asumí que descargaste la maliciosa durante la ventana 24-27 marzo.

¿El malware me roba la contraseña de OpenAI directamente?

No. No necesita tu contraseña. OpenAI usa API keys, que son como tokens de acceso. Si guardás tu API key como variable de ambiente (práctica común), el malware la cosecha. Con esa key puede hacer llamadas a la API sin conocer tu contraseña jamás.

¿Por qué no lo detectó Snyk / GitHub Advanced Security?

¿Esto puede pasar con otros proyectos open source?

Conclusión

Fuentes

• Mercor says it was hit by cyberattack tied to compromise of open source LiteLLM project — TechCrunch
• Security Update March 2026 — LiteLLM Official Docs
• Compromised LiteLLM PyPI Package Delivers Multi-Stage Credential Stealer — Sonatype
• Poisoned Security Scanner Backdooring LiteLLM — Snyk
• Mercor Confirms Security Incident Tied to LiteLLM — The Record