needhelp
← Zurück zum Blog

Die Grok Build CLI hat dein komplettes Repo hochgeladen — inklusive .env-Dateien

von needhelp
Security
AI Agent
Privatsphäre
xAI

Ein Forscher mit dem Namen cereblab fand heraus, dass xAIs Grok Build CLI, Version 0.2.93, ganze Git-Repositories in einen Google-Cloud-Storage-Bucket kopierte — Secrets, komplette Historie, alles — ohne den Nutzer zu informieren.

Was passiert ist

Das Tool stellte zwei Arten ausgehender Anfragen. Modell-Durchläufe gingen an POST /v1/responses. Ein separater POST /v1/storage-Aufruf dagegen packte den gesamten Working Tree samt kompletter .git-Historie und schickte ihn an gs://grok-code-session-traces.

Der Bucket gehört xAI. Der Upload lief als Nebeneffekt der bloßen Nutzung der CLI — kein >>Export<<-Button, keine Abfrage, keine Warnung.

Die Zahlen sind gewaltig. Mit einem 12 GB großen Test-Repo und ohne dass das Modell tatsächlich Dateien las, übertrug /v1/responses etwa 192 KB. /v1/storage schickte 5,10 GiB in 73 Chunks. Das ist ein Faktor von 27.800×. Das Modell nutzte 192 KB Kontext; xAIs Server bekamen dein ganzes Repo.

Der Kanarientest

cereblab platzierte eine Datei namens never_read_canary.txt mit einem eindeutigen String. Der Prompt war wörtlich “Reply with exactly: OK. Do not read or open any files.” Das Modell hielt sich an den Text. Der Canary-String tauchte im hochgeladenen Paket wieder auf.

Die Exfiltration wurde also nicht dadurch ausgelöst, dass das Modell bei Bedarf Dateien las. Sie war eine eingebaute Pipeline, die unabhängig von deiner Anfrage lief.

Warum das Opt-out nicht funktionierte

Es gibt eine Einstellung namens >>Modell verbessern<<. Sie abzuschalten soll verhindern, dass deine Daten zum Training verwendet werden. cereblabs Aufzeichnung zeigte, dass der Server weiterhin trace_upload_enabled: true und upload_enabled: true zurückgab. Der Upload lief weiter.

Die CLI hat ein --deny-Flag, das einschränkt, welche Dateien das Modell lesen darf. Das blockiert nur Lesezugriffe. Gegen Netzwerk-Egress bewirkt es nichts — das Paket war bereits auf dem Weg nach draußen.

Der Gist bringt es unverblümt auf den Punkt: >>Ein Opt-out hält dein Repository nicht davon ab, den Rechner zu verlassen.<<

Das übergreifende Leck

Die Aufzeichnung zeigte, dass das Tool auch Dateien unter ~/.claude/ einsammelte. Das ist das Konfigurationsverzeichnis eines ganz anderen Produkts. Schlüssel für unabhängige Dienste — cereblab nennt einen Baidu-Miaoda-API-Schlüssel — verließen zusammen mit deinem Repo den Rechner.

Ein anderer Forscher, der die Ergebnisse reproduzierte, entdeckte 339 automatische Uploads in seinen Logs. Einer dieser Uploads enthielt sein gesamtes Home-Verzeichnis — potenziell inklusive SSH-Keys, Passwortmanager-Daten, Browser-Profilen, einfach alles.

Der Remote-Kill-Switch

Am 12. Juli, als die Geschichte viral ging, geschah etwas, das xAI nie angekündigt hat: Dieselbe Client-Binary, mit demselben SHA-256-Hash, bekam plötzlich andere Server-Antworten.

disable_codebase_upload: true. trace_upload_enabled: false.

Uploads stoppten. Kein Client-Update. Kein Changelog. Keine Benachrichtigung.

Das bedeutet: xAI hatte schön immer die Möglichkeit, die Datensammlung auf jeder Grok-CLI-Installation aus der Ferne ein- oder auszuschalten, jederzeit und ohne Wissen des Nutzers. Sie haben sich nur entschieden, sie standardmäßig eingeschaltet zu lassen und nie zu erwähnen.

Musk antwortet

Am 14. Juli antwortete Elon Musk auf die Kontroverse mit einem einzigen Wort: >>True.<< Er legte nach:

Als Vorsichtsmaßnahme werden alle Nutzerdaten, die vor jetzt zu SpaceXAI hochgeladen wurden, vollständig und restlos gelöscht. Absolut nichts wird übrig bleiben.<<

xAI kündigte gleichzeitig einen /privacy-Befehl für die Grok CLI an:

  • /privacy — zeigt deinen aktuellen Datenaufbewahrungsstatus
  • /privacy opt-out — deaktiviert die Aufbewahrung und löst die rückwirkende Löschung bereits synchronisierter Daten aus

Andrew Milich, Leiter von Grok Build, bestätigte, dass das Ändern der Datenschutzeinstellungen die Löschung zuvor synchronisierter Cloud-Daten auslöst. Enterprise-Kunden erhalten den >>Zero Data Retention<<-Modus (ZDR).

Aber was sich nicht geändert hat: Es gab keine Sicherheitswarnung. Keine Erklärung, warum ganze Repositories ohne Zustimmung gesammelt wurden. Kein unabhängiges Audit der Löschung. Das v0.2.98-Changelog erwähnte Repository-Uploads mit keinem Wort.

So prüfst du, ob du betroffen bist

  • Starte die CLI hinter einem MITM-Proxy: HTTPS_PROXY=http://127.0.0.1:8080. Achte auf POST /v1/storage-Aufrufe an den Bucket grok-code-session-traces.
  • Durchsuche das Binary bzw. die Strings nach dem hartkodierten Bucket-Namen grok-code-session-traces.
  • cereblabs Repro-Repo enthält ein verify.sh, das die zurückgesendeten Pakete erneut herunterlädt und entpackt, damit du genau siehst, was den Rechner verlassen hat.
  • Prüfe ausgehende Egress-Logs auf Traffic zu Google Cloud Storage während einer Grok-CLI-Sitzung.
  • Führe /privacy in der Grok CLI aus, um deinen aktuellen Datenaufbewahrungsstatus zu sehen.
  • Ein anderer Forscher fand 339 Uploads allein durch die Prüfung seiner Logs — wenn du das Tool überhaupt genutzt hast, geh davon aus, dass deine Repos den Rechner verlassen haben.

Was du tun solltest

  • Führe sofort /privacy opt-out aus, um die weitere Datenaufbewahrung zu deaktivieren und die Löschung bereits hochgeladener Daten zu beantragen.
  • Deinstalliere die betroffene Version (0.2.93) vollständig.
  • Blockiere Egress zu Google Cloud Storage auf Netzwerkebene — eine Firewall-Regel oder eine Clash-Reject-Regel: (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com).
  • Falls du das Tool weiternutzen musst, füge in ~/.grok/config.toml hinzu: 
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • Rotiere jede einzelne Credential, die jemals in einem Repo lag, das du mit dieser Version geöffnet hast. .env-Dateien werden oft getrackt oder liegen im Working Tree, und .gitignore schützt dich nicht — das Paket enthielt getrackte Dateien sowieso. Behandle alles als kompromittiert.

Daten lassen sich löschen. Vertrauen nicht so einfach.

Referenzen

Diese Seite teilen