Quando a IA não foi o elo fraco: a exposição de dados de candidatos do McHire

O que aconteceu

Em junho de 2025, os pesquisadores de segurança Ian Carroll e Sam Curry divulgaram uma cadeia de vulnerabilidades no McHire, a plataforma de contratação do McDonald's construída pela Paradox.ai e usada pela grande maioria das franquias do McDonald's. Relatórios públicos da Wired e do BleepingComputer estimam o conjunto de dados expostos em aproximadamente 64 milhões de candidatos a emprego, com nomes, endereços de e-mail, números de telefone e transcrições de bate-papo acessíveis a qualquer pessoa que seguisse o mesmo caminho que os pesquisadores.

A manchete que mais circulou enquadrou isso como um ataque de injeção de prompt no chatbot "Olivia". Essa abordagem está errada. Os pesquisadores dizem que tentaram a injeção de prompt primeiro, e falhou: o bot estava rigidamente restrito a respostas pré-definidas e nunca teve dados de back-end que pudessem ser enganados para vazar. O comprometimento não teve nada a ver com o modelo de linguagem.

O ponto de entrada real foi uma página de login administrativo da Paradox.ai no McHire, acessível pela internet pública. Os pesquisadores tentaram as credenciais "123456" / "123456" em uma conta de teste que, de acordo com relatórios públicos, havia sido deixada ativa desde 2019. Eles conseguiram entrar.

Uma vez lá dentro, uma clássica Referência Direta a Objeto Insegura (IDOR) na API do candidato permitiu que eles incrementassem um ID numérico e puxassem o registro de qualquer candidato. Nenhuma exploração do modelo, nenhuma técnica nova, nenhum zero-day. Credenciais padrão mais uma referência de objeto não autenticada.

Por que esse padrão se repete

A falha interessante aqui não é técnica, é organizacional. O chatbot era o componente visível de "IA", então absorveu a atenção da segurança. O chato administrador da web por trás dele era o raio de explosão real, e quase ninguém estava olhando para ele dessa forma.

Isso acontece sempre que um comprador trata um fornecedor de IA como um produto de IA, em vez de como um aplicativo SaaS que por acaso contém um modelo. O modelo recebe uma revisão de equipe vermelha. O console de administração, a API do candidato, o bucket de armazenamento, o registro de auditoria, a política de rotação de credenciais — as coisas que têm décadas de modos de falha conhecidos — são tratadas como encanamento.

A estrutura de incentivos do fornecedor a reforça. Fornecedores de IA entregam rapidamente, muitas vezes antes de terem um programa de segurança maduro, e as equipes de compras de seus clientes perguntam sobre o comportamento do modelo, em vez de sobre o aplicativo circundante. Uma conta de teste de 2019 com a senha "123456" sobrevive a essa lacuna por anos porque ninguém delimitou a revisão para encontrá-la.

As violações de IA mais caras dos próximos dois anos não serão explorações de modelos. Serão vulnerabilidades da web da era de 1990 no aplicativo que envolve o modelo.

O playbook do atacante passo a passo

A sequência divulgada foi curta, e essa é a parte desconfortável. Um atacante habilidoso não precisou de uma cadeia de primitivas novas.

Passo 1: enumerar a superfície do fornecedor de IA

Identifique o fornecedor terceirizado por trás do chatbot visível. Neste caso, o bot se identificou como construído pela Paradox.ai, o que apontou para uma superfície administrativa separada — uma página de login no mesmo domínio McHire.

Passo 2: tentar as credenciais óbvias

Credenciais padrão e fracas continuam sendo o ataque de maior rendimento contra painéis de administração de fornecedores. Relatórios indicam que uma única conta de teste com "123456" / "123456" foi suficiente.

Passo 3: pivotar de administrador para dados

A função de administrador expôs uma API de candidato interna. A API usava um identificador numérico sequencial e não verificava se a conta chamadora estava autorizada a ler cada candidato específico. Iterar o ID retornava registros arbitrários.

Passo 4: confirmar o escopo e divulgar

