ZCode packte 42.411 Dateien in ein Archiv, das nur Zhipu öffnen konnte

Am 18. September 2026 veröffentlichte ein Entwickler, der unter dem Namen ferstarschreibt, eine Analyse von ZCode, dem Desktop-KI-Coding-Agenten des chinesischen Modellentwicklers Zhipu AI, nachdem ihm aufgefallen war, dass ein versteckter Ordner in seinem Home-Verzeichnis auf über 700 MB angewachsen war. Darin fand er ein 313 MB großes verschlüsseltes Archiv mit 42.411 Dateien aus einem 345 MB großen Workspace, zu 86,6 % aus Git-Historie bestehend, vom Client gepackt und für den Upload in den Objektspeicher von Alibaba Cloud bereitgestellt. Das Archiv war mit einem Schlüssel versiegelt, den nur die Server von Zhipu entschlüsseln konnten, und der Client bot keinen Schalter, der den Aufbau verhinderte. Zhipu entschuldigte sich noch am selben Abend. Der vollständige Datensatz mit der eigenen Konfidenzstufe des Archivs und seinem Schadensstatus befindet sich im Orca AI Incident Archive, das jeden dokumentierten KI-Vorfall anhand seiner zitierten Quellen protokolliert.

ZCode ist Zhipus Desktop-Coding-Agent: Er liest ein Projekt, führt Shell-Befehle aus und schreibt Code. Das Unternehmen wird in Hongkong unter dem Ticker 2513.HK gehandelt und tritt mit seinem internationalen Arm als Z.ai auf, dem Namen, der auf den von ferstar untersuchten ZCode-Servern erscheint. The Paper, das Shanghaier Nachrichtenportal, das ihn und mehrere andere Entwickler anschließend interviewte, berichtet, sein Beitrag habe in etwa den Titel „Den Vorhang vor ZCodes stillem Hochladen der vollständigen Git-Historie lüften“ getragen und habe sich innerhalb von Stunden nach der Veröffentlichung in chinesischen Entwicklergruppen verbreitet.

Was befand sich in dem versteckten Ordner?

Ferstars eigene Zahlen sind das Rückgrat des Falls, und sie wurden von The Next Web, InfoQ und der Finanzredaktion von China National Radio durchgängig übereinstimmend wiedergegeben. Das Archiv in seinem ZCode-Checkpoints-Verzeichnis war 313 MB groß. Die danebenliegende Statusdatei verzeichnete einen Arbeitsbereich von etwa 345 MB und 42.411 Dateien. Das .git-Verzeichnis machte 86,6 % der Nutzlast aus: 196,1 MB Git-Cache für große Dateien, 102,2 MB Git-Objekte mit der vollständigen Commit-Historie und einen kleinen Anteil Reflog. Der tatsächliche Quellcode und die Dokumentation machten rund 13,4 % aus.

Der Unterschied ist wichtig, weil die Git-Historie der Ort ist, an dem Material, das aus dem aktuellen Tree entfernt wurde, tendenziell überlebt. Die Darstellung des Papers macht das direkt deutlich: Ein Archiv dieser Art kann die Bearbeitungshistorie eines Projekts ab dem ersten Commit, gelöschte Inhalte, nicht committete Entwürfe und ältere Konfigurationsdateien enthalten – einschließlich Zugangsdaten, die vor langer Zeit aus dem Code entfernt wurden, aber weiterhin in früheren Commits und im Large-File-Cache vorhanden sind.

Ferstars eigenes 313-MB-Archiv verließ nie seinen Rechner. Sein Statusprotokoll zeigte 564 fehlgeschlagene Upload-Versuche, und es war in einem ausstehenden Zustand über dem Größenlimit hängen geblieben. Um zu testen, ob die Pipeline überhaupt funktionierte, probierte er ein kleines öffentliches Repository mit 538 Dateien aus; dieser Snapshot wurde auf rund 15 KB komprimiert und verschlüsselt und vom Server angenommen. Dieser Transfer ist der in den Aufzeichnungen bestätigte, der durchgängig abgeschlossen wurde, und er ist es, der den Befund von einer Code-Lese-Übung in eine Exfiltration mit nachgewiesenem Empfangsende verwandelt.

