Grok Build CLI 0.2.93 : une analyse au niveau du réseau révèle des uploads silencieux de dépôts entiers, des secrets non masqués et un bouton de désactivation inefficace

Un chercheur en sécurité indépendant de Cereblab (@cereblab) a réalisé une analyse reproductible au niveau du réseau de Grok Build CLI version 0.2.93 d'xAI en utilisant mitmproxy, et a publié son analyse complète sous forme de Gist GitHub . L'analyse a mis au jour trois failles de sécurité majeures qui contredisent directement le positionnement « local-first » de l'entreprise et violent les attentes des développeurs en matière de confidentialité des données.

Des comportements d'exfiltration de données contraires au marketing « local-first »

Le chercheur a identifié deux canaux de données matériellement différents quittant la machine du développeur :

• Le canal des échanges avec le modèle (POST /v1/responses) : les fichiers ouverts par l'agent étaient sérialisés dans les requêtes du modèle. C'est le comportement attendu d'un agent de codage cloud.
• Le canal de stockage (POST /v1/storage) : l'intégralité du dépôt était emballée indépendamment sous forme de git bundle et téléchargée en morceaux d'environ 75 Mo vers un bucket Google Cloud Storage nommé grok-code-session-traces .

L'écart d'échelle a prouvé que le téléchargement n'était pas motivé par ce que l'agent lisait. Sur un dépôt test de 12 Go, le canal de stockage a déplacé 5,10 Gio en 73 morceaux (tous avec un code HTTP 200), tandis que le canal des échanges avec le modèle n'a déplacé que 192 Ko — un rapport d'environ 27 800 pour 1 . Même avec l'invite « réponds OK, ne lis aucun fichier », l'outil a téléchargé l'intégralité du dépôt sous forme de git bundle ; le clonage du bundle capturé a permis de récupérer un fichier (src/_probe/never_read_canary.txt) que l'agent avait explicitement pour instruction de ne pas ouvrir, ainsi que l'historique complet des commits Git .

Types de secrets et de fichiers transmis sans masquage

• Les fichiers .env contenant des clés API, des mots de passe de bases de données et d'autres identifiants ont été transmis textuellement, sans masquage ni caviardage via les deux canaux . Dans des tests contrôlés, un fichier de 48 Ko contenant des identifiants de base de données et des clés API est apparu en clair dans le corps de la requête .
• Chaque fichier suivi dans le dépôt, ainsi que l'historique Git complet (tous les commits, branches, tags), a été empaqueté et téléchargé . Cela signifie que les secrets supprimés il y a des mois mais qui ont été divulgués peuvent encore exister dans les données téléchargées.
• Le mécanisme de téléchargement a été identifié comme une caisse Rust propriétaire (xai-data-collector) résidente dans le binaire, avec des chemins source comme crates/codegen/xai-data-collector/src/gcs.rs et crates/codegen/xai-grok-shell/src/upload/ .
• Sur une base de code réelle de 12 Go de fichiers aléatoires jamais lus, le point de terminaison de stockage a accepté les téléchargements sans aucun rejet basé sur la taille ; les seules réponses non-200 étaient des erreurs de quota d'utilisation du modèle (402/429), pas des échecs de stockage .

Échec du bouton de désactivation

Le chercheur a testé le bouton de confidentialité « Améliorer le modèle » et a constaté qu'il n'empêchait pas les téléchargements .

• Après avoir désactivé le bouton et redémarré, le point de terminaison des paramètres du serveur renvoyait toujours trace_upload_enabled: true .
• Le canal de stockage a continué d'accepter les téléchargements de git bundles en morceaux avec des réponses HTTP 200 .
• Une option de configuration disable_codebase_upload=true existe dans les paramètres du harnais, mais sa relation avec le comportement côté serveur n'est pas documentée, et les tests du chercheur ont montré que le serveur ne respectait pas les préférences du client .

Recommandations pour les développeurs concernés

Le chercheur original et les sites d'analyse ultérieurs recommandent ce qui suit :

Actions immédiates pour les équipes qui ont utilisé Grok Build CLI sur des dépôts privés :

• Faites tourner tous les identifiants qui existaient dans un fichier .env, un fichier de configuration ou l'historique Git au sein des dépôts utilisés avec Grok Build, car ils peuvent avoir été transmis et stockés dans le bucket GCS grok-code-session-traces .
• Auditez l'historique Git à la recherche de secrets qui ont pu exister dans un commit passé, puisque la CLI a envoyé l'historique complet des commits .
• Partez du principe que les données ont été stockées, pas seulement transmises — le serveur a renvoyé un HTTP 200 pour toutes les requêtes de stockage, confirmant l'acceptation .
• Demandez à xAI si le bucket a été supprimé, quels contrôles d'accès existaient, et si un accord de traitement des données le couvrait (aucun n'a été publié au moment de la divulgation) .

Mesures d'atténuation architecturales pour tout agent de codage :

• Exécutez les agents dans des conteneurs/machines virtuelles avec uniquement le répertoire de la tâche monté, pas de répertoire personnel, pas d'agent SSH, pas de socket Docker et aucun répertoire d'identifiants cloud exposé .
• Mettez en place des contrôles de trafic sortant : autorisez les points de terminaison d'inférence de modèle et les hôtes d'authentification, mais refusez les téléchargements génériques directs vers un stockage d'objets. Alertez en cas de transferts dépassant 100 Mo .
• Utilisez la capture de paquets à l'échelle de l'hôte, la journalisation DNS et la télémétrie réseau des terminaux pour détecter les téléchargements par des processus de coordination en arrière-plan que les compteurs d'octets de premier plan manqueraient .
• Testez les invites minimales et maximales sous capture réseau — les cas où l'agent ne doit pas lire de fichiers sont essentiels pour détecter l'exfiltration au-delà de la fenêtre de contexte .
• Exécutez au moins trois cas d'invite : (1) « réponds OK, ne lis aucun fichier », (2) lis un fichier spécifique, (3) inspecte le langage du projet — puis comparez les octets par point de terminaison .