Das CLI-Tool Grok Build von xAI, das zur Unterstützung beim Schreiben von Code gedacht ist, lud nach Angaben eines Forschers in den Cloud-Speicher von xAI nicht nur die für die jeweilige Aufgabe benötigten Dateien hoch, sondern ganze Git-Repositories mitsamt vollständiger Commit-Historie. Das Problem betraf mindestens Version 0.2.93 und potenziell jeden Entwickler, der das Tool vor dem 13. Juli genutzt hat. Dabei verhinderte die Benutzereinstellung zum Ablehnen des Modeltrainings die Datenübertragung nicht. Allen, die mit Grok Build gearbeitet haben, wird empfohlen, umgehend sämtliche Secrets zu rotieren, die in verfolgten Dateien oder in der Commit-Historie enthalten gewesen sein könnten.
Was die Analyse des Netzwerkverkehrs zeigte
Der unter dem Pseudonym cereblab publizierende Forscher führte eine detaillierte Analyse des Netzwerkverkehrs von Grok Build Version 0.2.93 durch. Das Tool nutzte zwei getrennte Datenkanäle: einen für die Interaktion mit der Sprachmodell-API über den Endpoint /v1/responses, den anderen für das Hochladen von Daten in den Speicher über /v1/storage.
Das Ausmaß der Diskrepanz zwischen diesen Kanälen ist aufschlussreich. Bei einem Repository mit einer Größe von 12 GB, dessen Dateien vom Modell nicht gelesen wurden, betrug der Traffic zum Modell etwa 192 KB, während über den Speicherkanal 5,10 GiB übertragen wurden – ein Unterschied um ungefähr den Faktor 27 800. Der Upload erfolgte in 73 Fragmenten zu jeweils ~75 MB, von denen jedes eine HTTP-200-Antwort erhielt. Das Upload-Volumen skalierte den Angaben zufolge proportional zur Größe des Repositories.
Der Ziel-Speicher — der Bucket grok-code-session-traces in Google Cloud Storage — wurde sowohl in der Binärdatei des Tools als auch in der Zwischendatei metadata.json identifiziert, die Pfade der Form gs://grok-code-session-traces/ enthielt.
Canary-Test und Problem der Secrets
Zum Nachweis der Übertragung platzierte der Forscher im Repository die Datei src/_probe/never_read_canary.txt mit einem eindeutigen Marker und wies den Agenten ausdrücklich an, diese Datei nicht zu öffnen. Nach Abfangen des hochgeladenen Bundles und dessen Klonen wurde die Canary-Datei wortgetreu wiederhergestellt, zusammen mit der vollständigen Commit-Historie. Der Test wurde an einem zweiten, nicht verbundenen Repository mit demselben Ergebnis wiederholt.
Ein separates Problem betraf den Umgang mit Secrets. Als Grok im Rahmen einer Aufgabe die verfolgte Datei .env las, wurden deren Inhalte — einschließlich der Testwerte API_KEY und DB_PASSWORD — unverändert in den Modellkontext übertragen und zusätzlich im Archiv session_state gespeichert, das an den Speicher gesendet wurde. Die in dem Test verwendeten Secrets waren zwar Platzhalter, doch der Mechanismus selbst — die Übermittlung und Speicherung von Zugangsdaten ohne Filterung — stellt ein systemisches Risiko dar.
Wichtig: Die Untersuchung hält den Umstand der Übermittlung, des Empfangs und der Speicherung von Daten fest, behauptet jedoch nicht, dass xAI den Code zum Training des Modells genutzt hat oder dass Mitarbeiter des Unternehmens darauf zugegriffen haben. Es wird außerdem vermerkt, dass Dateien aus der .gitignore, die nie in Commits gelangten, nicht in das Bundle aufgenommen wurden.
Die Datenschutzeinstellung funktionierte nicht wie erwartet
Ein zentraler Aspekt des Vorfalls ist das Verhalten der Benutzereinstellungen. Nach Angaben des Forschers lud das Tool auch bei deaktivierter Option „Improve the model“ weiterhin das Repository hoch, und die Serverantwort auf die Anfrage /v1/settings enthielt weiterhin trace_upload_enabled: true. Das bedeutet, dass der Schalter lediglich die Nutzung der Daten zum Trainieren des Modells steuerte, nicht aber den eigentlichen Versand des Codes vom Rechner des Nutzers. Zwei unterschiedliche Mechanismen — Datenübertragung und deren Verwendung für das Training — waren getrennt, doch der Nutzer konnte nur den zweiten steuern.
Vergleich mit Wettbewerbern
In einer vergleichenden Analyse, die vom selben Forscher durchgeführt wurde, sendeten Claude Code und Codex keine Repository-Bundles. Gemini übermittelte im Test ohne aktive Aufgabe kein Bundle, wobei der Test mit einer realen Aufgabe aufgrund ausgeschöpfter Quote nicht abgeschlossen wurde. Grok Build erwies sich als das einzige Tool, das einen massenhaften Upload des Arbeitsverzeichnisses durchführte. Gleichzeitig senden alle Cloud-basierten Coding-Tools die Dateien, die sie öffnen — ein vollständig lokales Arbeitsmodell ist auf sie nicht anwendbar.
Reaktion von xAI und aktueller Status
Am 13. Juli stellte dieselbe Binärdatei der Version 0.2.93 die Anfragen an /v1/storage ein. Der Forscher führte sechs Wiederholungstests durch — ohne einen einzigen Upload zum Speicher. Der Server begann, disable_codebase_upload: true und trace_upload_enabled: false zurückzugeben. Da der Client auf derselben Version verblieb, handelte es sich um eine serverseitige Deaktivierung und nicht um ein Anwendungs-Update. Entwickler Peter Dedene bestätigte eine entsprechende Änderung der Flags auf seinem Account.
Das Unternehmen xAI reagierte über Beiträge auf X und nicht über eine formelle Sicherheitsmitteilung. Der Account @SpaceXAI teilte mit, dass Unternehmenskunden mit Zero Data Retention (ZDR) nie einer Speicherung von Code oder Traces ausgesetzt waren und dass Einzelanwender im CLI den Befehl /privacy ausführen können, um die Speicherung zu deaktivieren und die Löschung zuvor synchronisierter Daten zu veranlassen. Elon Musk erklärte, dass alle zuvor hochgeladenen Nutzerdaten „vollständig und bedingungslos gelöscht“ würden; diese Aussage erfolgte jedoch in einem sozialen Netzwerk ohne begleitende technische Dokumentation.
Ein wesentliches Detail: Eine unabhängige Analyse der Version 0.2.99 zeigte, dass der Upload-Code weiterhin in der Binärdatei vorhanden ist, aber durch ein Server-Flag deaktiviert wurde. Das bedeutet, dass xAI die Funktionalität ohne Veröffentlichung eines Client-Updates wieder aktivieren kann.
Empfehlungen
- Rotation von Secrets: Ersetzen Sie alle Zugangsdaten, die Grok Build lesen konnte — Inhalte verfolgter Dateien sowie Daten aus der Commit-Historie, einschließlich Secrets, die einst committet und später aus dem Arbeitsbaum entfernt wurden. Das Löschen einer Datei aus dem aktuellen Branch entfernt sie nicht aus der Git-Historie.
- Befehl /privacy: Wenn Sie Grok Build weiterhin verwenden, führen Sie
/privacyim CLI aus, um die Speicherung zu deaktivieren und die Löschung zuvor synchronisierter Daten zu beantragen. - Audit des Netzwerkverkehrs: Überwachen Sie beim Einsatz beliebiger Cloud-basierten Coding-Tools den ausgehenden Traffic. Das vom Tool gesendete Datenvolumen sollte der ausgeführten Aufgabe angemessen sein.
- Speicherung von Secrets: Legen Sie keine realen Zugangsdaten in von Git verfolgten Dateien ab. Nutzen Sie Secret-Manager und Umgebungsvariablen, die aus geschützten Speichern geladen werden.
xAI hat bisher keine formelle Sicherheitsmitteilung veröffentlicht und drei zentrale Fragen nicht beantwortet: warum vollständige Repositories standardmäßig hochgeladen wurden, wie lange die Daten gespeichert wurden und wie viele Nutzer betroffen sind. Der Upload-Code verbleibt in der Binärdatei und wird durch ein Server-Flag gesteuert, das jederzeit geändert werden kann. Für Entwickler, die mit Grok Build gearbeitet haben, hat die Rotation sämtlicher Secrets, die jemals in verfolgte Dateien oder die Commit-Historie der betroffenen Repositories gelangt sind, oberste Priorität.