Die Erfassung war an keine Aktion gebunden, die ein Nutzer als „mein Repository hochladen“ erkennen würde. Laut ferstars Rekonstruktion wurde ein Auslöser vor jedem an das Modell gesendeten Prompt ausgelöst, und ein weiterer lief als Aktualisierungsaufgabe für Repo Wiki. Das Löschen des ausstehenden Archivs stoppte dies nicht: Ein Beitrag in Tencent Clouds Entwickler-Community dokumentiert, dass das Paket innerhalb von 30 Minuten neu erstellt wurde und der Fehlerzähler von 564 auf 565 stieg. Die einzige zuverlässige Möglichkeit zum Anhalten, die der Autor fand, bestand darin, das Checkpoint-Verzeichnis nicht beschreibbar zu machen, sodass die Erfassung beim Schreiben auf die Festplatte fehlschlug – auf Kosten des Verlusts von Checkpoint-Rollback und der Timeline-Oberfläche.

Ein Schlüssel, den nur der Anbieter verwenden konnte

Die Verschlüsselung war Envelope Encryption wie aus dem Lehrbuch, und genau dieser Teil ließ sich von den Nutzern nicht umgehen. InfoQs Rekonstruktion, die auf ferstars Reverse Engineering basiert, beschreibt, wie der Client eine Snapshot-ID, einen öffentlichen RSA-Schlüssel und Upload-Anmeldeinformationen für Alibaba Cloud OSS von zcode.z.ai abruft, den Arbeitsbereich lokal paketiert und verschlüsselt und anschließend den Geheimtext direkt an OSS sendet. Die Inhalte wurden mit AES-256-CTR verschlüsselt; der symmetrische Schlüssel wurde mit RSA-OAEP-SHA256 unter dem öffentlichen Schlüssel des Servers gekapselt, dessen private Hälfte in der Cloud von Zhipu verblieb.

Das Routing ist ebenso wichtig wie die Kryptografie. Weil der Client direkt zu Alibaba Cloud hochlud und nicht über Zhipus eigene Anwendungsserver, lief der Datenverkehr nicht durch einen Zhipu-Dienst, der ihn protokollieren oder filtern konnte; daher lag kein Zhipu-Dienst im Pfad, der protokollieren oder filtern konnte, was hinausging. Und weil der private Schlüssel nie auf dem Gerät war, konnte ferstar sein eigenes Archiv nicht öffnen: The Next Web berichtet, dass er jeden privaten Schlüssel auf seinem Rechner ausprobierte und scheiterte. In seinem Beitrag beschrieb er die Konstruktion als einen Schlüssel, den nur der Server verwenden kann und der nur einem Zweck dient.

Zwei Einstellungen im Client sahen so aus, als hätten sie dies verhindern müssen, und keine von beiden tat es. Der Umschalter „Optimierung des Erlebnisses“ regelte, ob Daten für das Modelltraining verwendet werden durften; der Umschalter „Repository-Snapshot-Indizierung“ regelte, ob der Server einen Index über bereits eingegangene Snapshots aufbaute. Beide wirken erst nach der Erfassung. Ferstar stellte fest, dass die Erfassung bedingungslos lief, und The Next Web berichtet, dass sie nach seiner Lesart der Datenschutzerklärung zwar das Sammeln von Gesprächstexten und Dateien beschrieb, aber nichts über automatische Workspace-Snapshots aussagte, die die vollständige Git-Historie enthalten.

Die Erklärung, die Zhipu abgegeben hat, und die vier Tage danach

Zhipu reagierte noch am selben Tag – über die offizielle Nutzergruppe von ZCode statt über eine Pressemitteilung. Wie die Global Times berichtete und Security Inside nachdruckte, führte das Unternehmen das Verhalten auf eine Funktion namens Codebasis-Indexierung zurück, die lokale Indexierung, die Wiederherstellung von Sitzungs-Checkpoints, Versions-Rollbacks und die Generierung von Repo Wiki unterstützt, und erklärte, der Repo Wiki-Schritt habe die Uploads der Repositories in die Cloud ausgelöst. Die Funktion sei seit der Einführung standardmäßig aktiviert gewesen. Zhipu erklärte, die hochgeladenen Daten seien nur zur Generierung der Repo Wiki-Seite verwendet und unmittelbar danach gelöscht worden; sie würden weder gespeichert noch für das Training verwendet, und das Unternehmen entschuldigte sich bei den betroffenen Nutzern. Es versprach, die ZCode-Codebasis als Open Source zu veröffentlichen, eine Prüfung durch Dritte einzuladen und die Ergebnisse zu veröffentlichen, und bot jedem ZCode-Nutzer als Entschädigung einen zusätzlichen wöchentlichen Quota-Reset an.

