ZCode packade 42 411 filer i ett arkiv som bara Zhipu kunde öppna

Den 18 september 2026 publicerade en utvecklare som skriver under namnet ferstar en teardown av ZCode, den stationära AI-kodagenten som görs av den kinesiska modellutvecklaren Zhipu AI, efter att ha märkt att en dold mapp i hans hemkatalog hade vuxit till över 700 MB. I den hittade han ett krypterat arkiv på 313 MB med 42 411 filer hämtade från en arbetsyta på 345 MB, varav 86,6 % var Git-historik, paketerat av klienten och förberett för uppladdning till Alibaba Cloud:s objektlagring. Arkivet var förseglat med en nyckel som bara Zhipus servrar kunde låsa upp, och klienten erbjöd ingen inställning som stoppade att det byggdes. Zhipu bad om ursäkt samma kväll. Det fullständiga registret, med arkivets egen konfidensgrad och skadestatus, finns i Orca AI Incident Archive, som loggar varje dokumenterad AI-incident mot de källor som citeras.

ZCode är Zhipus skrivbordsbaserade kodningsagent: den läser ett projekt, kör shellkommandon och skriver kod. Företaget handlas i Hongkong under tickern 2513.HK och marknadsför sin internationella gren som Z.ai, namnet som visas på de ZCode-servrar som ferstar granskade. The Paper, det shanghainesiska nyhetsmediet som senare intervjuade honom och flera andra utvecklare, rapporterar att hans inlägg hade rubriken, ungefär, ”Att dra undan ridån för ZCodes tysta uppladdning av hela Git-historiken”, och att det spreds i kinesiska utvecklargrupper inom några timmar efter publiceringen.

Vad fanns inuti den dolda mappen?

Ferstars egna siffror är ryggraden i fallet, och de har återgivits konsekvent av The Next Web, InfoQ och ekonomiredaktionen på China National Radio. Arkivet i hans katalog ZCode checkpoints var 313 MB. Statusfilen bredvid registrerade en arbetsyta på cirka 345 MB och 42 411 filer. Katalogen .git upptog 86,6 % av nyttolasten: 196,1 MB Git-cache för stora filer, 102,2 MB Git-objekt med hela commit-historiken och en liten del reflog. Den faktiska källkoden och dokumentationen utgjorde ungefär 13,4 %.

Distinktionen är viktig eftersom Git-historiken är där material som har tagits bort från det aktuella trädet tenderar att överleva. Papers redogörelse gör poängen direkt: ett arkiv av detta slag kan bära ett projekts redigeringshistorik från dess första commit, borttaget innehåll, ej committade utkast och äldre konfigurationsfiler, inklusive autentiseringsuppgifter som avlägsnades från koden för länge sedan men som finns kvar i tidigare commits och i cachen för stora filer.

Ferstars eget 313 MB-arkiv lämnade aldrig hans dator. Dess statuslogg visade 564 misslyckade uppladdningsförsök, och det hade fastnat i ett väntande tillstånd, över storleksgränsen. För att testa om pipelinen överhuvudtaget fungerade provade han ett litet offentligt repositorium med 538 filer; den ögonblicksbilden komprimerades och krypterades till ungefär 15 KB och accepterades av servern. Den överföringen är den i registret som bekräftats ha slutförts från början till slut, och det är den som förvandlar fyndet från en kodläsningsövning till en exfiltrering med en påvisad mottagarsida.

Infångningen var inte kopplad till någon åtgärd som en användare skulle känna igen som ”ladda upp mitt repo”. Enligt ferstars rekonstruktion aktiverades en utlösare före varje prompt som skickades till modellen, och en annan kördes som en Repo Wiki-uppdateringsuppgift. Att radera det väntande arkivet stoppade den inte: ett inlägg i Tencent Clouds utvecklarkommunity dokumenterar att paketet byggdes om inom 30 minuter och att felräknaren ökade från 564 till 565. Det enda tillförlitliga stoppet som författaren hittade var att göra checkpoint-katalogen icke skrivbar så att infångningen misslyckades vid skrivningen till disk, till priset av att förlora checkpoint-återställning och tidslinjegränssnittet.

En nyckel som bara leverantören kunde använda

