Un paquete envenenado de PyPI se infiltró en la startup de entrenamiento de IA Mercor — y expuso 4 TB de datos de contratistas a Lapsus$

El 31 de marzo de 2026, Mercor — una startup de $10 mil millones que brinda servicios de etiquetado de datos, anotación y gestión de contratistas a OpenAI, Anthropic, Meta y Google — confirmó una brecha que los investigadores de seguridad consideran uno de los ataques más importantes a la cadena de suministro contra la industria de la IA hasta la fecha. Se exfiltraron aproximadamente 4 TB de datos: 939 GB de código fuente de la plataforma, 211 GB de registros de bases de datos de usuarios y aproximadamente 3 TB de contenido de buckets de almacenamiento que incluyen escaneos de pasaportes de contratistas, números de Seguro Social, documentos de verificación de identidad y grabaciones de video de entrevistas técnicas. El grupo que reclama responsabilidad es Lapsus$, que ha listado los datos robados para subasta en su mercado de la dark web. Ya se han presentado cinco demandas colectivas contra Mercor por parte de contratistas afectados.

La cadena de ataque: tres saltos desde el escáner hasta la producción

Lo que hace técnicamente distintiva esta brecha es la ruta de ataque. No fue una intrusión directa en los sistemas de Mercor. Fue un ataque de cadena de suministro de tres etapas que se movió a través del ecosistema de herramientas de código abierto antes de llegar a cualquier entorno de producción.

Salto 1 — 19 de marzo: Trivy está comprometido. Trivy es un escáner de vulnerabilidades de código abierto ampliamente utilizado, mantenido por Aqua Security e integrado en pipelines de CI/CD en miles de organizaciones. El grupo atacante, operando bajo el nombre TeamPCP, obtuvo acceso de escritura a los artefactos de lanzamiento de Trivy. El vector inicial exacto hacia Trivy no se ha divulgado públicamente, pero el resultado fue que TeamPCP tuvo la capacidad de influir en lo que Trivy ejecutaba durante sus ejecuciones de escaneo.

Salto 2: Extracción de credenciales de CI/CD de LiteLLM. LiteLLM — una biblioteca popular de Python de código abierto que proporciona una puerta de enlace API unificada para llamar a diferentes proveedores de modelos de lenguaje grandes — usaba Trivy como parte de su pipeline automatizado de CI/CD para escanear contenedores y dependencias en busca de vulnerabilidades conocidas. Críticamente, la configuración de CI/CD de LiteLLM no fijaba Trivy a un hash de versión específico. Descargaba Trivy sin bloqueo de versión, lo que significaba que cuando Trivy comprometido se ejecutaba dentro del entorno de compilación de LiteLLM, tenía acceso a los secretos del pipeline: credenciales de publicación de PyPI, tokens de repositorio y variables de entorno. TeamPCP extrajo esas credenciales a través del escáner comprometido durante una ejecución de compilación rutinaria.

Salto 3 — 27 de marzo: Versiones maliciosas de LiteLLM en PyPI. Armado con las credenciales de publicación de PyPI de LiteLLM, TeamPCP subió dos lanzamientos maliciosos: litellm==1.82.7 y litellm==1.82.8. Los paquetes eran funcionalmente idénticos a los lanzamientos legítimos en su comportamiento superficial — pasaban pruebas básicas de importación y podían enrutar llamadas API de LLM normalmente. La carga útil inyectada se ejecutaba al importar o al primer uso, estableciendo conectividad saliente y exfiltrando variables de entorno, claves API y rutas del sistema de archivos accesibles al proceso en ejecución. Cualquier organización que descargara estas versiones a un entorno de producción — mediante pip install litellm sin fijar versión, o mediante automatización de actualización de dependencias — ejecutó código controlado por atacantes.

Mercor fue una de esas organizaciones. Dado que LiteLLM se utiliza en todo el ecosistema de desarrollo de IA como infraestructura para construir aplicaciones que llaman a GPT-4, Claude, Gemini y otros modelos, la ventana de exposición fue amplia. La plataforma de Mercor, que gestiona flujos de trabajo de contratistas, almacena documentos de identidad de contratistas y maneja datos de entrenamiento propietarios para los principales laboratorios de IA, era un objetivo de alto valor dentro de esa ventana.

Qué fue robado

Los datos exfiltrados de Mercor se dividen en tres categorías, cada una con perfiles de riesgo distintos:

• 939 GB de código fuente de la plataforma. Esto incluye el sistema de gestión de contratistas de Mercor, las herramientas de evaluación y las interfaces a través de las cuales los contratistas interactúan con las tareas de entrenamiento de IA. Para los clientes de Mercor — OpenAI, Anthropic, Meta, Google — la exposición de este código revela potencialmente cómo están estructurados sus pipelines de entrenamiento en la capa de interfaz del contratista, qué tipos de tareas se enrutan a través de Mercor y qué mecanismos de control de calidad están implementados.
• 211 GB de registros de bases de datos de usuarios. Esto incluye perfiles de contratistas, metadatos de cuentas, registros de pagos y correspondencia interna. El esquema exacto no se ha confirmado, pero dados los requisitos de cumplimiento de Mercor para la incorporación de contratistas, la base de datos casi con certeza incluye información de identificación personal para decenas de miles de contratistas.
• ~3 TB de contenido de buckets de almacenamiento. Esta es la categoría más sensible para los contratistas individuales. Los buckets de almacenamiento contenían grabaciones de video de entrevistas técnicas utilizadas para verificación de identidad y selección de competencias, escaneos de identificación emitida por el gobierno, incluidos pasaportes y tarjetas de identificación nacional, números de Seguro Social recopilados durante la incorporación de contratistas estadounidenses, y documentos de verificación de identidad enviados para cumplir con los requisitos de KYC. La combinación de video biométrico, identificación gubernamental y SSN representa un paquete de identidad completo para los contratistas afectados — suficiente para robo de identidad, fraude de identidad sintética e ingeniería social dirigida.

Por qué las cadenas de suministro de entrenamiento de IA son un objetivo excepcionalmente sensible

Una brecha en una plataforma estándar de gestión de contratistas SaaS sería grave principalmente por la exposición de datos personales. La brecha de Mercor es categóricamente diferente debido a lo que realmente manejan los contratistas que trabajan a través de Mercor.

Los contratistas de IA al nivel de la base de clientes de Mercor no están realizando ingreso de datos genérico. Están realizando tareas que tocan los aspectos más propietarios y competitivamente sensibles del desarrollo de IA: evaluar salidas de modelos en benchmarks de capacidad que no se han publicado públicamente, anotar casos límite que revelan dónde falla actualmente un modelo, calificar respuestas según criterios que codifican la metodología de entrenamiento RLHF de una empresa, y probar filtros de seguridad de maneras que exponen lo que el modelo puede y no puede hacer. Las instrucciones, rúbricas y especificaciones de tareas que reciben los contratistas son el núcleo intelectual de cómo estos laboratorios entrenan y alinean sus modelos.

El código fuente de Mercor — que incluye las interfaces y herramientas a través de las cuales se entregan estas tareas — podría exponer esas metodologías incluso si los datos de tareas individuales no estuvieran en el conjunto exfiltrado. Para un adversario que construye un modelo competidor, o para un actor estatal que intenta comprender los límites de seguridad y las técnicas de entrenamiento de los sistemas de IA de frontera, esto representa acceso a información que no se puede reconstruir a partir de la investigación pública.

Respuesta posterior

La respuesta de los clientes de Mercor ha sido medida pero significativa. Meta pausó indefinidamente todo trabajo de datos enrutado a través de Mercor el 2 de abril, dos días después de que se confirmara la brecha, citando incertidumbre sobre la integridad del entorno del contratista y la posible exposición de las especificaciones de tareas. Tanto OpenAI como Anthropic emitieron declaraciones confirmando que están auditando su exposición — revisando específicamente si algún dato de entrenamiento propietario, rúbricas de anotación o marcos de evaluación eran accesibles para los contratistas a través de la plataforma ahora comprometida de Mercor en el momento de la brecha.

Ni OpenAI ni Anthropic han confirmado si materiales de entrenamiento propietarios estaban entre los datos exfiltrados. El volcado de código fuente de 939 GB es el vector más probable para la exposición indirecta: si el código fuente de la plataforma de Mercor incluye plantillas de tareas integradas, criterios de evaluación o muestras de salida de modelos utilizados para entrenar la calidad de los contratistas, esos estarían ahora en posesión de Lapsus$.

Lapsus$ ha listado el conjunto completo de datos de 4 TB para subasta en su mercado de la dark web, con lo que las fuentes describen como un precio de siete cifras. El grupo tiene un historial documentado de concretar ventas de datos — más notablemente con datos robados de Nvidia, Samsung y Microsoft en 2022 — lo que otorga credibilidad a la lista de subasta más allá de una amenaza de extorsión típica.

