Grok a été surpris en train de télécharger l'intégralité de votre base de code

BBetter Stack
컴퓨터/소프트웨어경제 뉴스AI/미래기술

스크립트

00:00:00Grok a téléchargé tout mon répertoire utilisateur sur les serveurs de xAI, il contient mes clés SSH, mon mot de passe
00:00:05de base de données, mes documents, photos, vidéos, tout. L'interface en ligne de commande de Grok a téléchargé
00:00:10tout votre dépôt et votre historique git, y compris les fichiers qu'il était censé ne pas ouvrir et les secrets supprimés de
00:00:16l'historique. C'est une erreur grave et massive de l'équipe de Grok, alors analysons
00:00:20ce qui s'est passé, comment vérifier si votre code a été téléchargé et ce que xAI a fait pour corriger cela.
00:00:29J'ai découvert cela grâce à ce tweet conseillant aux gens d'exécuter cette commande grep pour lire
00:00:33les journaux de Grok, en disant que vous seriez furieux. Il montre une photo du journal indiquant la mise en file d'attente d'un dépôt
00:00:38pour un téléchargement sur les serveurs de Grok. Ce tweet a des centaines de réponses et de citations de personnes exécutant cette commande
00:00:42et obtenant un résultat similaire, et même un utilisateur ayant exécuté Grok dans son répertoire personnel rapportant qu'ils
00:00:47avaient tout téléchargé. D'autres enquêtes montrent qu'il intègre un collecteur de code en arrière-plan semblable à un logiciel malveillant.
00:00:52Regardons donc ce qu'il faisait réellement. Il s'agit d'un rapport d'un chercheur appelé cereblab
00:00:56qui a utilisé mitmproxy pour inspecter le trafic que l'interface CLI de Grok envoyait et recevait. Ils ouvrent Grok dans
00:01:02un dépôt et la seule instruction qu'ils lui ont envoyée était “réponds ok, n'ouvre aucun fichier”. Il s'avère
00:01:07cependant que cette instruction n'a pas d'importance car Grok a quand même téléchargé l'intégralité du dépôt. Il y avait une
00:01:12requête POST qui a été envoyée contenant tout le bundle du dépôt, et ce bundle contenait tout l'historique git
00:01:16et même les variables d'environnement. C'est ce que je trouve si grave dans tout cela. Oui, nous savons tous que lorsque
00:01:21nous utilisons un modèle distant, le code est envoyé sur leurs serveurs, mais il y a normalement une supposition
00:01:26que seul le code qui doit réellement être lu est envoyé, pas l'intégralité de la base de code,
00:01:30même quand ce n'est pas pertinent pour la requête. Ils ont même montré que cela fonctionnait quand un dépôt faisait 12 gigaoctets.
00:01:35Il télécharge toujours tout. Tester cela dans d'autres outils comme Claude Code, Cursor et Gemini
00:01:40montre qu'ils n'envoient que le fichier qu'ils lisent. C'est un problème unique à l'interface CLI de Grok. Ils ont même découvert
00:01:45que si vous désactiviez le paramètre “aider à améliorer ce modèle”, il continuerait à le faire, et en récupérant l'utilisateur
00:01:51qu'il existait en fait un drapeau appelé “trace upload enable” qui était toujours réglé sur vrai. Maintenant, tous
00:01:55ces tweets et ce message ont commencé à devenir viraux. Alors comment xAI a-t-il réagi ? Eh bien, d'abord, ils ont fait un peu
00:02:01une correction silencieuse. Si vous essayiez à nouveau un jour plus tard, après que le message soit devenu viral, les paramètres montraient que
00:02:05ce drapeau “trace upload” était maintenant désactivé et qu'il y avait en fait un nouveau appelé “disable codebase upload”
00:02:10qui était réglé sur vrai apparemment pour le compte de tout le monde. Ils avaient donc mis en place un kill switch côté serveur
00:02:14pour le téléchargement du code. Peu après, ils ont aussi répondu publiquement sur Twitter en disant : “Nous nous soucions
00:02:19profondément de votre vie privée et respectons le choix du client. Pour les équipes utilisant la rétention de données zéro, aucune trace et
00:02:24aucune donnée de code n'est conservée. Toute utilisation de la clé API de la build Grok respecte également la rétention de données zéro. Si la rétention de
00:02:30données est désactivée, la commande /privacy est disponible dans l'interface CLI pour désactiver la rétention de données
00:02:36ce qui supprime également les données précédemment synchronisées. Exécutez la commande /privacy pour voir ou modifier vos
00:02:40paramètres à tout moment”. Elon a aussi tweeté en disant qu'en guise de mesure de précaution, toutes les données utilisateur qui ont été
00:02:45téléchargées sur xAI jusqu'à présent seront complètement et totalement supprimées. Zéro quoi que ce soit
00:02:51ne restera. Mais vous avez aussi demandé dans un autre tweet de laisser le paramètre activé car c'est en fait utile
00:02:55pour déboguer des problèmes s'ils peuvent conserver une certaine quantité de données, ce que je peux croire. Si nous étions juste
00:03:00en train de parler de traces, c'est une pratique assez courante, mais télécharger un dépôt entier sur leurs serveurs
00:03:05aucune de ces réponses ne semble aborder cette partie, et la nouvelle mise à jour de l'interface CLI de Grok a simplement ajouté une commande
00:03:10de confidentialité, mais il est important de noter que cette mise à jour n'a pas réellement supprimé le code qui télécharge tout votre
00:03:14dépôt. Vous pouvez en fait toujours trouver cela dans le binaire, donc il semble que la seule chose qui empêche cela de se remettre
00:03:18en marche est ce drapeau côté serveur qui est contrôlé par xAI. Il me semble vraiment que ce code
00:03:23ne devrait pas être là, car aucun autre outil ne l'utilise. De plus, si nous examinons cette nouvelle commande de confidentialité,
00:03:28celle-ci désactive simplement les traces et bascule l'interrupteur côté serveur appelé “coding data retention opt-out”
00:03:33et le même chercheur a en fait analysé cette commande et montré qu'elle ne fait rien localement. Vos
00:03:38traces de session sont toujours envoyées à xAI en entier, que ce soit activé ou désactivé, et la seule différence réside dans
00:03:43la manière dont le serveur répond. S'il est désactivé, il va répondre avec un code 200 signifiant que cela a été stocké
00:03:48et si le mode de confidentialité est activé, il retourne simplement un 204 pour dire aucun contenu et que les données ont été écartées.
00:03:53C'est donc en réalité seulement un interrupteur de rétention côté serveur et cela ne le bloque pas côté client, donc
00:03:58vous transmettez toujours tout, vous devez juste faire confiance au fait que les serveurs de xAI vont réellement
00:04:02l'écarter au lieu de le stocker. Même si je faisais confiance à xAI, cela empire, car cette commande de confidentialité
00:04:07est en fait un interrupteur de rétention par session, vous devrez donc peut-être l'activer à chaque session pour garder
00:04:12vos données en sécurité. Cela me semble incroyablement rétrograde, mais c'est là où nous en sommes maintenant. Si vous avez utilisé
00:04:17l'interface CLI de Groc dans le passé et que vous voulez voir ce qui a pu fuiter de votre machine, vous pouvez vérifier vos
00:04:21journaux. Cette commande grep vous montre exactement quelles sessions ont déclenché les téléchargements. Si vous prenez la sécurité
00:04:26au sérieux également, vous voudrez probablement faire pivoter toutes ces clés s'il s'avère qu'une partie
00:04:30de ces données a été envoyée, à moins que vous ne fassiez entièrement confiance au fait que xAI a supprimé tout cela. Enfin, si vous voulez
00:04:35garder une once de confidentialité tout en utilisant l'interface CLI de Groc, bien que je ne le recommanderais probablement pas,
00:04:40il y a un très bon compte rendu ici sur la façon dont vous pouvez renforcer l'interface CLI de Groc et il vous montre où
00:04:44définir des éléments comme “disabled codebase upload” dans votre configuration, ce qui devrait arrêter brutalement ce pipeline de téléchargement. Donc,
00:04:49voilà l'histoire : pour une raison quelconque, Groc téléchargeait tout votre dépôt même quand il n'en avait pas besoin, et ils
00:04:53semblent avoir supprimé toutes ces données maintenant et fait marche arrière sur la fonctionnalité, mais je veux savoir : faites-vous
00:04:58leur confiance et utiliseriez-vous l'interface CLI de Groc dorénavant, maintenant que vous savez cela ? Dites-le-moi dans
00:05:02les commentaires ci-dessous. Attendez, abonnez-vous et, comme toujours, à la prochaine.