Krypteringen var en skolboksmässig envelope-kryptering, och det är den delen som användarna inte kunde kringgå. InfoQ:s rekonstruktion, baserad på ferstars reverse engineering, beskriver hur klienten hämtar ett snapshot-ID, en RSA-publik nyckel och uppladdningsuppgifter för Alibaba Cloud OSS från zcode.z.ai, paketerar och krypterar arbetsytan lokalt och sedan skickar chiffertexten direkt till OSS. Innehållet krypterades med AES-256-CTR; den symmetriska nyckeln omslöts med RSA-OAEP-SHA256 under serverns publika nyckel, vars privata halva förblev i Zhipus moln.

Routningen är lika betydelsefull som kryptografin. Eftersom klienten laddade upp direkt till Alibaba Cloud i stället för via Zhipus egna applikationsservrar passerade trafiken inte en Zhipu-tjänst som kunde logga eller filtrera den, så ingen Zhipu-tjänst satt i vägen för att logga eller filtrera det som lämnade. Och eftersom den privata nyckeln aldrig fanns på enheten kunde ferstar inte öppna sitt eget arkiv: The Next Web rapporterar att han provade varje privat nyckel på sin maskin och misslyckades. Han beskrev arrangemanget i sitt inlägg som en nyckel som bara servern kan använda, vilket har ett enda syfte.

Två inställningar i klienten såg ut som att de borde ha stoppat detta, och ingen av dem gjorde det. Reglaget "optimera upplevelsen" styrde om data fick användas för modellträning; reglaget "indexering av repository-ögonblicksbilder" styrde om servern byggde ett index över ögonblicksbilder som redan hade anlänt. Båda verkar först efter själva insamlingen. Ferstar fann att insamlingen kördes ovillkorligt, och The Next Web rapporterar att hans läsning av integritetspolicyn visade att den beskrev insamling av konversationstext och filer men inte nämnde något om automatiska arbetsyteögonblicksbilder som innehåller fullständig Git-historik.

Förklaringen som Zhipu gav, och de fyra dagarna efter den

Zhipu svarade samma dag, via ZCodes officiella användargrupp i stället för ett pressmeddelande. Enligt en rapport från Global Times som återpublicerats av Security Inside tillskrev företaget beteendet en funktion som kallas kodbasindexering, som stöder lokal indexering, återställning av sessionscheckpunkter, versionsåterställning och generering av Repo Wiki, och uppgav att det var Repo Wiki-steget som utlöste uppladdningar av kodförråd till molnet. Funktionen hade varit på som standard sedan lanseringen. Zhipu uppgav att uppladdade data endast användes för att generera Repo Wiki-sidan och förstördes omedelbart därefter, att de inte lagrades och inte användes för träning, och bad de drabbade användarna om ursäkt. Företaget lovade att göra ZCodes kodbas till öppen källkod, bjuda in till tredjepartsgranskning och publicera resultaten, och erbjöd varje ZCode-användare en extra veckokvotåterställning som kompensation.

Rättningen kom nästa dag. The Paper rapporterar att ZCode 3.14.0 släpptes den 19 september med en changelog-post med texten "åtgärda problemet med onormal uppladdning av förvarets wiki", och att ferstar samma dag bekräftade att uppladdningskedjan och dess slutpunkt var borta. Den 20 september meddelade Zhipus MaaS-plattform ett kommande nollbevarandealternativ där indata och utdata inte skulle lagras statiskt; The Paper noterar att det aktiveras efter ansökan, utesluter Batch API och File API och fortfarande tillåter lagring i 30 dagar eller mer när lagstiftning eller utredning av missbruk kräver det. Den 21 september blev klientkällkoden offentlig på GitHub under Apache 2.0-licensen och omfattade skrivbordsappen, webbklienten, backend, agent-CLI och agent runtime.

Två granskningar beställdes och deras slutsatser publicerades som sammanfattningar. China Academy of Information and Communications Technology fann att zcode-prod Alibaba Cloud OSS-bucket befann sig i vad Zhipu kallar ett nolldatatillstånd. Säkerhetsföretaget NSFOCUS rapporterade att varje dataobjekt och själva bucketen hade raderats, och att det inte hittade någon kvarvarande väg i ZCode 3.14.0 som kunde utlösa en lokal ögonblicksbild av repositoriet eller skicka ut filer. Den fullständiga bedömningsrapporten har inte publicerats, och The Next Web rapporterar att Zhipu inte har angett något datum för den.

