Plus de 35 000 applications créées avec Grok exposées en ligne avec des fuites de données sensibles

La société de sécurité Claroc a identifié une exposition massive d'applications générées par l'assistant IA Grok, révélant que plus de 35 000 de ces applications étaient publiquement accessibles sans authentification. L'incident, signalé le 11 novembre 2026, comprend des outils internes créés par des employés de X et SpaceXSI, ayant entraîné la fuite de données d'entreprise sensibles allant des cartes commerciales aux mots de passe des employés.

Ce qui s'est passé

Les chercheurs de Claroc ont scanné Internet à la recherche d'applications hébergées sur le sous-domaine grok.me, utilisé pour les applications créées via le constructeur basé sur le chat de Grok. Ils ont découvert 37 571 applications de ce type, dont 35 578 étaient ouvertes à quiconque disposait du lien et ne nécessitaient aucune connexion. Bien que beaucoup d'entre elles soient de simples jeux ou calculateurs, environ 10 % contenaient des informations professionnelles ou personnelles internes. Parmi les éléments exposés figuraient 24 applications créées par le personnel de X et SpaceXSI, l'entreprise derrière Grok. Celles-ci comprenaient un plan d'intégration confidentiel pour un nouveau recruteur commercial, une carte du territoire de vente couvrant 594 comptes, et une proposition publicitaire marquée comme confidentielle destinée à une agence fédérale américaine.

Au-delà des entreprises technologiques directement impliquées, les chercheurs ont identifié des données internes provenant de 30 autres organisations dans des secteurs tels que la santé, la défense et l'énergie. Six de ces entités affectées sont des entreprises du classement Fortune 500. La gravité des fuites variait, mais Claroc a estimé qu'environ 2 % des applications ouvertes présentaient des risques élevés ou critiques. Les exemples incluaient une liste consultable de 3 500 employés hospitaliers, un briefing patient en soins intensifs, et une application de feuilles de temps pour sous-traitants stockant les mots de passe des employés en texte clair dans son code. SpaceXSI a depuis supprimé les 24 applications créées par le personnel, mais n'a pas retiré l'ensemble plus large des applications générées par les utilisateurs.

La racine du problème réside dans la manière dont Grok gère la publication des applications. Lorsque les utilisateurs créent une application via l'interface de chat, ils doivent cliquer sur « Publish » (Publier) pour la rendre accessible. Lors de ce processus, le paramètre d'accès par défaut est « Anyone with the link » (Toute personne disposant du lien), plutôt qu'une option plus restrictive. Bien que Grok suggère des noms aléatoires de quatre mots pour les applications, rendant leur devinette difficile, ces noms ne sont pas secrets. Les services DNS passifs enregistrent chaque consultation de ces sous-domaines, permettant aux attaquants de découvrir les adresses des applications en fouillant les journaux DNS. En revanche, les chercheurs ont noté que le constructeur d'applications de ChatGPT utilise par défaut « Only me » (Moi uniquement), ce qui signifie que même si une adresse est trouvée dans les enregistrements DNS, le contenu reste inaccessible aux étrangers.

Détails clés

• Échelle de l'exposition : 35 578 des 37 571 applications créées avec Grok découvertes étaient publiquement accessibles sans exigence de connexion.
• Impact sur les entreprises : 24 applications du personnel de X et SpaceXSI ont été exposées, ainsi que des données provenant de 30 autres organisations, dont six entreprises du Fortune 500.
• Types de données sensibles : Les fuites comprenaient des cartes de territoires commerciaux, des propositions gouvernementales confidentielles, des briefings médicaux patients et des mots de passe en texte clair.
• Risque lié aux paramètres par défaut : L'autorisation « Anyone with the link » était pré-sélectionnée lors de la publication, contrairement aux concurrents qui optent par défaut pour un accès privé.
• Méthode de découverte : Les chercheurs ont utilisé des données DNS passives pour trouver les sous-domaines des applications, prouvant que des noms obscurs ne garantissent pas la sécurité.
• Réponse du fournisseur : SpaceXSI a supprimé les applications du personnel mais ne s'est pas engagé à contacter les autres utilisateurs affectés ni à modifier les autorisations par défaut.

