Grok Build a exposé les données de 35 000 applications à cause d'un secret placé dans un sous-domaine

Imaginez : en dix minutes, vous avez construit un tableau de bord interne avec un agent IA, cliqué sur « partager » et envoyé le lien à un collègue. L'adresse est longue, composée de mots aléatoires, donc impossible à deviner. Puis il s'avère que n'importe qui sachant utiliser une base publique de requêtes DNS peut la voir. Selon les chercheurs de Claroc, c'est exactement ce qui s'est produit avec Grok Build, l'agent de vibe coding de SpaceXSI (nom désormais porté par la fusion de SpaceX et xAI).

Ce qui a réellement dysfonctionné

L'idée du schéma est saine. Elle s'appelle capability-based access control : connaître l'URL équivaut à avoir le droit d'accès. Il suffit que l'adresse ne puisse être ni devinée ni retrouvée. Trois mots aléatoires donnent environ 38 bits d'entropie, soit des milliards de combinaisons. Google procède de façon similaire dans Docs, mais la chaîne aléatoire se trouve dans le chemin, après le domaine.

Grok Build a placé les mots aléatoires à gauche du domaine, dans le sous-domaine : cinder-crane-sand-frost.grok.me. Or les noms de sous-domaines fuitent. Lorsque quelqu'un demande pour la première fois l'adresse IP d'un nouvel hôte, l'enregistrement se dépose dans les bases publiques de passive DNS. Il suffit alors de chercher tout ce qui se termine par grok.me. Inutile de deviner quoi que ce soit : il suffit de lire une liste toute prête. Le chemin de l'URL n'entre pas dans la requête DNS, c'est pourquoi cette astuce ne fonctionne pas avec les liens Google.

Claroc a trouvé 43 601 liens grok.me. Plus de 35 000 d'entre eux, soit près de 95 %, ouvraient l'application avec toutes ses données. Parmi les éléments découverts : 3 784 bilans médicaux d'ouvriers d'une entreprise de construction péruvienne, une liste de 3 565 employés d'un hôpital, un tableau de 22 techniciens Tesla avec leur productivité et leurs primes, environ 4 000 commandes d'un transporteur automobile avec prix et marges. On y a aussi trouvé 24 applications de SpaceXSI elle-même : un plan d'intégration d'un commercial marqué confidential et une carte de 594 comptes clients.

Le réglage par défaut contre la réalité

Selon les tests d'Asaf Aprozper, CTO de Claroc, Grok Build définit par défaut l'accès « Anyone with the link ». Pour fermer l'application, l'utilisateur doit choisir lui-même « invités » ou « vous uniquement ». Un représentant de Cursor (récemment racheté par SpaceXSI) a assuré que les applications sont privées par défaut. Les tests de Claroc le contredisent. Ars Technica n'a reçu aucune réponse à ses questions complémentaires.

La chronologie est elle aussi révélatrice. Claroc a signalé la fuite un dimanche, n'a reçu aucune réponse et a mentionné Musk et le responsable de Grok sur X. Les liens vers les 24 applications internes n'ont disparu que quelques heures après la demande des journalistes. Les autres données sont restées accessibles.

Le problème dépasse Grok. Lovable, Bolt et Replit attribuent aussi à chaque application sa propre adresse, si bien que leurs traces DNS sont les mêmes. Simplement, c'est dans Grok qu'on a trouvé le plus de données d'entreprise sensibles. Meta Muse a récemment suspendu sa fonction de partage après une fuite similaire. Claude artifacts, ChatGPT share et Gemini share sont conçus correctement : le secret se trouve dans le chemin, et le DNS ne le voit pas.

Que faire concrètement

Si vous ou votre équipe avez construit quelque chose dans Grok Build, commencez par ouvrir les paramètres de toutes les applications et passez l'accès sur « invités » ou « vous uniquement ». Il convient de faire la même vérification dans Lovable, Bolt et Replit. N'oubliez pas qu'un lien qui est une fois entré dans le passive DNS a pu déjà atterrir dans des bases tierces. Si l'application contenait des données personnelles ou des offres commerciales, fermez l'accès et évaluez s'il faut prévenir les personnes concernées et les clients.

Pour ceux qui construisent des plateformes avec des liens de partage, la leçon est la suivante. Le secret-capability ne doit jamais figurer dans le nom d'hôte, seulement dans le chemin ou dans un jeton placé après le domaine. Pour les outils internes, il vaut mieux activer d'emblée l'authentification, et faire de l'accès public un choix conscient plutôt qu'une valeur par défaut.

Il y a aussi des réserves. Les chiffres proviennent de l'étude de Claroc, et il n'existe pas encore de vérification indépendante. Une application publique ne contient pas forcément de données sensibles, et beaucoup des 35 000 peuvent n'être que des démos. SpaceXSI n'a pas expliqué comment des documents internes se sont retrouvés dans des applications ouvertes, ni si elle préviendra ses clients. Mais la conclusion principale demeure : le vibe coding accélère la mise en production, et avec elle les erreurs de configuration des accès. L'habitude du « généré et partagé » doit inclure de vérifier qui exactement pourra ouvrir le lien.