ZCode verpakte 42.411 bestanden in een archief dat alleen Zhipu kon openen

Op 18 september 2026 publiceerde een ontwikkelaar, schrijvend onder de naam ferstar, een teardown van ZCode, de desktop-AI-codeeragent van de Chinese modelontwikkelaar Zhipu AI, nadat hij merkte dat een verborgen map in zijn thuismap was gegroeid tot meer dan 700 MB. Daarin vond hij een versleuteld archief van 313 MB met 42.411 bestanden uit een werkruimte van 345 MB, waarvan 86,6% Git-geschiedenis, verpakt door de client en klaargezet voor upload naar Alibaba Cloud-objectopslag. Het archief was verzegeld met een sleutel die alleen de servers van Zhipu konden ontsleutelen, en de client bood geen schakelaar die voorkwam dat het werd gebouwd. Zhipu verontschuldigde zich dezelfde avond. Het volledige verslag, met de eigen betrouwbaarheidsgraad en schadestatus van het archief, staat in het Orca AI Incident Archive, dat elk gedocumenteerd AI-incident vastlegt aan de hand van de aangehaalde bronnen.

ZCode is Zhipu's desktop-codingagent: het leest een project, voert shell-opdrachten uit en schrijft code. Het bedrijf is in Hong Kong genoteerd onder ticker 2513.HK en voert zijn internationale tak onder de naam Z.ai, de naam die voorkomt op de ZCode-servers die ferstar heeft geïnspecteerd. The Paper, het Shanghaise nieuwsmedium dat hem en verschillende andere ontwikkelaars achteraf interviewde, meldt dat zijn bericht ongeveer de titel "Het doek optrekken over de stille upload van de volledige Git-geschiedenis door ZCode" had, en dat het zich binnen uren na publicatie via Chinese ontwikkelaarsgroepen verspreidde.

Wat zat er in de verborgen map

De eigen cijfers van Ferstar vormen de ruggengraat van de zaak, en ze zijn consistent gereproduceerd door The Next Web, InfoQ en de financiële redactie van China National Radio. Het archief in zijn ZCode-checkpointsmap was 313 MB. Het statusbestand ernaast registreerde een werkruimte van ongeveer 345 MB en 42.411 bestanden. De .git-map was goed voor 86,6% van de payload: 196,1 MB aan Git large-file-storage-cache, 102,2 MB aan Git-objecten met de volledige commitgeschiedenis, en een klein deel reflog. De eigenlijke broncode en documentatie besloegen ongeveer 13,4%.

Het onderscheid is belangrijk omdat Git-geschiedenis de plek is waar materiaal dat uit de huidige tree is verwijderd, vaak blijft voortbestaan. De beschrijving van The Paper maakt dat punt direct: een archief van dit soort kan de bewerkingsgeschiedenis van een project vanaf de eerste commit bevatten, verwijderde inhoud, niet-gecommitte concepten en oudere configuratiebestanden, waaronder inloggegevens die lang geleden uit de code zijn verwijderd maar in eerdere commits en in de cache voor grote bestanden blijven staan.

Ferstar's eigen archief van 313 MB heeft zijn machine nooit verlaten. Uit het statuslog bleek dat er 564 mislukte uploadpogingen waren en dat het in een wachtende staat was vastgelopen, boven de grootte limiet. Om te testen of de pipeline überhaupt werkte, probeerde hij een kleine openbare repository van 538 bestanden; die momentopname werd gecomprimeerd en versleuteld tot ongeveer 15 KB en werd door de server geaccepteerd. Die overdracht is de enige in het verslag waarvan bevestigd is dat die van begin tot eind is voltooid, en dat is wat de bevinding verandert van een exercitie in code lezen in een exfiltratie met een aantoonbaar ontvangende kant.

Capture was niet gekoppeld aan een actie die een gebruiker zou herkennen als "mijn repository uploaden". Volgens de reconstructie van ferstar werd één trigger geactiveerd vóór elke prompt die naar het model werd verzonden, en een andere werd uitgevoerd als een Repo Wiki-updatetaak. Het verwijderen van het nog wachtende archief stopte het niet: een artikel op de developer community van Tencent Cloud vermeldt dat het pakket binnen 30 minuten opnieuw werd opgebouwd en dat de faalteller van 564 naar 565 ging. De enige betrouwbare stop die die auteur vond, was de checkpointmap niet-schrijfbaar maken, zodat het vastleggen bij het schrijven naar schijf mislukte, ten koste van het verlies van checkpoint-rollback en de tijdlijninterface.

Een sleutel die alleen de leverancier kon gebruiken