핵심 요약

L'interface en ligne de commande de Grok exfiltrait par défaut l'intégralité des dépôts de code utilisateur vers les serveurs de xAI, une pratique que les correctifs récents tentent de limiter via des filtres côté serveur sans modifier le comportement de collecte côté client.

하이라이트

  • L'interface de ligne de commande (CLI) de Grok téléchargeait systématiquement l'intégralité du dépôt Git local, y compris les fichiers exclus, les secrets supprimés et les variables d'environnement.

  • Des tests via mitmproxy ont démontré que Grok téléchargeait l'intégralité d'un dépôt de 12 Go même lorsque la consigne explicite était de ne lire aucun fichier.

  • L'option de désactivation du partage de données dans les paramètres était inefficace, car le drapeau interne “trace upload enable” restait activé par défaut.

  • xAI a réagi en introduisant un interrupteur côté serveur (“kill switch”) pour empêcher le téléchargement automatique des dépôts.

  • La nouvelle commande /privacy dans l'interface CLI de Grok ne bloque pas le transfert des données côté client, mais demande simplement au serveur de ne pas les conserver.

  • L'analyse révèle que le binaire de l'outil CLI contient toujours le code responsable du téléchargement massif des données.

타임라인

Découverte de l'exfiltration massive de données

  • L'interface CLI de Grok accédait à l'intégralité des répertoires utilisateurs, incluant clés SSH et mots de passe de base de données.
  • Le comportement de collecte s'apparentait à celui d'un logiciel malveillant en arrière-plan.
  • La pratique incluait l'historique Git complet et les fichiers explicitement non destinés à être lus.