Se han presentado cinco demandas colectivas en un tribunal federal de EE. UU. por parte de contratistas afectados, alegando prácticas negligentes de seguridad de datos, falta de implementación de controles adecuados en la cadena de suministro y notificación inadecuada después de la brecha. Las demandas nombran específicamente a Mercor; ninguna ha nombrado aún a las empresas de IA cuyos programas de contratistas estaban alojados en la plataforma.

Qué deben hacer los desarrolladores

Si tu base de código usa LiteLLM, los pasos inmediatos son específicos:

• Verifica tu versión instalada. Ejecuta pip show litellm o inspecciona tu requirements.txt, pyproject.toml o archivo de bloqueo. Si tienes litellm==1.82.7 o litellm==1.82.8 en algún lugar de tu gráfico de dependencias, incluidas las dependencias transitivas, trata el entorno como comprometido. Rota todos los secretos accesibles a ese proceso: claves API, credenciales de base de datos, tokens de proveedor de nube y cualquier variable de entorno.
• Audita tu estrategia de fijación de dependencias de PyPI. Cualquier dependencia descargada con un rango de versión (litellm>=1.82) o sin restricción de versión (litellm) era vulnerable a esta clase de ataque. Fija a versiones exactas y usa un archivo de bloqueo (Poetry's poetry.lock o el requirements.txt generado por pip-compile) que incluya hashes. La bandera de fijación de hash --require-hashes en pip hace imposible instalar un paquete cuyo contenido no coincida con el hash registrado, incluso si un atacante reemplaza una versión en PyPI.
• Revisa la fijación de versiones de tus herramientas de CI/CD. La brecha de LiteLLM se originó porque Trivy no estaba fijado a una versión específica en el pipeline de compilación de LiteLLM. Cada herramienta en tu pipeline de CI/CD — escáneres, linters, herramientas de compilación, ejecutores de pruebas — debe estar fijada a una versión específica y preferiblemente a un hash de contenido. GitHub Actions permite fijar acciones a un SHA de commit completo en lugar de una etiqueta, lo que evita ataques de etiqueta mutable. Para herramientas basadas en contenedores como Trivy, fija al digest de la imagen (aquasec/trivy@sha256:...), no a la etiqueta (aquasec/trivy:latest).
• Audita qué secretos son accesibles en tu entorno de compilación. Las credenciales de publicación de PyPI nunca deben estar disponibles como variables de entorno en el mismo paso del pipeline que ejecuta el escaneo de dependencias o las pruebas. Usa trabajos de pipeline separados con ámbitos de credenciales distintos y aplica principios de privilegio mínimo a qué secretos puede acceder cada paso.

El patrón: ataques a la cadena de suministro contra herramientas de desarrollo

El ataque a LiteLLM es el último de una secuencia de ataques a la cadena de suministro que han apuntado progresivamente a capas más profundas de la pila de herramientas de desarrollo:

• SolarWinds (diciembre de 2020): Actores estatales (APT29/Cozy Bear) comprometieron el sistema de compilación de SolarWinds, inyectando una puerta trasera en la plataforma Orion distribuida a aproximadamente 18,000 organizaciones, incluidas agencias federales de EE. UU. El vector de ataque fue el propio pipeline de compilación.
• Codecov (abril de 2021): Atacantes modificaron el script de carga bash de Codecov alojado en su propia infraestructura. Cualquier pipeline de CI/CD que ejecutara el script — un patrón común para informes de cobertura de código — cargaba variables de entorno, incluidos secretos, a servidores controlados por atacantes.
• xz Utils (marzo de 2024): Una sofisticada campaña de ingeniería social de varios años resultó en la fusión de una puerta trasera en la biblioteca de compresión xz, dirigida a la autenticación del servidor SSH en sistemas Linux. El atacante pasó dos años generando confianza como colaborador legítimo antes de insertar el código malicioso.
• LiteLLM a través de Trivy (marzo de 2026): Un escáner de vulnerabilidades utilizado sin fijación de versión se convirtió en el punto de entrada para el robo de credenciales, que luego permitió publicar un paquete malicioso en PyPI bajo el nombre de una biblioteca confiable.

El hilo conductor es consistente: los atacantes no están rompiendo defensas de aplicaciones endurecidas. Están explotando las relaciones de confianza entre las herramientas en las que los desarrolladores confían para construir, probar e implementar software. A medida que las herramientas de desarrollo de IA se vuelven más interconectadas — con bibliotecas como LiteLLM sirviendo como infraestructura crítica para enrutar llamadas a modelos de frontera — el radio de explosión de una dependencia comprometida crece proporcionalmente. La brecha de Mercor no es un caso atípico. Es una ilustración de cómo se verán los próximos años de ataques a la cadena de suministro contra la industria de la IA.