De versleuteling was envelopversleuteling volgens het boekje, en dat is het onderdeel waar gebruikers niet omheen konden. De reconstructie van InfoQ, gebaseerd op het reverse-engineering van ferstar, beschrijft dat de client een snapshot-ID, een RSA-publieke sleutel en uploadreferenties voor Alibaba Cloud OSS ophaalde bij zcode.z.ai, de werkruimte lokaal verpakte en versleutelde en vervolgens de ciphertext rechtstreeks naar OSS stuurde. De inhoud werd versleuteld met AES-256-CTR; de symmetrische sleutel werd verpakt met RSA-OAEP-SHA256 onder de publieke sleutel van de server, waarvan de private helft in Zhipu's cloud bleef.

De routering is net zo belangrijk als de cryptografie. Omdat de client rechtstreeks naar Alibaba Cloud uploadde in plaats van via Zhipu's eigen applicatieservers, ging het verkeer niet langs een Zhipu-dienst die het kon loggen of filteren; er zat dus geen Zhipu-dienst in het pad om te loggen of te filteren wat er vertrok. En omdat de privésleutel nooit op het apparaat stond, kon ferstar zijn eigen archief niet openen: The Next Web meldt dat hij alle privésleutels op zijn machine probeerde en er niet in slaagde. Hij beschreef de opzet in zijn bericht als een sleutel die alleen de server kan gebruiken en die maar één doel heeft.

Twee instellingen in de client leken dit te moeten stoppen, en geen van beide deed dat. De schakelaar "optimise experience" bepaalde of gegevens mochten worden gebruikt voor modeltraining; de schakelaar "repository snapshot indexing" bepaalde of de server een index bouwde over snapshots die al waren aangekomen. Beide werken stroomafwaarts van het vastleggen. Ferstar ontdekte dat het vastleggen onvoorwaardelijk liep, en The Next Web meldt dat uit zijn lezing van het privacybeleid bleek dat het wel het verzamelen van gesprekstekst en bestanden beschreef, maar niets zei over automatische workspace-snapshots die de volledige Git-geschiedenis meedragen.

De uitleg die Zhipu gaf, en de vier dagen daarna

Zhipu reageerde dezelfde dag, via de officiële gebruikersgroep van ZCode in plaats van via een persbericht. Zoals gemeld door Global Times en overgenomen door Security Inside, schreef het bedrijf het gedrag toe aan een functie genaamd codebase-indexering, die lokale indexering, herstel van sessie-checkpoints, versierollback en het genereren van Repo Wiki ondersteunt, en zei dat de Repo Wiki-stap de oorzaak was van de uploads van repositories naar de cloud. De functie stond sinds de lancering standaard aan. Zhipu zei dat geüploade gegevens alleen werden gebruikt om de Repo Wiki-pagina te genereren en daarna onmiddellijk werden vernietigd, dat ze niet werden opgeslagen en niet voor training werden gebruikt, en bood getroffen gebruikers excuses aan. Het beloofde de ZCode-codebase open source te maken, een derde partij uit te nodigen voor beoordeling en de resultaten te publiceren, en bood elke ZCode-gebruiker één extra wekelijkse quotumreset als compensatie.

De fix kwam de volgende dag. The Paper meldt dat ZCode 3.14.0 op 19 september is uitgekomen met een changelog-regel die luidt: "fix the abnormal upload issue of the repository wiki", en dat ferstar dezelfde dag bevestigde dat de uploadketen en het bijbehorende endpoint verdwenen waren. Op 20 september kondigde het MaaS-platform van Zhipu een aanstaande zero-retention-optie aan, waarbij inputs en outputs niet statisch zouden worden opgeslagen; The Paper merkt op dat deze opt-in is op aanvraag, de Batch API en File API uitsluit, en nog steeds bewaring van 30 dagen of langer toestaat wanneer de wet of een onderzoek naar misbruik dat vereist. Op 21 september werd de broncode van de client openbaar op GitHub onder de Apache 2.0-licentie, met de desktopapp, webclient, backend, agent-CLI en agent-runtime.

Er werden twee audits in opdracht gegeven en hun conclusies werden als samenvattingen gepubliceerd. De China Academy of Information and Communications Technology stelde vast dat de zcode-prod Alibaba Cloud OSS-bucket zich in wat Zhipu een zero-data-status noemt, bevond. Het beveiligingsbedrijf NSFOCUS meldde dat elk data-object en de bucket zelf waren verwijderd, en dat het in ZCode 3.14.0 geen resterend pad vond dat een lokale repository-snapshot kon activeren of bestanden naar buiten kon sturen. Het volledige beoordelingsrapport is niet verschenen, en The Next Web meldt dat Zhipu er geen datum voor heeft gegeven.

