needhelp
← Retour au blog

La CLI Grok Build à discrètement téléversé tout votre dépôt — fichiers .env inclus

par needhelp
Security
AI Agent
Confidentialité
xAI

Un chercheur se faisant appeler cereblab à découvert que la CLI Grok Build de xAI, version 0.2.93, copiait des dépôts git entiers — secrets, historique complet, tout — vers un bucket Google Cloud Storage sans en informer l’utilisateur.

Ce qui s’est passé

L’outil effectuait deux types de requêtes sortantes. Les tours du modèle partaient vers POST /v1/responses. Mais un appel distinct POST /v1/storage emballait l’arbre de travail complet ainsi que tout l’historique .git et l’expédiait vers gs://grok-code-session-traces.

Ce bucket appartient à xAI. Le téléversement se déclenchait comme un simple effet de bord de l’utilisation de la CLI — aucun bouton << exporter >>, aucune invite, aucun avertissement.

Les chiffres donnent le vertige. Avec un dépôt de test de 12 Go et aucun fichier réellement lu par le modèle, /v1/responses a transmis environ 192 Ko. /v1/storage a envoyé 5,10 Gio en 73 segments. Un écart de 27 800×. Le modèle a utilisé 192 Ko de contexte ; les serveurs de xAI ont reçu l’intégralité de votre dépôt.

Le test canari

cereblab a placé un fichier nommé never_read_canary.txt contenant une chaîne unique. Le prompt était littéralement “Reply with exactly: OK. Do not read or open any files.” Le modèle s’est conformé au texte. La chaîne canari a été retrouvée dans le paquet téléversé.

L’exfiltration n’était donc pas déclenchée par le modèle lisant des fichiers à la demande. C’était une pipeline intégrée qui s’exécutait quoi que vous demandiez.

Pourquoi l’opt-out n’a pas fonctionné

Il existe un réglage intitulé << Améliorer le modèle >>. Le désactiver est censé empêcher l’utilisation de vos données pour l’entraînement. La capture de cereblab a montré que le serveur renvoyait toujours trace_upload_enabled: true et upload_enabled: true. Le téléversement continuait.

La CLI dispose d’un drapeau --deny qui restreint les fichiers que le modèle peut lire. Cela bloque uniquement les lectures. Cela ne fait rien contre le trafic réseau sortant — le paquet était déjà en chemin.

Le gist résume la conclusion sans détour : << Se désinscrire n’empêche pas votre dépôt de quitter la machine. >>

La fuite inter-outils

La capture a montré que l’outil récupérait aussi les fichiers sous ~/.claude/. C’est le répertoire de configuration d’un produit complètement différent. Des clés pour des services sans aucun rapport — cereblab cite une clé API Baidu Miaoda — quittaient la machine en même temps que votre dépôt.

Un autre chercheur ayant reproduit les résultats à découvert 339 téléversements automatiques dans ses logs. L’un de ces téléversements contenait l’intégralité de son répertoire personnel — exposant potentiellement des clés SSH, des données de gestionnaire de mots de passe, des profils de navigateur, absolument tout.

L’interrupteur à distance

Le 12 juillet, alors que l’histoire devenait virale, quelque chose que xAI n’a jamais annoncé s’est produit : le même binaire client, avec la même empreinte SHA-256, à soudainement commencé à recevoir des réponses différentes du serveur.

disable_codebase_upload: true. trace_upload_enabled: false.

Les téléversements se sont arrêtés. Aucune mise à jour du client. Aucun changelog. Aucune notification.

Cela signifie que xAI à toujours eu la capacité d’activer ou de désactiver à distance la collecte de données sur n’importe quelle installation de la CLI Grok, à tout moment, sans que l’utilisateur le sache. Ils ont simplement choisi de la laisser activée par défaut et de ne jamais en parler.

Musk répond

Le 14 juillet, Elon Musk a répondu à la controverse par un seul mot : << True. >> Il a ajouté :

<< Par mesure de précaution, toutes les données utilisateur qui ont été téléversées vers SpaceXAI jusqu’à présent seront complètement et totalement supprimées. Il ne restera absolument rien. >>

xAI à simultanément annoncé une commande /privacy pour la CLI Grok :

  • /privacy — affiche votre statut actuel de rétention des données
  • /privacy opt-out — désactive la rétention et déclenche la suppression rétrospective des données déjà synchronisées

Andrew Milich, responsable de Grok Build, a confirmé que la modification des paramètrès de confidentialité déclenche la suppression des données cloud précédemment synchronisées. Les clients enterprise bénéficient du mode << Zero Data Retention >> (ZDR).

Mais voici ce qui n’a pas changé : aucun avis de sécurité n’a été émis. Aucune explication sur les raisons pour lesquelles des dépôts entiers ont été collectés sans consentement. Aucun audit indépendant de la suppression. Le changelog de la v0.2.98 à complètement omis toute mention des téléversements de dépôts.

Comment vérifier si vous êtes concerné

  • Exécutez la CLI derrière un proxy MITM : HTTPS_PROXY=http://127.0.0.1:8080. Surveillez les appels POST /v1/storage ciblant le bucket grok-code-session-traces.
  • Recherchez dans le binaire / les chaînes le nom du bucket codé en dur grok-code-session-traces.
  • Le dépôt de reproduction de cereblab fournit un verify.sh qui re-télécharge et décompresse les paquets retournés pour que vous puissiez voir exactement ce qui est sorti.
  • Vérifiez les logs de trafic sortant vers Google Cloud Storage pendant toute session de la CLI Grok.
  • Exécutez /privacy dans la CLI Grok pour voir votre statut actuel de rétention des données.
  • Un autre chercheur a trouvé 339 téléversements rien qu’en vérifiant ses propres logs — si vous avez utilisé l’outil ne serait-ce qu’une fois, partez du principe que vos dépôts ont quitté la machine.

Que faire

  • Exécutez /privacy opt-out immédiatement pour désactiver la rétention future et demander la suppression des données déjà téléversées.
  • Désinstallez complètement la version concernée (0.2.93).
  • Bloquez le trafic sortant vers Google Cloud Storage au niveau réseau — une règle de pare-feu ou une règle de rejet Clash : (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com).
  • Si vous devez absolument continuer à l’utiliser, ajoutez à ~/.grok/config.toml : 
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • Rotationnez chaque identifiant qui a pu se trouver dans un dépôt ouvert avec cette version. Les fichiers .env sont souvent suivis ou se trouvent dans l’arbre de travail, et .gitignore ne vous protège pas — le paquet contenait les fichiers suivis quoi qu’il arrive. Considérez tout comme compromis.

Les données peuvent être supprimées. La confiance, c’est moins simple.

Références

Partager cette page