Der Fix kam am nächsten Tag. The Paper berichtet, dass ZCode 3.14.0 am 19. September mit einem Changelog-Eintrag ausgeliefert wurde, der lautet: „fix the abnormal upload issue of the repository wiki“, und dass ferstar noch am selben Tag bestätigte, dass die Upload-Kette und ihr Endpunkt nicht mehr vorhanden waren. Am 20. September kündigte Zhipus MaaS-Plattform eine kommende Zero-Retention-Option an, bei der Eingaben und Ausgaben nicht statisch gespeichert würden; The Paper merkt an, dass sie auf Antrag opt-in ist, Batch API und File API ausschließt und eine Aufbewahrung von 30 Tagen oder länger weiterhin erlaubt, wenn dies gesetzlich oder zur Untersuchung von Missbrauch erforderlich ist. Am 21. September wurde der Client-Quellcode auf GitHub unter der Apache-2.0-Lizenz öffentlich, einschließlich Desktop-App, Web-Client, Backend, Agent-CLI und Agent-Runtime.

Es wurden zwei Audits in Auftrag gegeben, deren Ergebnisse in Form von Zusammenfassungen veröffentlicht wurden. Die China Academy of Information and Communications Technology stellte fest, dass sich der Alibaba-Cloud-OSS-Bucket zcode-prod in einem Zustand befindet, den Zhipu als Null-Daten-Zustand bezeichnet. Das Sicherheitsunternehmen NSFOCUS berichtete, dass jedes Datenobjekt und der Bucket selbst gelöscht worden seien und dass es in ZCode 3.14.0 keinen verbleibenden Pfad gefunden habe, der einen lokalen Repository-Snapshot auslösen oder Dateien nach außen senden könnte. Der vollständige Bewertungsbericht ist bislang nicht erschienen, und The Next Web berichtet, dass Zhipu keinen Termin dafür genannt hat.

Der Kunde, der mehr behauptet hat und dies dann zurückzog

Die schwerwiegendste Behauptung eines tatsächlichen Verlusts kam nicht von ferstar. Am 19. September schickte Taiyuan Chengming Technology laut China National Radio Zhipu ein Rechtsschreiben mit der Nummer Chengming [2026] Legal Letter No. 1, das von ChainCatcher ausführlich wiedergegeben wurde. Das Unternehmen erklärte, sechs seiner Coding-Workspaces seien ohne Zustimmung hochgeladen worden – 34.500 Dateien und rund 425 MB im Klartext – und führte vollständigen Quellcode, Systemarchitektur, Versionsverlauf, Datenbankpasswörter, Cloud-Zugangsdaten und personenbezogene Daten von Mitarbeitenden auf. Es hieß, ein siebter Workspace mit 1.947 Dateien und etwa 144 MB sei gepackt und verschlüsselt worden, doch 32 Upload-Versuche seien fehlgeschlagen. Außerdem merkte es an, dass sein Client am 16. September auf Version 3.12.3 aktualisiert worden sei, dennoch seien am 18. September um 00:28 Uhr noch Uploads festgestellt worden – am Morgen, an dem sich Zhipu entschuldigte.

Der Brief stellte eine Frage, die die Audits nicht beantworten: ob Daten das Land verlassen haben. Chengming sagte, die Netzwerkanfragen von ZCode hätten auf eine Entität in Singapur verwiesen, während seine Dienstleistungsvereinbarung mit Beijing Zhipu Huazhang unterzeichnet worden sei, und forderte Zhipu auf, zu benennen, welche Partei verantwortlich war und ob eine Übertragung oder Speicherung außerhalb des chinesischen Festlands stattgefunden habe. Der Brief enthielt zwölf Forderungen, darunter: alle hochgeladenen Daten sowie deren Derivate, Caches und Backups zu löschen und dies schriftlich zu bescheinigen; zu erklären, wohin die Daten gelangten und ob sie mit Dritten geteilt oder für das Training verwendet wurden; zu beschreiben, wie der private Schlüssel verwahrt wird, und Zugriffsprotokolle vorzulegen; den genauen Umfang der Behauptung „zerstört“ zu definieren; und sich schriftlich zu verpflichten, nie wieder hochzuladen. Er setzte Zhipu eine Frist bis zum 10. Oktober für eine schriftliche Antwort und behielt sich das Recht vor, Schadensersatz zu verlangen und Beschwerde bei den Aufsichtsbehörden einzulegen. Caixin Global berichtet, dass Zhipu die Vorwürfe als unwahr bezeichnete.