Os pesquisadores pararam na prova de impacto, validaram o tamanho do conjunto de dados e relataram à Paradox.ai e ao McDonald's. A Paradox.ai desativou a conta de teste e, segundo relatos, corrigiu o IDOR horas após a divulgação.

O que os defensores perderam

Três coisas, em ordem decrescente de gravidade.

Primeiro, nenhuma higiene de credenciais na superfície de administração do fornecedor. Uma conta de teste que antecedeu a implantação em produção, com uma senha numérica de seis caracteres, estava acessível pela internet pública cinco anos após sua criação. Qualquer auditoria periódica de credenciais a teria encontrado.

Segundo, nenhuma verificação de autorização na API do candidato. IDOR é uma das vulnerabilidades da web mais antigas e bem documentadas no catálogo OWASP. O fato de uma chamada de administrador autenticada retornar registros arbitrários de candidatos significa que a API impôs autenticação, mas não autorização.

Terceiro, nenhuma revisão de segurança da superfície "chata". O chatbot recebeu atenção porque era a IA. O login de administrador, o gateway de API e o armazenamento de 64 milhões de registros de PII não receberam o mesmo escrutínio — no McDonald's, na Paradox.ai ou nas franquias que implantaram o McHire.

Uma lista de verificação defensiva prática

As correções são pouco glamorosas. Elas também são o que teria evitado este incidente.

• Inventarie todas as superfícies de autenticação expostas por qualquer fornecedor de IA que você usa, incluindo painéis de administração, ambientes de teste e ferramentas de suporte ao cliente. Trate-os como aplicativos web de joias da coroa, não como encanamento para o modelo.
• Exija que os fornecedores atestem, por escrito, que nenhuma credencial padrão ou compartilhada existe em produção e que as contas de teste criadas durante a integração sejam excluídas no momento do lançamento.
• Execute testes IDOR/BOLA autenticados contra todas as APIs que o fornecedor expõe, especialmente APIs que retornam registros por usuário. O OWASP API Security Top 10 classifica isso como #1 por um bom motivo.
• Force o SSO com seu provedor de identidade para todas as superfícies de administração do fornecedor, para que as credenciais não possam se desviar independentemente e as contas antigas morram quando os funcionários saírem.
• Limite os privilégios da sessão de administrador para que uma única conta de administrador comprometida não possa enumerar todo o conjunto de dados de candidatos ou clientes.
• Exija que o fornecedor registre e alerte sobre padrões de leitura em massa contra APIs sensíveis. Puxar dezenas de milhões de registros de candidatos não deve parecer um dia normal.

Como testes ofensivos modernos teriam pego isso

Um engajamento ofensivo autorizado e com escopo contra a superfície do fornecedor McHire — não contra o chatbot — teria encontrado isso na primeira tarde. As verificações relevantes são bem conhecidas: pulverização de credenciais contra o login de administrador, controle de acesso horizontal autenticado em cada API parametrizada e revisão de contas de teste e fluxos de trabalho de redefinição.

O modelo em si não precisa de uma equipe vermelha nesta história. O modelo se comportou corretamente. As salvaguardas do chatbot se mantiveram. A lição é que uma revisão completa de segurança do aplicativo do produto envolvente teria sinalizado cada etapa da cadeia de ataque antes que ela estivesse ativa.

O que observar a seguir

Espere mais disso. Os fornecedores de IA estão absorvendo fluxos de trabalho mais sensíveis — contratação, sinistros, atendimento ao cliente, agendamento — e os consoles administrativos de back-end em torno desses fluxos de trabalho agora contêm concentrações de dados pessoais regulamentados que antes estavam em sistemas menos acessíveis.

Duas coisas a observar em seu próprio programa: quais fornecedores de IA detêm a maior concentração de dados pessoais regulamentados em seu nome e como é seu direito contratual de testar sua superfície de administração. Se você não pode executar uma revisão de segurança de aplicativo autenticada contra o painel do fornecedor, você está confiando que a próxima conta de teste foi excluída, a próxima API impõe autorização e a próxima senha padrão foi girada. A divulgação do McHire mostra o que acontece quando essa confiança é mal colocada.