Piratage de Lilli chez McKinsey : 46,5 millions de messages exposés
Le piratage de Lilli chez McKinsey, révélé le 9 mars 2026 par la start-up de red team CodeWall, a montré un agent IA obtenir en deux heures un accès complet en lecture et en écriture à la plateforme d'IA interne du cabinet de conseil. Selon CodeWall, l'agent a atteint 46,5 millions de messages de chat et 95 prompts système modifiables grâce à une faille d'injection SQL. McKinsey affirme avoir corrigé les problèmes en quelques heures et n'avoir trouvé aucun signe d'accès aux données de ses clients. Pour toute entreprise qui utilise un assistant IA interne, le cas montre qu'une vieille faille web peut désormais atteindre les instructions du modèle.
Pourquoi Lilli était une cible précieuse pour un attaquant
Lilli contient une grande partie du savoir de McKinsey. Le cabinet a déployé cette plateforme d'IA générative en juillet 2023 et, selon l'entreprise, 72 % de ses employés, soit plus de 40 000 personnes, l'utilisent aujourd'hui. Le chatbot traite plus de 500 000 prompts chaque mois.
Les consultants utilisent Lilli pour interroger la base de connaissances du cabinet en langage naturel. Dans un entretien accordé à The Stack début 2025, Jacky Wright, alors directrice de la technologie et des plateformes de McKinsey, expliquait que le cabinet avait versé ses connaissances dans des bases vectorielles à l'aide de modèles d'embedding d'OpenAI, avec une recherche sémantique et par mots clés et le reranker de Cohere pour affiner les résultats. Le cabinet indique que le conseil en IA représente environ 40 % de son chiffre d'affaires, et son PDG a déclaré que McKinsey a créé 25 000 agents IA pour épauler ses équipes.
Comment l'agent IA de CodeWall a choisi McKinsey et est entré
CodeWall utilise des agents IA pour attaquer l'infrastructure de ses clients afin qu'ils corrigent leurs faiblesses avant les autres. C'est son propre agent de sécurité qui a proposé McKinsey comme cible, en citant la politique publique de divulgation responsable du cabinet, publiée sur HackerOne, et les mises à jour récentes de Lilli. L'agent ne disposait d'aucun identifiant.
Il a trouvé une documentation d'API exposée publiquement qui listait plus de 200 endpoints, dont 22 ne demandaient aucune authentification. L'un de ces endpoints ouverts enregistrait les requêtes de recherche des utilisateurs, et les clés JSON, c'est-à-dire les noms des champs, étaient concaténées dans du SQL. Quand l'agent a vu ces noms de champs renvoyés tels quels dans les messages d'erreur de la base de données, il a reconnu une injection SQL que les outils classiques ne signaleraient pas. CodeWall explique avoir ensuite mené quinze itérations à l'aveugle jusqu'à ce que des données de production réelles commencent à remonter.
Le fondateur de CodeWall, Paul Price, a déclaré à The Stack que l'intrusion avait pris deux heures et coûté 20 dollars de tokens. Il a précisé à The Register que le processus était « entièrement autonome, de la recherche sur la cible à l'analyse, à l'attaque et au rapport ».
Ce que l'agent a atteint dans Lilli
Selon CodeWall, l'agent disposait en deux heures d'un accès complet en lecture et en écriture à la base de données de production. D'après son décompte, cela couvrait 46,5 millions de messages de chat sur la stratégie, les fusions et acquisitions et les missions clients, stockés en clair, ainsi que 728 000 fichiers, 57 000 comptes utilisateurs, 384 000 assistants IA et 94 000 espaces de travail.
Ces chiffres sont ceux de CodeWall. L'analyste en sécurité Edward Kiledjian a jugé la chaîne d'attaque « plausible et techniquement solide », tout en estimant que l'ampleur annoncée de l'impact n'était « pas entièrement démontrée ». Une source chez McKinsey a indiqué au Financial Times que les fichiers sous-jacents étaient stockés séparément et n'avaient « jamais été en danger ».
Pourquoi des prompts système modifiables aggravent le risque
Les 95 prompts système de Lilli, les instructions qui dictent la façon dont le chatbot répond, se trouvaient dans la même base de données, et la faille permettait d'y écrire. Un attaquant aurait pu les réécrire en silence et changer la façon dont Lilli répondait aux consultants, les garde-fous qu'il respectait et sa manière de citer ses sources, sans nouveau code ni alerte de sécurité classique.
« Aucun déploiement nécessaire. Aucune modification de code. Une seule instruction UPDATE dans un seul appel HTTP. » CodeWall, sur la façon dont les prompts de Lilli auraient pu être réécrits
Comment McKinsey a réagi au signalement
L'agent de CodeWall a trouvé la faille fin février, et les chercheurs ont communiqué la chaîne d'attaque complète le 1er mars. Le 2 mars, McKinsey avait corrigé tous les endpoints sans authentification, mis hors ligne son environnement de développement et bloqué l'accès public à la documentation de l'API.
Un porte-parole de McKinsey a déclaré que le cabinet avait corrigé les problèmes en quelques heures. Selon l'entreprise, son enquête, menée avec l'appui d'un cabinet d'investigation numérique de premier plan, n'a trouvé aucune preuve que des données clients ou des informations confidentielles de clients aient été consultées par le chercheur ou par un autre tiers non autorisé. Paul Price affirme que l'équipe de McKinsey a relu et amendé l'article de blog de CodeWall avant sa publication.
Ce que l'intrusion signifie pour les entreprises dotées d'outils IA internes
La faille n'était pas nouvelle. Selon CodeWall, Lilli était en production depuis plus de deux ans et les scanners internes de McKinsey n'avaient pas détecté le problème ; Paul Price ajoute qu'un scan OWASP ZAP l'avait lui aussi manqué. La couche d'IA n'a pas créé la faille, mais elle en a augmenté le coût.
Pour une entreprise, la leçon est simple : un assistant interne hérite de toutes les faiblesses de l'application web qui l'entoure. Une documentation d'API exposée, des endpoints sans authentification et des prompts stockés à côté des données des utilisateurs transforment un bug banal en moyen de changer ce que l'on dit à des milliers d'employés. Paul Price prévient que des attaquants utiliseront les mêmes techniques d'agents, avec des objectifs comme le chantage financier ou le rançongiciel.
Questions et réponses
Comment un agent IA a-t-il piraté Lilli, l'IA de McKinsey ?
L'agent de CodeWall a trouvé une documentation d'API publique, utilisé l'un des 22 endpoints qui ne demandaient aucune authentification et repéré une injection SQL dans la façon dont les clés JSON étaient intégrées aux requêtes de la base de données. Les messages d'erreur ont ensuite laissé fuiter des données de production réelles.
Des données clients de McKinsey ont-elles été exposées lors de l'intrusion dans Lilli ?
CodeWall affirme que son agent pouvait atteindre des données confidentielles de clients. McKinsey assure que son enquête, menée avec un cabinet d'investigation numérique externe, n'a trouvé aucune preuve que des données clients aient été consultées par le chercheur ou par une autre personne non autorisée.
Qu'est-ce que la plateforme Lilli de McKinsey ?
Lilli est la plateforme d'IA générative interne de McKinsey, lancée en juillet 2023. Elle répond aux questions des consultants à partir de la base de connaissances du cabinet, et l'entreprise indique que 72 % de ses employés l'utilisent.
Le regard de MOZGII
Comment nous le construirions
Un assistant interne comme Lilli, ce sont en réalité trois choses : un stock de documents, un jeu d'instructions qui disent au modèle comment répondre, et un service web qui permet de poser des questions. Ici, le point faible était le service web, et les instructions se trouvaient dans la même base de données que tout le reste. Si nous construisions un tel assistant, nous garderions les prompts système dans un stockage séparé que l'application en production peut lire mais jamais modifier. Toute modification d'un prompt passerait par la même revue qu'une modification de code, avec une personne nommée pour l'approuver.
Nous placerions chaque endpoint derrière une connexion par défaut et garderions la documentation de l'API hors de l'internet public. Nous lancerions aussi régulièrement notre propre agent d'attaque contre le service, car le cas montre que les scanners ordinaires peuvent manquer ce qu'un agent trouve en réessayant encore et encore. Chaque découverte irait à une personne responsable de la correction, avec une échéance.
Le système casserait là où les équipes ajoutent vite de nouveaux endpoints pour une nouvelle fonctionnalité et sautent la revue. Le seul indicateur que nous suivrions est la part des endpoints en production qui exigent une authentification, qui devrait rester à la totalité. Ensuite, nous construirions une alerte qui se déclenche quand les instructions d'un assistant changent en dehors du circuit de mise en production approuvé, pour qu'une modification silencieuse devienne bruyante.
Sources
D’où viennent les faits de cet article.