Grok Build CLI lud komplette ganze Git-Repositorys in einen Google Cloud-Bucket hoch

Stop - PixabayDer AI-Coding-Assistent Grok Build CLI ist vor einigen Tagen durch ein seltsames Verhalten aufgefallen. Der Coding-Assistent von xAI ist aufgefallen weil er ganze Git-Repositorys in einen Google Cloud-Bucket hochgeladen hat. Dadurch wurden auch private Codebasen und Geheimnisse wie Zugangsdaten im Klartext in das Google Cloud-Bucket hochgeladen und müssen als kompromittiert angesehen werden. SpaceXAI hat inzwischen den Vorfall bestätigt und den Upload gelöscht.

Ein Tweet mit Hinweis auf "Ausleitungen"

Mir ist der Vorfall die Tage auf X untergekommen, weil der Kanal International Cyber Digest in nachfolgendem Tweet seine Beobachtungen veröffentlichte.

Grook-Fail

Im Tweet hieß es, dass die "Grok Build CLI" von xAI hat ganze Git-Repositorys in einen Google-Cloud-Bucket hochgeladen habe. Darunter befanden sich auch private Codebasen und Geheimnisse wie Zugangsdaten im Klartext (ungeschwärzt).

Das Ausmaß sei atemberaubend, heißt es im Tweet. Bei einem 12-GB-Test-Repository flossen 5,1 GB in den "grok-code-session-traces"-Bucket von xAI, während die eigentliche Programmieraufgabe lediglich 192 KB benötigte. Das Tool griff auf das gesamte Repository zu, in dem es ausgeführt wurde, und nicht nur auf die benötigten Dateien.

Das Thema wurde bereits zum 10. Juli 2027 auf reddit.com in diesem Post angesprochen und auf GitHub dokumentiert. Das ist für die Benutzer von "Grok Build CLI" natürlich ein GAU, ist doch quasi das gesamte Repository samt "Geheimnissen" ausgeleitet worden. Irgendwann hat xAI  das gemerkt, denn die Uploads wurden stillschweigend über ein verstecktes serverseitiges Flag gestoppt. In obigem Tweet wird beklagt, dass xAI sich zum Zeitpunkt der Erstellung des Posts noch nicht zu Umfang, Aufbewahrungsdauer oder Löschung geäußert habe.

xAI bestätigt Problem und löscht Upload

In einem Folgetweet thematisiert International Cyber Digest die Stellungnahme von SpaceXAI zum Vorfall. Das Eingeständnis ist, dass die Datenspeicherung in der Beta-Phase für Nicht-ZDR-Nutzer (Zero Data Retention) standardmäßig aktiviert war.

Grook-Fail-Bestätigung

Es wird auch erwähnt, dass die Einstellung, dass keine Daten ausgeleitet werden dürfen, respektiert wurde. Es traf nut Nutzer, die die Option nicht entsprechend gesetzt hatten. Diese Ausleitung wurde inzwischen deaktiviert und SpaceXAI gibt an, dass man alle Kodierungsdaten, die man hochgeladen habe, löscht.

Einstufung durch Norddeutsch

Blog-Leser Norddeutsch hatte zu obigem Sachverhalt folgenden Text im Diskussionsbereich des Blogs eingestellt, den ich mal nach hierher ziehe:

Ausleitung (aller) zugreifbaren Daten in GitHub-Repositories der Nutzer von xAI's KI-Coding-Assistenten Grok Build. Dazu hier detaillierte Analyse von cereblab auf GitHub. Hier zu Hacker NewsGolem gestern, dort CyberNews. Scheinbar wurden ebenso Daten bis zu potentiellen oder verhandenen Secrets und SSH-Keys ausgeleitet, dies getestet mit Canary-Files (hier verwendet i.S.v. von Kanarienvögeln), z.B.:

API_KEY=CANARY7F3A9-SECRET-should-not-leave
DB_PASSWORD=CANARY7F3A9-DBPASS

Egal ob jetzt der Quellcode von Grok zur Vertrauensbildung veröffentlicht wurde. Egal ob ohne Zustimmung ausgeleitete Daten gelöscht werden.

Alle Credentials wären m.E. als kompromittiert zu betrachten. Token sind allesamt zu tauschen, Passworte neu zu setzen, Ausleitung bei Systemen im OP's oder DEV unmittelbar zu prüfen.

Risiko KI-Coding-Assistent und der Kontrollverlust

Da passt der Hinweis von Leser viebrix im Diskussionsbereich, der folgendes schrieb:

Linus Torvalds findet sehr klare Worte zu KI und der Benutzung bei Linux. Golem Artikel: Linus Torvalds eskaliert gegen KI-Gegner "Linux ist kein Anti-KI-Projekt"

Hier ein Auszug (ganzen Artikel lesen, es steht noch mehr drin):
Torvalds hat bezüglich KI aber offenkundig eine andere Einstellung. "Mir ist klar, dass manche Leute KI wirklich nicht mögen, aber dies ist ein Bereich, in dem ich als Hauptverantwortlicher Maintainer absolut nicht nachgeben werde", schrieb er in einer Mail. KI sei lediglich ein Tool wie viele andere, und in diesem Fall sogar ein "zweifellos nützliches".

Vor einem Jahr sei die Lage diesbezüglich womöglich noch nicht ganz so eindeutig gewesen, heute stehe die Nützlichkeit von KI aber außer Frage. "Jeder, der das bezweifelt, hat es offensichtlich selbst noch nicht ausprobiert", so der Kernel-Entwickler.

Zwar könne KI durchaus lästig sein und erzeuge für Maintainer gerade eine Menge Arbeitsaufwand, die Lösung bestehe allerdings nicht darin, "den Kopf in den Sand zu stecken und laut 'Lalala, ich kann dich nicht hören' zu singen, wie es manche Leute offenbar tun".

Es stimmt zwar, was Torvalds da zu bedenken gibt. Aber der obige Sachverhalt zeigt halt auch, dass der Teufel im Detail steckt. Spätestens wenn die Leute ihre GitHub-Repositories samt Geheimnissen ausgeleitet bekommen, fängt doch der Katzenjammer an.

Die Lieferkettenangriffe, die wir seit Monaten sehen, werden dann ohne Hacks möglich, wenn Zugangsdaten frei Haus geliefert werden. Und ich erinnere an das Thema GitLost, was am 6. Juli 2026 im Beitrag GitLost: How We Tricked GitHub's AI Agent into Leaking … öffentlich wurde. KI-Coding-Assistenten sind quasi die Zauberlehrlinge, die die Geister riefen. Bleibt die Frage, ob die Zauberlehrlinge auf Dauer "die Geister, die sie riefen, Herr werden, oder ob die ein Eigenleben entwickeln".

Dieser Beitrag wurde unter AI, Sicherheit abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen für den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht. Wegen Missbrauchs bin ich gezwungen, Name und E-Mail als Pflichtfelder beim Kommentieren zu aktivieren. Wählt ggf. einen (noch nicht benutzten) Alias-Namen und verwendet ggf. eine Dummy-Mail-Adresse (z.B. t@hotkev.com).

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.