Kunden som påstod mer och sedan drog tillbaka det

Det allvarligaste påståendet om faktisk förlust kom inte från ferstar. Den 19 september skickade Taiyuan Chengming Technology, enligt China National Radio, ett juridiskt brev till Zhipu med beteckningen Chengming [2026] Legal Letter No. 1, som återgavs i detalj av ChainCatcher. Företaget uppgav att sex av dess kodarbetsytor hade laddats upp utan samtycke – 34 500 filer och ungefär 425 MB i klartext – och listade fullständig källkod, systemarkitektur, versionshistorik, databaslösenord, molnuppgifter och anställdas personuppgifter. Det uppgav att en sjunde arbetsyta med 1 947 filer och cirka 144 MB hade paketerats och krypterats, men att 32 uppladdningsförsök hade misslyckats. Det noterade också att dess klient hade uppdaterats till version 3.12.3 den 16 september, men att uppladdningar ändå upptäcktes kl. 00:28 den 18 september, samma morgon som Zhipu bad om ursäkt.

Brevet ställde en fråga som granskningarna inte besvarar: huruvida data lämnade landet. Chengming sade att ZCodes nätverksförfrågningar pekade mot en singaporiansk enhet medan dess tjänsteavtal var undertecknat med Beijing Zhipu Huazhang, och bad Zhipu att identifiera vilken part som var ansvarig och huruvida någon överföring eller lagring hade skett utanför det kinesiska fastlandet. Brevet innehöll tolv krav, bland annat att radera all uppladdad data och dess derivat, cachar och säkerhetskopior med ett skriftligt intyg, förklara vart datan tog vägen och huruvida den delades med tredje parter eller användes för träning, beskriva hur den privata nyckeln förvaras och ta fram åtkomstloggar, definiera den exakta omfattningen av påståendet om "förstörd" data samt skriftligen förbinda sig att aldrig ladda upp igen. Det gav Zhipu till den 10 oktober att svara skriftligen och förbehöll sig rätten att kräva skadestånd och anmäla till tillsynsmyndigheter. Caixin Global rapporterar att Zhipu kallade anklagelserna osanna.

Två dagar senare drog Chengming tillbaka dem. China National Radios ekonomiredaktion rapporterar att företaget den 21 september publicerade ett tillbakadragande där det uppgav att dess tidigare uttalanden vilade på felaktiga bevis, oprecis beskrivning och överdrivet språkbruk, att de hade skadat Zhipus rykte och att det skulle sluta uttala sig i medier. Reuters rapporterade också om tillbakadragandet, enligt The Next Web. Arkivposten för denna händelse är daterad den 18 september, dagen för upptäckten; brevet, dess tidsfrist den 10 oktober och tillbakadragandet kom alla efter det datumet. Enligt offentliga uppgifter i slutet av oktober står inget namngivet företag bakom ett påstående om att dess hemligheter hade exponerats.

En utgåva med öppen källkod där historiken har raderats

Att öppna klientens källkod var den lösning som Zhipu lutade sig allra mest mot, och den hade en brist. The Paper rapporterar att det publicerade kodförrådet innehåller två commits: en tom första commit och en enda commit som lägger till cirka 6 973 filer och 1,03 miljoner rader, med pull requests låsta och issues stängda. Hur uppladdningspipelinen såg ut när den levererades, och vilka versioner som innehöll den, finns inte i den historik som någon nu kan läsa.

Ferstars egen uppföljning gör begränsningen explicit. Han bekräftade att uppladdningspipelinen hade försvunnit och att den återstående checkpoint-mekanismen endast utför lokalt Git-arbete, och påpekade sedan vad en granskning av bucketen kunde och inte kunde visa: att tömma och radera bucketen är rätt förlustbegränsande åtgärd, men en tredjepartskontroll som utförs efter 20 september kan endast fastställa att bucketen var tom vid den tidpunkten. Den kan inte rekonstruera vad som passerade före 18 september, huruvida något dekrypterades, kopierades eller säkerhetskopierades, eller hur länge pipelinen hade varit igång. Ett påstående om radering vilar fortfarande i betydande utsträckning på ordet från den part som raderade.