Zwei Tage später nahm Chengming sie zurück. Die Finanzredaktion von China National Radio berichtet, dass das Unternehmen am 21. September einen Widerruf veröffentlichte, in dem es hieß, seine früheren Aussagen hätten auf fehlerhaften Beweisen, unpräziser Darstellung und überzogener Formulierung beruht, sie hätten den Ruf von Zhipu geschädigt, und es werde aufhören, mit den Medien zu sprechen. Laut The Next Web berichtete auch Reuters über die Rücknahme. Der Archiveintrag zu diesem Vorfall ist auf den 18. September datiert, den Tag der Entdeckung; der Brief, seine Frist vom 10. Oktober und der Widerruf kamen alle nach diesem Datum. Nach den öffentlich zugänglichen Unterlagen Ende Oktober steht kein namentlich genanntes Unternehmen hinter einer Behauptung, seine Geheimnisse seien offengelegt worden.

Eine Open-Source-Veröffentlichung, deren Geschichte gelöscht wurde

Die Open-Source-Veröffentlichung des Clients war die Maßnahme, auf die Zhipu am stärksten setzte, und sie brachte ein Loch mit sich. The Paper berichtet, dass das veröffentlichte Repository zwei Commits enthält: einen leeren ursprünglichen Commit und einen einzigen Commit, der etwa 6.973 Dateien und 1,03 Millionen Zeilen hinzufügt, wobei Pull Requests gesperrt und Issues geschlossen sind. Wie die Upload-Pipeline bei der Auslieferung aussah und welche Releases sie enthielten, ist in der Historie, die heute irgendjemand lesen kann, nicht enthalten.

Ferstars eigenes Nachfassen macht die Grenze explizit. Er bestätigte, dass die Upload-Pipeline nicht mehr vorhanden war und dass der verbleibende Checkpoint-Mechanismus ausschließlich lokal mit Git arbeitet, und wies dann darauf hin, was eine Prüfung des Buckets zeigen konnte und was nicht: Das Leeren und Löschen des Buckets ist die richtige Stop-Loss-Maßnahme, doch eine nach dem 20. September durchgeführte Prüfung durch Dritte kann nur belegen, dass der Bucket zu diesem Zeitpunkt leer war. Sie kann nicht rekonstruieren, was vor dem 18. September hindurchgelaufen ist, ob etwas entschlüsselt, kopiert oder gesichert wurde oder wie lange die Pipeline bereits lief. Eine Löschbehauptung stützt sich weiterhin wesentlich auf das Wort der Partei, die gelöscht hat.

Die Analyse von InfoQ listet die weiterhin offenen Fragen mit denselben Formulierungen auf: wie viele Repository-Snapshots erfolgreich hochgeladen wurden und von wie vielen Nutzern, wie lange Objekte aufbewahrt wurden, welche serverseitigen Systeme oder Mitarbeiter sie entschlüsseln konnten, ob ein vollständiges Zugriffsprotokoll existiert und ob die Löschung Backups und andere Kopien umfasste. Außerdem wird erwähnt, was ZCode nach der Fehlerbehebung noch ist. Die projekteigene NOTICE warnt davor, dass die gemeinsam genutzte Agent-Runtime standardmäßig keine Sandbox auf Betriebssystemebene bereitstellt und der Client Shell-, Terminal-, Git-, MCP-, Plugin- und eingebettete Browser-Oberflächen beibehält, die im Rahmen der Berechtigungen des Benutzerkontos Dateien lesen, Prozesse starten und auf das Netzwerk zugreifen können.

Was gesichert ist und was keine Quelle beantwortet