Des utilisateurs ont identifié via des journaux de commande que Grok mettait systématiquement en file d'attente l'intégralité des dépôts locaux pour un téléchargement. Ce problème affectait même les répertoires personnels contenant des données sensibles. La communauté a rapidement confirmé ce comportement via l'exécution de commandes grep sur les logs de l'outil.

Analyse technique du comportement de l'outil

  • L'inspection du trafic via mitmproxy a confirmé l'envoi d'une requête POST contenant l'ensemble du dépôt.
  • Le volume des données envoyées restait total, indépendamment de la taille du dépôt ou des instructions données à l'IA.
  • Le paramètre utilisateur censé empêcher l'amélioration du modèle n'avait aucun impact sur ce transfert massif.

Des chercheurs ont utilisé mitmproxy pour intercepter le trafic sortant de l'interface CLI de Grok. Malgré des instructions directes demandant de ne lire aucun fichier, l'outil transmettait l'intégralité de la base de code aux serveurs de xAI. Contrairement à d'autres outils comme Claude Code ou Cursor, Grok n'isolait pas les fichiers nécessaires à la requête.

Réponse de xAI et mesures correctives

  • xAI a déployé une correction silencieuse côté serveur pour désactiver le téléchargement automatique des dépôts.
  • Une nouvelle commande /privacy a été ajoutée pour gérer la rétention des données.
  • L'interrupteur de confidentialité ne bloque pas l'envoi des données côté client, mais demande au serveur de ne pas les stocker.

Suite à la viralité du problème, xAI a activé un interrupteur côté serveur pour stopper l'upload des dépôts. Elon Musk a promis la suppression totale des données collectées. Cependant, l'analyse technique montre que le binaire de l'outil continue d'effectuer les transferts, et que la commande /privacy agit uniquement comme un flag de rétention, faisant toujours transiter les données par les serveurs de xAI.

Recommandations de sécurité

  • La vérification des logs est nécessaire pour identifier les sessions ayant déclenché des téléchargements.
  • La rotation des clés API et secrets est fortement recommandée par mesure de précaution.
  • Il est possible de configurer manuellement “disabled codebase upload” pour stopper le flux de données.

Pour les utilisateurs ayant exploité la CLI de Grok, il est essentiel d'examiner les logs pour identifier les fuites potentielles. Bien qu'une configuration manuelle puisse bloquer le pipeline de téléchargement, la confiance envers l'outil est remise en question. Le maintien de la sécurité exige une vigilance accrue et une rotation systématique des secrets potentiellement exposés.

커뮤니티 글

모든 글 보기