De klant die meer beweerde en het vervolgens introk

De meest ernstige claim van daadwerkelijk verlies kwam niet van ferstar. Op 19 september stuurde Taiyuan Chengming Technology, volgens China National Radio, Zhipu een juridische brief met nummer Chengming [2026] Legal Letter No. 1, die door ChainCatcher in detail werd weergegeven. Het bedrijf zei dat zes van zijn codeerwerkruimten zonder toestemming waren geüpload — 34.500 bestanden en ongeveer 425 MB aan platte tekst — en noemde volledige broncode, systeemarchitectuur, versiegeschiedenis, databasewachtwoorden, cloudreferenties en persoonlijke informatie van werknemers. Het zei dat een zevende werkruimte van 1.947 bestanden en ongeveer 144 MB was verpakt en versleuteld, maar dat 32 uploadpogingen mislukten. Het merkte ook op dat zijn cliënt op 16 september naar versie 3.12.3 was bijgewerkt, maar dat er op 18 september om 00:28 nog steeds uploads werden gedetecteerd, de ochtend waarop Zhipu zich verontschuldigde.

De brief stelde een vraag die de audits niet beantwoorden: of er gegevens het land hadden verlaten. Chengming zei dat de netwerkverzoeken van ZCode op een Singaporese entiteit waren gericht, terwijl de dienstverleningsovereenkomst met Beijing Zhipu Huazhang was ondertekend, en vroeg Zhipu aan te geven welke partij verantwoordelijk was en of er enige overdracht of opslag buiten het Chinese vasteland had plaatsgevonden. De brief bevatte twaalf eisen, waaronder het verwijderen van alle geüploade gegevens en afgeleiden daarvan, caches en back-ups met een schriftelijk bewijs, uitleggen waar de gegevens naartoe gingen en of die met derden werden gedeeld of voor training werden gebruikt, beschrijven hoe de privésleutel wordt bewaard en toegangslogboeken overleggen, de exacte reikwijdte van de bewering "vernietigd" definiëren, en schriftelijk toezeggen nooit meer te uploaden. Zhipu kreeg tot 10 oktober om schriftelijk te antwoorden en behield zich het recht voor schadevergoeding te eisen en bij toezichthouders te klagen. Caixin Global meldt dat Zhipu de beschuldigingen onwaar noemde.

Twee dagen later trok Chengming ze in. De financiële redactie van China National Radio meldt dat het bedrijf op 21 september een intrekking uitbracht met de mededeling dat zijn eerdere verklaringen berustten op onjuist bewijs, onnauwkeurige beschrijving en overdreven formulering, dat ze Zhipu's reputatie hadden geschaad, en dat het de media niet meer te woord zou staan. Reuters berichtte ook over de intrekking, volgens The Next Web. De archiefvermelding voor dit incident is gedateerd op 18 september, de dag van de ontdekking; de brief, de daarin genoemde deadline van 10 oktober en de intrekking kwamen allemaal na die datum. In openbare bronnen is eind oktober geen bij naam genoemd bedrijf te vinden dat achter een bewering staat dat zijn geheimen zijn blootgelegd.

Een open-source release waarvan de geschiedenis is gewist

Het open source maken van de client was het middel waarop Zhipu het sterkst leunde, en het bracht een gat met zich mee. The Paper meldt dat de gepubliceerde repository twee commits bevat: een lege eerste commit en één enkele commit die ongeveer 6.973 bestanden en 1,03 miljoen regels toevoegt, waarbij pull requests vergrendeld en issues gesloten zijn. Hoe de uploadpipeline er bij de release ook uitzag, en in welke releases die ook terechtkwam, staat niet in de geschiedenis die nu nog door iemand kan worden gelezen.

Ferstars eigen vervolgreactie maakt de beperking expliciet. Hij bevestigde dat de uploadpijplijn was verdwenen en dat het resterende checkpointmechanisme uitsluitend lokaal Git-werk uitvoert, en wees vervolgens op wat een audit van de bucket wel en niet kon aantonen: het leegmaken en verwijderen van de bucket is de juiste stop-lossactie, maar een controle door een derde die na 20 september wordt uitgevoerd, kan alleen vaststellen dat de bucket op dat moment leeg was. Die kan niet reconstrueren wat er vóór 18 september doorheen is gegaan, of er iets is ontsleuteld, gekopieerd of waarvan een back-up is gemaakt, of hoe lang de pijplijn al liep. Een bewering over verwijdering rust nog steeds grotendeels op het woord van de partij die heeft verwijderd.

