Cuando la IA no fue el eslabón débil: la exposición de datos de solicitantes de McHire

Qué pasó

En junio de 2025, los investigadores de seguridad Ian Carroll y Sam Curry revelaron una cadena de vulnerabilidades en McHire, la plataforma de contratación de McDonald's construida por Paradox.ai y utilizada por la gran mayoría de las franquicias de McDonald's. Los informes públicos de Wired y BleepingComputer sitúan el conjunto de datos expuesto en aproximadamente 64 millones de solicitantes de empleo, con nombres, direcciones de correo electrónico, números de teléfono y transcripciones de chat accesibles para cualquiera que siguiera el mismo camino que los investigadores.

El titular que se difundió más rápido enmarcó esto como un ataque de inyección de prompts al chatbot "Olivia". Ese encuadre es incorrecto. Los investigadores dicen que primero intentaron la inyección de prompts, y falló: el bot estaba estrictamente limitado a respuestas predefinidas y nunca tuvo datos de backend que pudieran ser engañados para filtrar. El compromiso no tuvo nada que ver con el modelo de lenguaje.

El punto de entrada real fue una página de inicio de sesión administrativo de Paradox.ai en McHire, accesible desde internet público. Los investigadores probaron las credenciales "123456" / "123456" en una cuenta de prueba que, según los informes públicos, había permanecido activa desde 2019. Entraron.

Una vez dentro, una clásica Referencia Directa a Objeto Insegura (IDOR) en la API de solicitantes les permitió incrementar un ID numérico y extraer el registro de cualquier solicitante. Sin explotación del modelo, sin técnica novedosa, sin día cero. Credenciales predeterminadas más una referencia de objeto no autenticada.

Por qué este patrón se repite

El fallo interesante aquí no es técnico, es organizacional. El chatbot era el componente visible de "IA", por lo que absorbió la atención de seguridad. La aburrida administración web detrás de él era el radio de explosión real, y casi nadie lo veía de esa manera.

Esto sucede cada vez que un comprador trata a un proveedor de IA como un producto de IA en lugar de como una aplicación SaaS que casualmente contiene un modelo. El modelo recibe una revisión de equipo rojo. La consola de administración, la API de solicitantes, el bucket de almacenamiento, el registro de auditoría, la política de rotación de credenciales —las cosas que tienen décadas de modos de falla conocidos— se tratan como infraestructura.

La estructura de incentivos del proveedor lo refuerza. Los proveedores de IA lanzan rápidamente, a menudo antes de tener un programa de seguridad maduro, y los equipos de adquisiciones de sus clientes preguntan sobre el comportamiento del modelo en lugar de sobre la aplicación circundante. Una cuenta de prueba de 2019 con la contraseña "123456" sobrevive esa brecha durante años porque nadie delimitó la revisión para encontrarla.

Las brechas de IA más costosas de los próximos dos años no serán exploits de modelos. Serán vulnerabilidades web de la era de los 90 en la aplicación que rodea al modelo.

El manual del atacante paso a paso

La secuencia revelada fue corta, y esa es la parte incómoda. Un atacante hábil no necesitó una cadena de primitivas novedosas.

Paso 1: enumerar la superficie del proveedor de IA

Identificar al proveedor externo detrás del chatbot visible. En este caso, el bot se identificó como construido por Paradox.ai, lo que apuntaba a una superficie administrativa separada: una página de inicio de sesión en el mismo dominio de McHire.

Paso 2: probar las credenciales obvias

Las credenciales predeterminadas y débiles siguen siendo el ataque de mayor rendimiento contra los paneles de administración de proveedores. Los informes indican que una sola cuenta de prueba con "123456" / "123456" fue suficiente.

Paso 3: pivotar de administrador a datos

El rol de administrador expuso una API interna de solicitantes. La API utilizaba un identificador numérico secuencial y no verificaba que la cuenta que realizaba la llamada estuviera autorizada para leer cada solicitante específico. La iteración del ID devolvía registros arbitrarios.

Paso 4: confirmar el alcance y divulgar

Los investigadores se detuvieron en la prueba de impacto, validaron el tamaño del conjunto de datos e informaron a Paradox.ai y McDonald's. Paradox.ai deshabilitó la cuenta de prueba y, según los informes, solucionó el IDOR a las pocas horas de la divulgación.

