Corrección editorial · 11 de septiembre de 2026. Reescribimos este artículo para separar los hechos respaldados por fuentes primarias de las afirmaciones que retiramos. Conservamos la URL y la fecha de publicación original.
Qué está confirmado
Mercor confirmó que, a fines de marzo de 2026, fue afectada por un ataque a la cadena de suministro relacionado con LiteLLM. Su comunicado explica que se publicaron versiones alteradas del paquete con capacidad de extraer credenciales de los sistemas que las instalaran. Esa es la relación que podemos sostener con una fuente directa. Mercor, comunicado del 25 de junio.
LiteLLM identifica dos versiones comprometidas de su paquete en PyPI: 1.82.7 y 1.82.8, publicadas el 24 de marzo. Su actualización distingue ese mecanismo de distribución de la imagen oficial de LiteLLM Proxy en Docker, que no resultó afectada por esos paquetes. Por eso, conocer el nombre de una herramienta no alcanza: hay que verificar la versión y cómo llegó al entorno. LiteLLM, actualización de seguridad de marzo.
| Punto a verificar | Qué podemos afirmar | Evidencia |
|---|---|---|
| Incidente en Mercor | La empresa reconoce que fue afectada por el ataque relacionado con LiteLLM. | Comunicado oficial |
| Paquetes comprometidos | LiteLLM señala las versiones 1.82.7 y 1.82.8 distribuidas por PyPI. | Versiones afectadas |
| Alcance en una empresa | Depende de las versiones instaladas, la vía de distribución y el entorno. No se deduce solo por usar IA. | Quiénes están afectados |
Cómo se propaga el riesgo
Una dependencia es código de un tercero que incorporás a tu software. Puede ejecutarse durante la instalación, el despliegue o el funcionamiento de una aplicación. Si ese código se altera, los permisos disponibles en ese momento determinan qué otros recursos quedan al alcance.
Este esquema muestra la relación de forma conceptual; no reconstruye la infraestructura de Mercor.
- 01PaqueteCódigo de un tercero
- 02PipelineInstalación o despliegue
- 03CredencialesPermisos disponibles
- 04SistemasAcceso a datos y servicios
La pregunta útil es concreta: si este paquete ejecutara código inesperado, a qué podría acceder? La respuesta requiere revisar credenciales, permisos, redes y registros de tu propio entorno.
Qué retiramos del reporte original
La versión anterior incluía nombres de clientes, citas atribuidas a personas, cifras de mercado y una cronología detallada sin respaldo primario suficiente. También vinculaba un identificador CVE y una versión de parche que no pudimos corroborar para este incidente.
Retiramos esas afirmaciones. No las usamos para estimar pérdidas, atribuir responsabilidades ni recomendar una versión de software. Los enlaces a noticias ajenas al tema también fueron reemplazados por recursos pertinentes.
Confirmar que hubo un incidente no valida automáticamente todos los detalles de una noticia. La tabla anterior delimita qué sostienen las fuentes consultadas.
Qué revisar en tu empresa
Lo que sí podés auditar hoy, sin asumir que este incidente ocurrió tal como se reportó: inventario de dependencias open-source en tus pipelines de datos, SBOM para sistemas de RRHH, versión de LiteLLM u otra librería que uses y política de parches, retención de CVs y permisos, registro de accesos, revisión humana y salida manual antes de automatizar producción.
Una SBOM es un inventario de los componentes de software de un sistema. Sirve para localizar una dependencia afectada; su existencia por sí sola no demuestra que el sistema sea seguro.
Pasar de una suposición a una comprobación
| Área | Comprobación débil | Evidencia útil para revisar |
|---|---|---|
| Dependencias | “Tenemos la última versión”. | Versión exacta, archivo de bloqueo, origen y fecha de instalación. |
| Acceso | “Solo lo usa el equipo técnico”. | Credenciales disponibles y permisos efectivos en instalación, despliegue y ejecución. |
| Datos | “La aplicación casi no guarda información”. | Tipos de datos, ubicación, retención y cuentas que pueden leerlos. |
| Respuesta | “Actualizamos si aparece una alerta”. | Responsable, registro de acciones y procedimiento de contención y recuperación. |
Lista de verificación para empresas LATAM
- Ubicá la dependencia. Identificá si está instalada y en qué sistemas. Una mención en un documento no prueba una instalación.
- Contrastá el caso exacto. Revisá la versión y la vía de distribución frente al aviso oficial del proveedor.
- Revisá el acceso disponible. Registrá qué datos, servicios y credenciales alcanza el proceso.
- Definí quién actúa. Asigná un responsable de evaluar el hallazgo y seguir las instrucciones vigentes del proveedor.
- Conservá evidencia y una salida manual. Guardá los registros necesarios y probá cómo continuar si detenés una automatización.
Limitaciones de esta revisión
Este artículo resume comunicados públicos consultados el 11 de septiembre de 2026. No contiene una auditoría de Mercor, de LiteLLM ni de tu empresa. Las recomendaciones generales no establecen si un entorno fue comprometido.
Antes de cambiar una dependencia o un proceso, contrastá la documentación oficial vigente con tu instalación y tu modelo de permisos. Para decisiones sobre datos de personas, incidentes o producción, involucrá a quienes tienen responsabilidad técnica y de protección de datos.
Fuentes y seguimiento
- Mercor · 25 de junio de 2026. Actualización sobre el incidente de seguridad. Fuente de la confirmación de la empresa.
- LiteLLM · marzo de 2026. Actualización sobre el incidente de cadena de suministro. Fuente de las versiones y vías de distribución afectadas.
Si nueva evidencia modifica una afirmación, actualizaremos esta página y su fecha de revisión. No trasladamos cifras o citas de versiones anteriores sin volver a comprobarlas.