De analyse van InfoQ somt de vragen die openblijven in dezelfde bewoordingen op: hoeveel repository-snapshots met succes zijn geüpload en door hoeveel gebruikers, hoe lang objecten werden bewaard, welke server-side systemen of medewerkers ze konden ontsleutelen, of er een volledig toegangslogboek bestaat, en of de verwijdering back-ups en andere kopieën omvatte. Ook wordt opgemerkt wat ZCode na de oplossing nog steeds is. De eigen NOTICE van het project waarschuwt dat de gedeelde agent-runtime standaard geen sandbox op besturingssysteemniveau biedt, en dat de client shell-, terminal-, Git-, MCP-, plug-in- en embedded-browseroppervlakken behoudt die bestanden kunnen lezen, processen kunnen starten en binnen de accountrechten van de gebruiker het netwerk kunnen bereiken.

Wat vaststaat, en wat geen enkele bron beantwoordt

Het mechanisme staat niet ter discussie. Zhipu's eigen verklaringen geven toe dat repositorygegevens zijn geüpload, dat de functie standaard ingeschakeld was en dat de gegevens naar een cloudbucket gingen die het bedrijf beheerde. Ferstars metingen, de verontschuldiging van de leverancier, twee in opdracht uitgevoerde audits en de open-source-release beschrijven allemaal dezelfde keten. Niets in het dossier betwist dat werkruimten de machines verlieten zonder een werkbare opt-out. De schade die het dossier registreert, is reëel in plaats van hypothetisch: de overdrachten hebben plaatsgevonden, en de mensen wier code erin zat, konden ze noch voorkomen noch inspecteren.

Wat ter discussie staat, of simpelweg onbekend is, zijn de schaal en de gevolgen. Geen enkele bron vermeldt hoeveel gebruikers met de getroffen standaardinstellingen werkten, hoe lang de pijplijn vóór 18 september in werking was, of ooit een geüpload object is gedecrypt. Zhipu's verzekering dat gegevens na het genereren van de wiki werden vernietigd en nooit voor training zijn gebruikt, is de eigen verklaring van het bedrijf; de bevindingen van CAICT en NSFOCUS beschrijven de staat van de bucket na de fix, niet wat erdoorheen is gegaan. Het archief kent het dossier een A toe voor documentatie, en de documentatie is sterk op mechanisme en zwak op reikwijdte.

Wat is er veranderd, en wat niet

De commerciële kosten waren direct. China National Radio meldt dat de in Hongkong genoteerde aandelen van Zhipu op 21 september met 1,79% daalden, op 22 september met 6,55% en op 23 september met 12,4%, een cumulatieve daling van meer dan 16% over drie handelssessies, en dat Zhipu niet inging op hoeveel gebruikers getroffen waren of of historische gegevens waren ontsleuteld of waarvan een back-up was gemaakt.

Wat een ZCode-gebruiker daadwerkelijk ontving in de vier dagen na de ontdekking:

• 18 september: een publieke verontschuldiging waarin codebase-indexering als oorzaak werd genoemd, een belofte om de client open source te maken en een externe review te laten uitvoeren, en één extra wekelijkse quotumreset per gebruiker.

• 19 september: ZCode 3.14.0, waarbij Repo Wiki is verwijderd en het lokaal genereren en uploaden van snapshots is geschrapt. Ferstar bevestigde de volgende dag dat de uploadketen verdwenen was.

• 20 september: een aangekondigde zero-retentionoptie voor Zhipu's MaaS-platform, opt-in, met uitzondering van Batch API en File API, en nog steeds onderworpen aan een wettelijke bewaartermijn van 30 dagen of langer.

• 21 september: ZCode gepubliceerd onder Apache 2.0 zonder de commitgeschiedenis van vóór het incident; samenvattingen van CAICT en NSFOCUS melden dat de storagebucket leeg is en het egress-pad afwezig.

Niets daarvan reikt terug. De specifieke vragen die Chengming opwierp — waar de data naartoe ging, wie die kon ontsleutelen, of die het land verliet, en wat "vernietigd" omvatte — werden op schrift gesteld met een deadline van 10 oktober, en werden vervolgens ingetrokken samen met het bedrijf dat ze had gesteld. Zhipu heeft een volledig beoordelingsrapport door een derde partij beloofd, zonder datum. Totdat er een verschijnt, is het enige openbare verslag van wat de pipeline deed met de data die deze ontving, het verslag van het bedrijf dat de pipeline heeft gebouwd, en het enige onafhankelijk meetbare artefact is een bestand van 313 MB dat er 564 keer niet in slaagde de laptop van één ontwikkelaar te verlaten.