Quand l'IA n'était pas le maillon faible : l'exposition des données des candidats McHire

Ce qui s'est passé

En juin 2025, les chercheurs en sécurité Ian Carroll et Sam Curry ont révélé une chaîne de vulnérabilités dans McHire, la plateforme de recrutement de McDonald's construite par Paradox.ai et utilisée par la grande majorité des franchises McDonald's. Les rapports publics de Wired et BleepingComputer estiment que l'ensemble de données exposé représente environ 64 millions de candidats, avec des noms, des adresses e-mail, des numéros de téléphone et des transcriptions de chat accessibles à quiconque a suivi le même chemin que les chercheurs.

Le titre qui a circulé le plus rapidement a présenté cela comme une attaque par injection d'invite sur le chatbot "Olivia". Ce cadrage est faux. Les chercheurs affirment avoir d'abord essayé l'injection d'invite, et cela a échoué : le bot était étroitement contraint à des réponses pré-enregistrées et n'a jamais eu de données backend qu'il aurait pu être incité à divulguer. Le compromis n'avait rien à voir avec le modèle linguistique.

Le point d'entrée réel était une page de connexion administrative Paradox.ai sur McHire, accessible depuis l'internet public. Les chercheurs ont essayé les identifiants "123456" / "123456" sur un compte de test qui, selon les rapports publics, était resté actif depuis 2019. Ils sont entrés.

Une fois à l'intérieur, une classique Référence d'Objet Directe Insécurisée (IDOR) sur l'API des candidats leur a permis d'incrémenter un identifiant numérique et d'extraire le dossier de n'importe quel candidat. Aucune exploitation du modèle, aucune technique nouvelle, aucun zero-day. Des identifiants par défaut plus une référence d'objet non authentifiée.

Pourquoi ce schéma se répète

L'échec intéressant ici n'est pas technique, il est organisationnel. Le chatbot était le composant visible, "IA", il a donc absorbé l'attention de la sécurité. L'administration web ennuyeuse derrière lui était le véritable rayon d'action, et presque personne ne le voyait de cette façon.

Cela se produit chaque fois qu'un acheteur traite un fournisseur d'IA comme un produit d'IA plutôt que comme une application SaaS qui se trouve contenir un modèle. Le modèle fait l'objet d'un examen par une équipe rouge. La console d'administration, l'API des candidats, le compartiment de stockage, la journalisation d'audit, la politique de rotation des identifiants – les choses qui ont des décennies de modes de défaillance connus – sont traitées comme de la plomberie.

La structure d'incitation des fournisseurs le renforce. Les fournisseurs d'IA livrent rapidement, souvent avant d'avoir un programme de sécurité mature, et les équipes d'approvisionnement de leurs clients posent des questions sur le comportement du modèle plutôt que sur l'application environnante. Un compte de test de 2019 avec le mot de passe "123456" survit à cet écart pendant des années parce que personne n'a ciblé l'examen pour le trouver.

Les violations d'IA les plus coûteuses des deux prochaines années ne seront pas des exploits de modèle. Ce seront des vulnérabilités web de l'ère des années 1990 dans l'application qui entoure le modèle.

Le plan d'attaque étape par étape

La séquence divulguée était courte, et c'est la partie inconfortable. Un attaquant qualifié n'avait pas besoin d'une chaîne de primitives nouvelles.

Étape 1 : énumérer la surface du fournisseur d'IA

Identifier le fournisseur tiers derrière le chatbot visible. Dans ce cas, le bot s'est identifié comme étant construit par Paradox.ai, ce qui a pointé vers une surface administrative distincte — une page de connexion sur le même domaine McHire.

Étape 2 : essayer les identifiants évidents

Les identifiants par défaut et faibles restent l'attaque la plus rentable contre les panneaux d'administration des fournisseurs. Les rapports indiquent qu'un seul compte de test avec "123456" / "123456" a suffi.

Étape 3 : pivoter de l'administration aux données

Le rôle d'administrateur a exposé une API interne des candidats. L'API utilisait un identifiant numérique séquentiel et ne vérifiait pas que le compte appelant était autorisé à lire chaque candidat spécifique. L'itération de l'ID a renvoyé des enregistrements arbitraires.

Étape 4 : confirmer la portée et divulguer

Les chercheurs se sont arrêtés à la preuve d'impact, ont validé la taille de l'ensemble de données et ont signalé à Paradox.ai et McDonald's. Paradox.ai a désactivé le compte de test et aurait corrigé l'IDOR dans les heures suivant la divulgation.