InfoQ:s analys listar de frågor som fortfarande är öppna i samma ordalag: hur många ögonblicksbilder av repositoryn som laddades upp framgångsrikt och av hur många användare, hur länge objekt behölls, vilka serversidiga system eller vilken personal som kunde dekryptera dem, om det finns en fullständig åtkomstlogg, och om raderingen omfattade säkerhetskopior och andra kopior. Den noterar också vad ZCode fortfarande är efter åtgärden. Projektets egen NOTICE varnar för att den delade agentkörningsmiljön inte tillhandahåller en sandlåda på operativsystemsnivå som standard, och att klienten behåller shell-, terminal-, Git-, MCP-, plugin- och inbäddade webbläsarytor som kan läsa filer, starta processer och nå nätverket inom användarens kontobehörigheter.

Vad som är fastställt, och vad ingen källa besvarar

Mekanismen är inte omtvistad. Zhipus egna uttalanden medger att repository-data laddades upp, att funktionen var på som standard och att data hamnade i en molnlagringskorg som företaget kontrollerade. Ferstars mätningar, leverantörens ursäkt, två beställda revisioner och den öppna källkodens release beskriver alla samma kedja. Inget i dokumentationen motsäger att arbetsytor lämnade maskinerna utan ett fungerande opt-out. Den skada som dokumentationen registrerar är realiserad snarare än hypotetisk: överföringarna ägde rum, och personerna vars kod fanns i dem kunde varken förhindra eller granska dem.

Det som är omtvistat, eller helt enkelt okänt, är omfattning och konsekvenser. Ingen källa anger hur många användare som körde de påverkade standardinställningarna, hur länge pipelinen var i drift före den 18 september, eller om något uppladdat objekt någonsin dekrypterades. Zhipus försäkran att data förstördes efter wiki-genereringen och aldrig användes för träning är företagets eget uttalande; CAICT:s och NSFOCUS:s fynd beskriver tillståndet för bucket:en efter åtgärden, inte vad som passerade genom den. Arkivet ger posten betyget A för dokumentation, och dokumentationen är stark på mekanism men tunn på omfattning.

Vad förändrades, och vad förändrades inte

Den kommersiella kostnaden var omedelbar. China National Radio rapporterar att Zhipus Hongkongnoterade aktier föll 1,79 % den 21 september, 6,55 % den 22 september och 12,4 % den 23 september, en sammanlagd nedgång på mer än 16 % under tre handelssessioner, och att Zhipu inte bemötte hur många användare som påverkades eller huruvida historiska data hade dekrypterats eller säkerhetskopierats.

Vad en ZCode-användare faktiskt mottog under de fyra dagarna efter upptäckten:

• 18 september: en offentlig ursäkt där kodbasindexering anges som orsaken, ett löfte att göra klienten till öppen källkod och beställa en tredjepartsgranskning, samt en extra veckovis kvotåterställning per användare.

• 19 september: ZCode 3.14.0, där Repo Wiki togs bort och genereringen av lokala ögonblicksbilder samt uppladdningsvägen skars bort. Ferstar bekräftade dagen därpå att uppladdningskedjan var borta.

• 20 september: ett aviserat nollagringsalternativ för Zhipus MaaS-plattform, opt-in, med undantag för Batch API och File API, och fortfarande underkastat lagstadgad lagring i 30 dagar eller mer.

• 21 september: ZCode publicerades under Apache 2.0 utan sin commit-historik från före incidenten; sammanfattningar från CAICT och NSFOCUS rapporterar att lagringshinken är tom och att utgångsvägen saknas.

Ingenting av det där når bakåt. De specifika frågor som Chengming reste – vart data tog vägen, vem som kunde dekryptera det, om det lämnade landet och vad "förstört" omfattade – lades skriftligen med en deadline den 10 oktober och drogs sedan tillbaka tillsammans med företaget som ställde dem. Zhipu har lovat en fullständig tredjepartsbedömningsrapport utan datum. Tills en sådan dyker upp är den enda offentliga redogörelsen för vad pipeline gjorde med data den tog emot företagets egen redogörelse – företaget som byggde den – och den enda oberoende mätbara artefakten är en fil på 313 MB som 564 gånger misslyckades med att lämna en utvecklares bärbara dator.