Contexte

Grok Build permet aux utilisateurs de générer des applications web fonctionnelles en les décrivant dans une interface de chat. Cette fonctionnalité a été rendue disponible pour tous les plans Grok le 19 août 2026. Chaque application publiée reçoit un sous-domaine unique sous grok.me. Le modèle de sécurité repose sur la sélection manuelle des contrôles d'accès par le créateur : « Anyone with the link », « Invited users » (Utilisateurs invités) ou « Only you » (Vous uniquement). Cependant, la facilité de génération par IA conduit souvent au « shadow IT » (IT fantôme), où les employés construisent et déploient des outils sans supervision des équipes centrales d'informatique ou de sécurité.

La surveillance DNS passive est une technique courante utilisée à la fois par les chercheurs en sécurité et les attaquants. Chaque fois qu'un appareil résout un nom de domaine en adresse IP, cette requête peut être enregistrée par des services tiers. En agrégeant ces journaux, on peut reconstituer une liste des sous-domaines actifs pour un domaine parent donné. Cela signifie que même si le nom d'une application est aléatoire et impossible à deviner, il devient découvrable dès que quelqu'un y accède, rendant la « sécurité par obscurité » inefficace.

Pourquoi c'est important

Pour les responsables informatiques et les managers d'ingénierie, cet incident met en lumière les risques liés aux outils d'IA non gérés. Lorsque les développeurs ou les unités métier utilisent des constructeurs d'IA en dehors des plateformes approuvées, ils contournent les revues de sécurité standard, les contrôles d'accès et les politiques de prévention contre la perte de données. Le fait que le code généré par Grok échoue parfois à valider correctement l'identité de l'utilisateur — par exemple en ajoutant tout utilisateur Google connecté à une équipe sans vérifier son affiliation — démontre que le code généré par IA ne peut pas être considéré comme sécurisé par défaut. Les équipes doivent supposer que toute application créée de cette manière peut présenter des vulnérabilités critiques, sauf si elle est explicitement testée.

L'exposition de mots de passe en texte clair et de documents RH confidentiels souligne la nécessité d'une gouvernance stricte des données. Même si une application semble inoffensive, comme un calculateur ou une page d'atterrissage, elle peut se connecter à des bases de données internes ou contenir des secrets codés en dur. La facilité de déploiement signifie que les données sensibles peuvent fuiter rapidement et rester exposées pendant de longues périodes si elles ne sont pas activement surveillées. Les organisations ne peuvent plus compter uniquement sur les défenses périmétriques ; elles doivent tenir compte des données circulant via des applications éphémères créées par les utilisateurs et hébergées sur des plateformes externes.

Ce que vous pouvez faire

• Auditer l'utilisation des outils d'IA : Identifiez quels constructeurs d'applications IA (tels que Grok, Lovable ou Replit) votre personnel utilise et établissez des politiques claires pour leur utilisation.
• Vérifier l'exposition DNS : Si vous avez accès à des données DNS passives, recherchez les sous-domaines associés aux constructeurs d'IA connus pour trouver d'éventuelles applications internes exposées.
• Vérifier les contrôles d'accès : Pour toute application Grok existante contenant des données internes, assurez-vous que le paramètre est modifié en « Invited users » ou « Only you » et confirmez que les étrangers reçoivent une page d'erreur.
• Tester la logique d'authentification : Essayez de vous connecter aux applications internes en utilisant un compte externe pour vérifier que l'application restreint correctement l'accès au personnel autorisé uniquement.
• Scanner les secrets : Passez en revue le code source ou les scripts chargés des applications générées par IA pour détecter les mots de passe codés en dur, les clés API ou les adresses e-mail, et dépubliez toute application qui manque d'un propriétaire clair.
• Imposer la confidentialité par défaut : Plaidez auprès des fournisseurs pour qu'ils modifient les paramètres de publication par défaut en « Private » (Privé) ou « Only me » afin de réduire les expositions accidentelles.