Der Mechanismus ist unbestritten. Zhipus eigene Aussagen räumen ein, dass Repository-Daten hochgeladen wurden, dass die Funktion standardmäßig aktiv war und dass die Daten in einen vom Unternehmen kontrollierten Cloud-Bucket gelangten. Ferstars Messungen, die Entschuldigung des Anbieters, zwei in Auftrag gegebene Audits und die Open-Source-Veröffentlichung beschreiben alle dieselbe Kette. Nichts im Protokoll bestreitet, dass Arbeitsbereiche Rechner ohne eine praktikable Opt-out-Möglichkeit verließen. Der im Protokoll verzeichnete Schaden ist eingetreten und nicht hypothetisch: Die Übertragungen fanden statt, und die Personen, deren Code darin enthalten war, konnten sie weder verhindern noch einsehen.

Was strittig oder schlicht unbekannt ist, sind Ausmaß und Folgen. Keine Quelle gibt an, wie viele Nutzer die betroffenen Standardeinstellungen verwendeten, wie lange die Pipeline vor dem 18. September in Betrieb war oder ob jemals ein hochgeladenes Objekt entschlüsselt wurde. Zhipus Versicherung, dass die Daten nach der Wiki-Erstellung zerstört und nie zum Training verwendet wurden, ist eine Erklärung des Unternehmens selbst; die Befunde von CAICT und NSFOCUS beschreiben den Zustand des Buckets nach der Behebung, nicht das, was ihn durchlaufen hat. Das Archiv bewertet den Datensatz hinsichtlich der Dokumentation mit A, und die Dokumentation ist stark in Bezug auf den Mechanismus und dünn in Bezug auf den Umfang.

Was sich geändert hat – und was nicht

Die kommerziellen Kosten waren unmittelbar. China National Radio berichtet, dass die in Hongkong notierten Aktien von Zhipu am 21. September um 1,79 %, am 22. September um 6,55 % und am 23. September um 12,4 % fielen – ein kumulierter Rückgang von mehr als 16 % über drei Handelssitzungen – und dass Zhipu nicht darauf einging, wie viele Nutzer betroffen waren oder ob historische Daten entschlüsselt oder gesichert worden waren.

Was ein ZCode-Nutzer in den vier Tagen nach der Entdeckung tatsächlich erhielt:

• 18. September: eine öffentliche Entschuldigung, in der die Indizierung der Codebasis als Ursache genannt wird, ein Versprechen, den Client als Open Source zu veröffentlichen und eine Überprüfung durch Dritte in Auftrag zu geben, sowie ein zusätzlicher wöchentlicher Kontingent-Reset pro Nutzer.

• 19. September: ZCode 3.14.0, wobei Repo Wiki entfernt und der Pfad für lokale Snapshot-Erstellung und Upload gekappt wurde. Ferstar bestätigte am folgenden Tag, dass die Upload-Kette nicht mehr vorhanden war.

• 20. September: eine angekündigte Zero-Retention-Option für die MaaS-Plattform von Zhipu, Opt-in, mit Ausnahme von Batch API und File API und weiterhin einer gesetzlichen Aufbewahrungsfrist von 30 Tagen oder mehr unterliegend.

• 21. September: ZCode unter Apache 2.0 ohne seine Commit-Historie aus der Zeit vor dem Vorfall veröffentlicht; Zusammenfassungen von CAICT und NSFOCUS berichten, dass der Storage-Bucket leer und der Egress-Pfad nicht vorhanden sei.

Nichts davon wirkt rückwirkend. Die konkreten Fragen, die Chengming aufgeworfen hatte – wohin die Daten gingen, wer sie entschlüsseln konnte, ob sie das Land verließen und was „zerstört“ abdeckte –, wurden schriftlich mit einer Frist bis zum 10. Oktober gestellt und dann zusammen mit dem Unternehmen, das sie gestellt hatte, zurückgezogen. Zhipu hat einen vollständigen Bewertungsbericht eines Dritten versprochen, ohne einen Termin zu nennen. Bis ein solcher Bericht vorliegt, ist die einzige öffentliche Darstellung dessen, was die Pipeline mit den erhaltenen Daten gemacht hat, die Darstellung des Unternehmens, das sie gebaut hat, und das einzige unabhängig messbare Artefakt ist eine 313-MB-Datei, die 564 Mal daran scheiterte, den Laptop eines Entwicklers zu verlassen.