Lo que los defensores pasaron por alto

Tres cosas, en orden decreciente de gravedad.

Primero, ninguna higiene de credenciales en la superficie de administración del proveedor. Una cuenta de prueba anterior a la implementación de producción, con una contraseña numérica de seis caracteres, era accesible desde internet público cinco años después de su creación. Cualquier auditoría periódica de credenciales la habría encontrado.

Segundo, ninguna verificación de autorización en la API de solicitantes. IDOR es una de las vulnerabilidades web más antiguas y mejor documentadas en el catálogo de OWASP. El hecho de que una llamada de administrador autenticada devolviera registros de solicitantes arbitrarios significa que la API aplicaba autenticación pero no autorización.

Tercero, ninguna revisión de seguridad de la superficie aburrida. El chatbot recibió atención porque era la IA. El inicio de sesión de administrador, la puerta de enlace de la API y el almacenamiento de 64 millones de registros de PII no recibieron el mismo escrutinio, ni en McDonald's, ni en Paradox.ai, ni en las franquicias que implementaron McHire.

Una lista de verificación defensiva práctica

Las soluciones no son glamorosas. También son lo que habría evitado este incidente.

• Inventarie cada superficie de autenticación expuesta por cualquier proveedor de IA que utilice, incluidos los paneles de administración, los entornos de prueba y las herramientas de atención al cliente. Trátelos como aplicaciones web de "joyas de la corona", no como infraestructura para el modelo.
• Exija a los proveedores que certifiquen, por escrito, que no existen credenciales predeterminadas o compartidas en producción, y que las cuentas de prueba creadas durante la incorporación se eliminen al entrar en funcionamiento.
• Ejecute pruebas IDOR/BOLA autenticadas contra cada API que exponga el proveedor, especialmente las API que devuelven registros por usuario. El Top 10 de Seguridad API de OWASP lo clasifica como el número 1 por una buena razón.
• Force el SSO con su proveedor de identidad para cada superficie de administración del proveedor, de modo que las credenciales no puedan desviarse de forma independiente y las cuentas antiguas mueran cuando los empleados se vayan.
• Limite los privilegios de la sesión de administrador para que una sola cuenta de administrador comprometida no pueda enumerar todo el conjunto de datos de solicitantes o clientes.
• Exija al proveedor que registre y alerte sobre patrones de lectura masiva contra API sensibles. Extraer decenas de millones de registros de solicitantes no debería parecer un día normal.

Cómo las pruebas ofensivas modernas habrían detectado esto

Un compromiso ofensivo autorizado y con alcance contra la superficie del proveedor de McHire —no contra el chatbot— habría encontrado esto en la primera tarde. Las verificaciones relevantes son bien conocidas: pulverización de credenciales contra el inicio de sesión de administrador, control de acceso horizontal autenticado en cada API parametrizada y revisión de cuentas de prueba y flujos de trabajo de restablecimiento.

El modelo en sí no necesita un equipo rojo en esta historia. El modelo se comportó correctamente. Las salvaguardas del chatbot se mantuvieron. La lección es que una revisión exhaustiva de la seguridad de la aplicación del producto envolvente habría señalado cada paso de la cadena de ataque antes de que estuviera en vivo.

Qué esperar a continuación

Espere más de esto. Los proveedores de IA están absorbiendo flujos de trabajo más sensibles —contratación, reclamaciones, servicio al cliente, programación— y las consolas administrativas de backend alrededor de esos flujos de trabajo ahora contienen concentraciones de datos personales regulados que antes residían en sistemas menos accesibles.

Dos cosas a observar en su propio programa: qué proveedores de IA tienen la mayor concentración de datos personales regulados en su nombre, y cómo es su derecho contractual a probar su superficie de administración. Si no puede ejecutar una revisión de seguridad de aplicaciones autenticada contra el panel del proveedor, está confiando en que la próxima cuenta de prueba se eliminó, la próxima API aplica autorización y la próxima contraseña predeterminada se rotó. La divulgación de McHire muestra lo que sucede cuando esa confianza está mal depositada.