Ce que les défenseurs ont manqué

Trois choses, par ordre de gravité décroissant.

Premièrement, aucune hygiène des identifiants sur la surface d'administration du fournisseur. Un compte de test antérieur au déploiement en production, avec un mot de passe numérique de six caractères, était accessible depuis l'internet public cinq ans après sa création. Tout audit périodique des identifiants l'aurait trouvé.

Deuxièmement, aucune vérification d'autorisation sur l'API des candidats. L'IDOR est l'une des vulnérabilités web les plus anciennes et les mieux documentées dans le catalogue OWASP. Le fait qu'un appel d'administrateur authentifié ait renvoyé des enregistrements de candidats arbitraires signifie que l'API a appliqué l'authentification mais pas l'autorisation.

Troisièmement, aucun examen de sécurité de la surface ennuyeuse. Le chatbot a attiré l'attention parce que c'était l'IA. La connexion d'administration, la passerelle API et le stockage de 64 millions de dossiers PII n'ont pas fait l'objet du même examen — chez McDonald's, chez Paradox.ai ou chez les franchisés qui ont déployé McHire.

Une liste de contrôle défensive pratique

Les correctifs sont peu glamour. Ce sont aussi ce qui aurait empêché cet incident.

• Inventoriez chaque surface d'authentification exposée par tout fournisseur d'IA que vous utilisez, y compris les panneaux d'administration, les environnements de test et les outils de support client. Traitez-les comme des applications web de premier ordre, et non comme de la plomberie pour le modèle.
• Exigez des fournisseurs qu'ils attestent, par écrit, qu'aucun identifiant par défaut ou partagé n'existe en production, et que les comptes de test créés lors de l'intégration sont supprimés au moment de la mise en service.
• Exécutez des tests IDOR/BOLA authentifiés contre chaque API exposée par le fournisseur, en particulier les API qui renvoient des enregistrements par utilisateur. Le Top 10 de la sécurité des API OWASP classe cela au premier rang pour une bonne raison.
• Forcez le SSO avec votre fournisseur d'identité pour chaque surface d'administration du fournisseur, afin que les identifiants ne puissent pas dériver indépendamment et que les anciens comptes soient désactivés lorsque les employés partent.
• Limitez les privilèges de session d'administrateur afin qu'un seul compte d'administrateur compromis ne puisse pas énumérer l'ensemble des données des candidats ou des clients.
• Exigez du fournisseur qu'il enregistre et alerte sur les modèles de lecture en masse contre les API sensibles. L'extraction de dizaines de millions de dossiers de candidats ne devrait pas ressembler à un jour normal.

Comment les tests offensifs modernes auraient détecté cela

Un engagement offensif ciblé et autorisé contre la surface du fournisseur McHire — et non contre le chatbot — aurait trouvé cela dès le premier après-midi. Les vérifications pertinentes sont bien connues : pulvérisation d'identifiants contre la connexion d'administration, contrôle d'accès horizontal authentifié sur chaque API paramétrée, et examen des comptes de test et des flux de réinitialisation.

Le modèle lui-même n'a pas besoin d'une équipe rouge dans cette histoire. Le modèle s'est comporté correctement. Les garde-fous du chatbot ont tenu. La leçon est qu'un examen approfondi de la sécurité de l'application du produit enveloppant aurait signalé chaque étape de la chaîne de destruction avant qu'elle ne soit mise en ligne.

Ce qu'il faut surveiller ensuite

Attendez-vous à plus de cela. Les fournisseurs d'IA absorbent de plus en plus de flux de travail sensibles — recrutement, réclamations, service client, planification — et les consoles administratives backend autour de ces flux de travail détiennent désormais des concentrations de données personnelles réglementées qui se trouvaient auparavant dans des systèmes moins accessibles.

Deux choses à surveiller dans votre propre programme : quels fournisseurs d'IA détiennent la plus forte concentration de données personnelles réglementées en votre nom, et à quoi ressemble votre droit contractuel de tester leur surface d'administration. Si vous ne pouvez pas effectuer un examen de sécurité d'application authentifié contre le panneau du fournisseur, vous faites confiance au fait que le prochain compte de test a été supprimé, que la prochaine API applique l'autorisation et que le prochain mot de passe par défaut a été modifié. La divulgation de McHire montre ce qui se passe lorsque cette confiance est mal placée.