스크립트
00:00:00Grok hat mein gesamtes Benutzerverzeichnis auf xAI-Server hochgeladen, es enthält meine SSH-Schlüssel, mein Passwort
00:00:05Manager-Datenbank, meine Dokumente, Fotos, Videos, alles. Die Coding-CLI von Grok hat Ihr
00:00:10gesamtes Repo und Ihre Git-Historie hochgeladen, einschließlich Dateien, die nicht geöffnet werden durften, und Geheimnissen, die aus
00:00:16der Historie gelöscht wurden. Das ist ein schwerwiegender und massiver Fehler des Grok-Teams, also lassen Sie uns analysieren,
00:00:20was passiert ist, wie Sie prüfen können, ob Ihr Code hochgeladen wurde, und was xAI getan hat, um dies zu beheben.
00:00:29Ich bin zuerst durch diesen Tweet darauf gestoßen, der Leute auffordert, diesen Grep-Befehl auszuführen, um
00:00:33die Grok-Logs zu lesen. Man wird sich ärgern. Er zeigt ein Foto des Logs, das zeigt, wie ein Repo-Upload
00:00:38auf die Grok-Server eingereiht wird. Dieser Tweet hat Hunderte von Antworten und Zitaten von Leuten, die diesen Befehl ausführen
00:00:42und ein ähnliches Ergebnis erhalten, und sogar einen Benutzer, der Grok in seinem Home-Verzeichnis ausführte und berichtete, dass sie
00:00:47alles hochgeladen haben. Weitere Untersuchungen zeigen, dass es einen Malware-ähnlichen Hintergrund-Code-Sammler mitliefert.
00:00:52Lassen Sie uns also einen Blick darauf werfen, was er tatsächlich getan hat. Dies ist ein Bericht eines Forschers namens Cereblab,
00:00:56der mitmproxy verwendete, um den Datenverkehr zu untersuchen, den die Grok-CLI sendete und empfing. Sie öffneten Grok in
00:01:02einem Repo und der einzige Prompt, den sie sandten, war: „Antworte okay, öffne keine Dateien.“ Es stellt sich jedoch heraus,
00:01:07dass diese Anweisung keine Rolle spielt, da Grok trotzdem das gesamte Repo hochgeladen hat. Es gab einen
00:01:12POST-Request, der mit dem gesamten Repo-Bundle gesendet wurde, und dieses Bundle enthielt die gesamte Git-Historie
00:01:16und sogar Umgebungsvariablen. Das finde ich so schlimm an der ganzen Sache. Ja, wir wissen alle, dass, wenn
00:01:21wir ein Remote-Modell verwenden, Code an unsere Server gesendet wird, aber normalerweise geht man davon aus,
00:01:26dass nur der Code, der tatsächlich gelesen werden muss, an sie gesendet wird. Es ist nicht die gesamte Codebasis,
00:01:30selbst wenn sie für den Prompt gar nicht relevant ist. Sie zeigten sogar, dass dies funktionierte, als ein Repo 12 Gigabyte groß war.
00:01:35Es lädt immer noch alles hoch. Wenn man dies bei anderen Tools wie Claude Code, Codex und Gemini testet, zeigt es,
00:01:40dass nur die Datei gesendet wird, die es liest. Dies ist ein einzigartiges Problem der Grok-CLI. Sie fanden sogar heraus,
00:01:45dass es dies immer noch tun würde, selbst wenn man die Einstellung „Verbesserung dieses Modells unterstützen“ deaktiviert hätte. Und beim Abrufen der Benutzer-
00:01:51daten gab es tatsächlich ein Flag namens trace upload enable, das immer auf true gesetzt war. Nun,
00:01:55alle diese Tweets und dieser Beitrag gingen viral. Wie hat also xAI reagiert? Nun, zuerst nahmen sie ein bisschen
00:02:01einen stillen Fix vor. Wenn Sie dies einen Tag später, nachdem der Beitrag viral gegangen war, erneut versucht haben, zeigten die Einstellungen, dass
00:02:05dieses Trace-Upload-Flag nun deaktiviert war und es tatsächlich ein neues namens disable codebase upload gab,
00:02:10das anscheinend für das Konto jedes Benutzers auf true gesetzt war. Sie hatten also tatsächlich einen serverseitigen Kill-Switch
00:02:14für den Code-Upload eingebaut. Kurz darauf antworteten sie auch öffentlich auf Twitter und sagten: „Wir kümmern uns
00:02:19zutiefst um Ihre Privatsphäre und respektieren die Wahl der Kunden. Für Teams, die keine Datenspeicherung nutzen, werden keine Traces und
00:02:24Codedaten jemals gespeichert. Auch jede API-Key-Nutzung des Grok-Builds respektiert die Datenspeicherung von null. Wenn die Datenspeicherung
00:02:30auf null gesetzt ist, ist der Befehl /privacy in der CLI verfügbar, um die Datenspeicherung zu deaktivieren,
00:02:36was auch zuvor synchronisierte Daten löscht. Führen Sie den Befehl /privacy aus, um Ihre Einstellungen jederzeit
00:02:40anzuzeigen oder zu ändern.“ Elon twitterte auch, dass als Vorsichtsmaßnahme alle Benutzerdaten, die
00:02:45vorher auf space xai hochgeladen wurden, vollständig und gänzlich gelöscht werden. Nichts wird
00:02:51bleiben.“ Aber Sie haben in einem anderen Tweet auch gefragt, ob man die Einstellung anlassen kann, da dies eigentlich hilfreich ist
00:02:55für das Debuggen von Problemen, wenn sie eine gewisse Menge an Daten behalten können, was ich glauben kann, dass, wenn wir nur
00:03:00über Traces sprechen, das eine ziemlich übliche Praxis ist. Aber das Hochladen eines gesamten Repos auf ihre Server,
00:03:05keine dieser Antworten scheint diesen Teil anzusprechen. Und das neue Grok-CLI-Update fügte einfach einen Privacy-Befehl
00:03:10hinzu, aber es ist erwähnenswert, dass dieses Update den Code, der Ihr gesamtes Repo hochlädt, nicht wirklich entfernt hat.
00:03:14Sie können das tatsächlich immer noch in der Binärdatei finden. Es scheint also, das Einzige, was verhindert, dass sich dies wieder einschaltet,
00:03:18ist dieses serverseitige Flag, das von xAI kontrolliert wird. Es scheint mir wirklich so, als ob dieser Code
00:03:23nicht dort sein sollte, da kein anderes Tool ihn verwendet. Plus, wenn wir uns diesen neuen Privacy-Befehl ansehen, dieser
00:03:28deaktiviert eigentlich einfach Traces und schaltet den serverseitigen Schalter namens coding data retention opt-out um.
00:03:33Und derselbe Forscher hat diesen Befehl tatsächlich analysiert und gezeigt, dass er lokal nichts bewirkt. Ihre
00:03:38Sitzungstraces werden immer noch in vollem Umfang an xAI gesendet, egal ob es an oder aus ist. Der einzige Unterschied liegt darin,
00:03:43wie der Server antwortet: Wenn es aus ist, antwortet er mit einem 200er-Code, was bedeutet, dass es gespeichert wurde,
00:03:48und wenn der Datenschutzmodus an ist, gibt er einfach einen 204er-Code zurück, um zu sagen, kein Inhalt, und die Daten wurden verworfen.
00:03:53Es ist also tatsächlich nur ein serverseitiger Speicherschalter und blockiert es nicht von der Client-Seite. Also
00:03:58übertragen Sie immer noch alles, Sie müssen nur darauf vertrauen, dass xAI-Server es tatsächlich
00:04:02verwerfen, anstatt es zu speichern. Selbst wenn ich xAI vertrauen würde, wird es noch schlimmer, weil dieser Privacy-Befehl
00:04:07eigentlich ein pro-Sitzungs-Speicherschalter ist, also müssen Sie dies möglicherweise in jeder Sitzung umschalten, um
00:04:12Ihre Daten sicher zu halten. Das erscheint mir einfach unglaublich rückständig, aber hier stehen wir jetzt. Wenn Sie
00:04:17in der Vergangenheit die Grok-CLI verwendet haben und sehen möchten, was von Ihrem Computer geleakt sein könnte, können Sie Ihre
00:04:21Logs überprüfen. Dieser Grep-Befehl zeigt Ihnen genau, welche Sitzungen die Uploads ausgelöst haben. Wenn Sie Sicherheit
00:04:26auch ernst nehmen, werden Sie wahrscheinlich all diese Schlüssel rotieren wollen, wenn es zeigt, dass ein Teil
00:04:30dieser Daten gesendet wurde, es sei denn, Sie vertrauen voll darauf, dass xAI all dies gelöscht hat. Schließlich, wenn Sie
00:04:35einen Anschein von Privatsphäre bewahren wollen, während Sie die Grok-CLI weiterhin nutzen – obwohl ich es wahrscheinlich nicht empfehlen würde –,
00:04:40gibt es hier eine wirklich gute Anleitung dazu, wie Sie die Grok-CLI härten können, und sie zeigt Ihnen, wo Sie
00:04:44Dinge wie „disabled codebase upload“ in Ihrer Konfiguration einstellen, was diese Upload-Pipeline hart stoppen sollte. Also
00:04:49das ist die Geschichte: Aus irgendeinem Grund hat Grok Ihr gesamtes Repo hochgeladen, selbst wenn es das nicht brauchte, und sie
00:04:53haben anscheinend jetzt all diese Daten gelöscht und die Funktion zurückgenommen. Aber ich möchte wissen, vertrauen
00:04:58Sie ihnen und würden Sie die Grok-CLI von nun an verwenden, jetzt wo Sie das wissen? Lassen Sie es mich in den
00:05:02Kommentaren unten wissen. Moment, da abonnieren und wie immer, wir sehen uns beim nächsten Mal.