ZCode ha compresso 42.411 file in un archivio che solo Zhipu poteva aprire

Il 18 settembre 2026, uno sviluppatore che scrive sotto il nome ferstar ha pubblicato un'analisi tecnica dettagliata di ZCode, l'agente di programmazione AI per desktop realizzato dallo sviluppatore cinese di modelli Zhipu AI, dopo aver notato che una cartella nascosta nella sua directory home aveva superato i 700 MB. Al suo interno ha trovato un archivio crittografato da 313 MB contenente 42.411 file provenienti da uno spazio di lavoro da 345 MB, l'86,6% dei quali costituito dalla cronologia Git, impacchettato dal client e predisposto per il caricamento sull'archiviazione oggetti di Alibaba Cloud. L'archivio era sigillato con una chiave che solo i server di Zhipu potevano sbloccare, e il client non offriva alcuna opzione che impedisse la creazione dell'archivio. Zhipu si è scusata la stessa sera. Il resoconto completo, con il grado di confidenza e lo stato di danno dell'archivio stesso, si trova nel Orca AI Incident Archive, che registra ogni incidente AI documentato rispetto alle fonti citate.

ZCode è l'agente di coding desktop di Zhipu: legge un progetto, esegue comandi shell e scrive codice. L'azienda è quotata a Hong Kong con il ticker 2513.HK e commercializza la sua divisione internazionale con il marchio Z.ai, il nome che compare sui server ZCode ispezionati da ferstar. The Paper, il media di Shanghai che in seguito ha intervistato lui e diversi altri sviluppatori, riferisce che il suo post aveva all'incirca il titolo «Svelare il velo sul caricamento silenzioso dell'intera cronologia Git da parte di ZCode» e che si è diffuso nei gruppi di sviluppatori cinesi nel giro di poche ore dalla pubblicazione.

Che cosa c’era dentro la cartella nascosta?

I numeri di Ferstar stesso sono la spina dorsale del caso, e sono stati riprodotti in modo coerente da The Next Web, InfoQ e dalla redazione finanziaria di China National Radio. L'archivio nella sua directory dei checkpoint di ZCode era di 313 MB. Il file di stato accanto registrava un workspace di circa 345 MB e 42.411 file. La directory .git rappresentava l'86,6% del payload: 196,1 MB di cache Git large-file-storage, 102,2 MB di oggetti Git che contenevano l'intera cronologia dei commit e una piccola porzione di reflog. Il codice sorgente e la documentazione veri e propri costituivano circa il 13,4%.

La distinzione è importante perché la cronologia di Git è il luogo in cui tende a sopravvivere il materiale rimosso dall'albero corrente. Il resoconto del Paper lo afferma direttamente: un archivio di questo tipo può contenere la cronologia delle modifiche di un progetto fin dal suo primo commit, contenuti eliminati, bozze non sottoposte a commit e file di configurazione più datati, comprese le credenziali che furono rimosse dal codice molto tempo fa ma che restano nei commit precedenti e nella cache dei file di grandi dimensioni.

L'archivio da 313 MB di Ferstar non ha mai lasciato la sua macchina. Il suo registro di stato mostrava 564 tentativi di caricamento falliti ed era bloccato in uno stato in sospeso, oltre il limite di dimensione. Per verificare se la pipeline funzionasse affatto, provò un piccolo repository pubblico di 538 file; quello snapshot, compresso e cifrato, arrivò a circa 15 KB e fu accettato dal server. Quel trasferimento è l'unico nel registro confermato come completato end-to-end, ed è ciò che trasforma la scoperta da un esercizio di lettura del codice in un'esfiltrazione con una destinazione ricevente dimostrata.

La cattura non era legata ad alcuna azione che un utente riconoscerebbe come “caricare il mio repository”. Secondo la ricostruzione di ferstar, un trigger veniva attivato prima di ogni prompt inviato al modello, e un altro veniva eseguito come attività di aggiornamento di Repo Wiki. L'eliminazione dell'archivio in sospeso non lo ha fermato: un articolo sulla community per sviluppatori di Tencent Cloud riporta che il pacchetto è stato ricostruito entro 30 minuti e che il contatore dei fallimenti è passato da 564 a 565. L'unico modo affidabile per fermarla che l'autore abbia trovato è stato rendere non scrivibile la directory dei checkpoint, così che la cattura fallisse in fase di scrittura su disco, al prezzo di perdere il rollback dei checkpoint e l'interfaccia della timeline.

Una chiave che solo il fornitore poteva usare

La cifratura era una cifratura a busta da manuale, e questa è la parte che gli utenti non potevano aggirare. La ricostruzione di InfoQ, basata sul reverse engineering di ferstar, descrive il client che recupera da zcode.z.ai un ID snapshot, una chiave pubblica RSA e le credenziali di caricamento di Alibaba Cloud OSS, confeziona e cifra il workspace localmente, quindi invia il testo cifrato direttamente a OSS. Il contenuto veniva cifrato con AES-256-CTR; la chiave simmetrica veniva avvolta con RSA-OAEP-SHA256 sotto la chiave pubblica del server, la cui metà privata restava nel cloud di Zhipu.

L'instradamento è tanto significativo quanto la crittografia. Poiché il client ha caricato direttamente su Alibaba Cloud anziché attraverso i server applicativi di Zhipu, il traffico non è passato da un servizio Zhipu che potesse registrarlo o filtrarlo, quindi nessun servizio Zhipu si trovava nel percorso per registrare o filtrare ciò che usciva. E poiché la chiave privata non è mai stata sul dispositivo, ferstar non poteva aprire il proprio archivio: The Next Web riferisce che ha provato ogni chiave privata sulla sua macchina e ha fallito. Nel suo post ha descritto la soluzione come una chiave che solo il server può usare, con un unico scopo.

Due impostazioni nel client sembravano doverlo impedire, e nessuna delle due lo ha fatto. L'interruttore "ottimizza l'esperienza" stabiliva se i dati potevano essere usati per l'addestramento dei modelli; l'interruttore "indicizzazione delle istantanee del repository" stabiliva se il server costruiva un indice sulle istantanee già arrivate. Entrambe agiscono a valle dell'acquisizione. Ferstar ha scoperto che l'acquisizione era in esecuzione incondizionatamente, e The Next Web riferisce che, secondo la sua lettura dell'informativa sulla privacy, questa descriveva la raccolta di testo delle conversazioni e file ma non diceva nulla sulle istantanee automatiche dell'area di lavoro che contengono l'intera cronologia Git.

La spiegazione che Zhipu ha dato, e i quattro giorni successivi

Zhipu ha risposto lo stesso giorno, tramite il gruppo utenti ufficiale di ZCode anziché con un comunicato stampa. Come riportato da Global Times e ripubblicato da Security Inside, l'azienda ha attribuito il comportamento a una funzione chiamata indicizzazione della base di codice, che supporta l'indicizzazione locale, il ripristino dei checkpoint di sessione, il rollback delle versioni e la generazione di Repo Wiki, e ha affermato che il passaggio relativo a Repo Wiki era ciò che aveva attivato i caricamenti dei repository sul cloud. La funzione era attiva per impostazione predefinita fin dal lancio. Zhipu ha dichiarato che i dati caricati venivano usati solo per generare la pagina Repo Wiki ed erano distrutti immediatamente dopo, che non venivano archiviati né usati per l'addestramento, e si è scusata con gli utenti coinvolti. Ha promesso di rendere open source la base di codice di ZCode, invitare a una revisione di terze parti e pubblicare i risultati, e ha offerto a ogni utente di ZCode una reimpostazione aggiuntiva della quota settimanale come compensazione.

La correzione è arrivata il giorno successivo. The Paper riporta che ZCode 3.14.0 è stato distribuito il 19 settembre con una voce del changelog che recita "corregge il problema di caricamento anomalo del wiki del repository", e che ferstar ha confermato lo stesso giorno che la catena di caricamento e il suo endpoint erano scomparsi. Il 20 settembre, la piattaforma MaaS di Zhipu ha annunciato un'opzione di conservazione zero in arrivo, in base alla quale gli input e gli output non sarebbero stati archiviati in modo statico; The Paper osserva che è attivabile su richiesta per applicazione, esclude Batch API e File API e consente comunque la conservazione per 30 giorni o più quando la legge o un'indagine per abuso lo richiedono. Il 21 settembre il codice sorgente del client è diventato pubblico su GitHub con licenza Apache 2.0, comprendendo l'app desktop, il client web, il backend, la CLI dell'agente e il runtime dell'agente.

Sono stati commissionati due audit e le loro conclusioni sono state pubblicate sotto forma di sintesi. La China Academy of Information and Communications Technology ha rilevato che il bucket OSS di Alibaba Cloud zcode-prod si trova in quello che Zhipu definisce uno stato a zero dati. La società di sicurezza NSFOCUS ha riferito che ogni oggetto dati e il bucket stesso erano stati eliminati e che non ha trovato alcun percorso rimanente in ZCode 3.14.0 in grado di attivare uno snapshot di un repository locale o di inviare file all'esterno. Il rapporto di valutazione completo non è stato reso pubblico e The Next Web riferisce che Zhipu non ha indicato una data per la sua pubblicazione.

Il cliente che ha asserito di più, poi ha ritirato quanto detto

La dichiarazione più grave di una perdita effettiva non è arrivata da ferstar. Il 19 settembre, secondo China National Radio, Taiyuan Chengming Technology ha inviato a Zhipu una lettera legale recante il numero Chengming [2026] Legal Letter No. 1, riprodotta in dettaglio da ChainCatcher. L'azienda ha affermato che sei dei suoi spazi di lavoro di programmazione erano stati caricati senza consenso — 34.500 file e circa 425 MB in chiaro — e ha elencato codice sorgente completo, architettura del sistema, cronologia delle versioni, password dei database, credenziali cloud e informazioni personali dei dipendenti. Ha affermato che un settimo spazio di lavoro di 1.947 file e circa 144 MB era stato impacchettato e crittografato, ma che 32 tentativi di caricamento non erano andati a buon fine. Ha inoltre osservato che il suo client era stato aggiornato alla versione 3.12.3 il 16 settembre, eppure caricamenti sono stati ancora rilevati alle 00:28 del 18 settembre, la mattina in cui Zhipu ha chiesto scusa.

La lettera poneva una domanda a cui gli audit non rispondono: se i dati abbiano lasciato il Paese. Chengming ha dichiarato che le richieste di rete di ZCode puntavano a un'entità di Singapore mentre il suo contratto di servizio era stato firmato con Beijing Zhipu Huazhang, e ha chiesto a Zhipu di identificare quale parte fosse responsabile e se vi fossero stati trasferimenti o conservazione al di fuori della Cina continentale. La lettera elencava dodici richieste, tra cui cancellare tutti i dati caricati e i relativi derivati, le cache e i backup con un certificato scritto, spiegare dove sono finiti i dati e se sono stati condivisi con terzi o utilizzati per l'addestramento, descrivere come viene custodita la chiave privata e produrre i log di accesso, definire l'esatta portata dell'affermazione di «distruzione» e impegnarsi per iscritto a non caricare mai più. Fissava per Zhipu il termine del 10 ottobre per rispondere per iscritto e si riservava il diritto di chiedere il risarcimento dei danni e di presentare reclamo alle autorità di regolamentazione. Caixin Global riferisce che Zhipu ha definito le accuse non vere.

Due giorni dopo, Chengming le ritirò. La redazione finanziaria di China National Radio riferisce che il 21 settembre l'azienda ha diffuso una ritrattazione, affermando che le sue precedenti dichiarazioni si basavano su prove errate, descrizione imprecisa e formulazione esagerata, che avevano danneggiato la reputazione di Zhipu e che avrebbe smesso di parlare con i media. Anche Reuters ha riportato la ritrattazione, secondo The Next Web. La voce d'archivio relativa a questo incidente è datata 18 settembre, il giorno della scoperta; la lettera, la sua scadenza del 10 ottobre e la ritrattazione sono tutte giunte dopo quella data. Alla fine di ottobre, stando ai documenti pubblici, nessuna azienda nominata sostiene l'affermazione che i propri segreti siano stati esposti.

Un rilascio open source con la cronologia cancellata

Il rilascio in open source del client è stato il rimedio su cui Zhipu ha puntato con più forza, e ha portato con sé una lacuna. The Paper riporta che il repository pubblicato contiene due commit: un commit iniziale vuoto e un singolo commit che aggiunge circa 6.973 file e 1,03 milioni di righe, con pull request bloccate e issue chiuse. Qualunque aspetto avesse la pipeline di caricamento al momento del rilascio, e qualunque release la contenesse, non è nella cronologia che chiunque può ora leggere.

La stessa replica di Ferstar rende esplicito il limite. Ha confermato che la pipeline di upload non c'era più e che il meccanismo di checkpoint rimanente esegue solo operazioni Git locali, poi ha indicato cosa un audit del bucket poteva e non poteva dimostrare: svuotare ed eliminare il bucket è la giusta azione di stop-loss, ma un controllo di terze parti effettuato dopo il 20 settembre può stabilire solo che il bucket era vuoto a quel punto. Non può ricostruire cosa sia passato prima del 18 settembre, se qualcosa sia stato decrittografato, copiato o sottoposto a backup, o per quanto tempo la pipeline fosse in funzione. Un'affermazione di cancellazione si basa ancora in larga misura sulla parola della parte che ha cancellato.

L'analisi di InfoQ elenca le questioni ancora aperte negli stessi termini: quante snapshot dei repository sono state caricate con successo e da quanti utenti, per quanto tempo sono stati conservati gli oggetti, quali sistemi lato server o membri del personale potevano decifrarli, se esiste un log di accesso completo e se la cancellazione ha incluso backup e altre copie. Nota inoltre cos'è ancora ZCode dopo la correzione. Il NOTICE del progetto avverte che il runtime condiviso dell'agente non fornisce di default una sandbox a livello di sistema operativo, e il client conserva superfici shell, terminale, Git, MCP, plugin e browser integrato che possono leggere file, avviare processi e raggiungere la rete entro i permessi dell'account dell'utente.

Ciò che è stabilito e ciò a cui nessuna fonte dà risposta

Il meccanismo non è in discussione. Le stesse dichiarazioni di Zhipu ammettono che i dati del repository sono stati caricati, che la funzione era attiva per impostazione predefinita e che i dati sono finiti in un bucket cloud controllato dall’azienda. Le misurazioni di Ferstar, le scuse del fornitore, due audit commissionati e il rilascio open-source descrivono tutti la stessa catena. Nulla agli atti contesta che gli spazi di lavoro lasciassero le macchine senza un opt-out praticabile. Il danno che gli atti documentano è concretamente avvenuto, non ipotetico: i trasferimenti hanno avuto luogo e le persone il cui codice era al loro interno non hanno potuto né impedirli né ispezionarli.

Ciò che è in discussione, o semplicemente sconosciuto, sono la scala e le conseguenze. Nessuna fonte indica quanti utenti abbiano eseguito le configurazioni predefinite interessate, per quanto tempo la pipeline abbia operato prima del 18 settembre, o se qualche oggetto caricato sia mai stato decrittografato. L'assicurazione di Zhipu che i dati siano stati distrutti dopo la generazione della wiki e mai usati per l'addestramento è una dichiarazione dell'azienda stessa; i risultati di CAICT e NSFOCUS descrivono lo stato del bucket dopo la correzione, non ciò che vi è transitato. L'archivio assegna al record la valutazione A per la documentazione, e la documentazione è solida sul meccanismo e carente sull'ambito.

Cosa è cambiato e cosa no

Il costo commerciale è stato immediato. China National Radio riporta che le azioni di Zhipu quotate a Hong Kong sono scese dell'1,79% il 21 settembre, del 6,55% il 22 settembre e del 12,4% il 23 settembre, con un calo cumulativo superiore al 16% in tre sessioni di contrattazione, e che Zhipu non ha chiarito quanti utenti siano stati colpiti né se i dati storici siano stati decifrati o sottoposti a backup.

Ciò che un utente ZCode ha effettivamente ricevuto nei quattro giorni successivi alla scoperta:

• 18 settembre: delle scuse pubbliche che indicano l'indicizzazione del codebase come causa, la promessa di rendere open source il client e di commissionare una revisione indipendente, e un ulteriore reset settimanale della quota per utente.

• 19 settembre: ZCode 3.14.0, con Repo Wiki rimosso e la generazione locale degli snapshot e il percorso di caricamento eliminati. Ferstar ha confermato che la catena di caricamento non c'era più il giorno seguente.

• 20 settembre: un'opzione annunciata di conservazione zero per la piattaforma MaaS di Zhipu, su base opt-in, che esclude Batch API e File API e resta comunque soggetta a conservazione legale di 30 giorni o più.

• 21 settembre: ZCode pubblicato con licenza Apache 2.0 senza la cronologia dei commit precedenti all'incidente; le sintesi di CAICT e NSFOCUS riportano che il bucket di archiviazione è vuoto e che il percorso di uscita è assente.

Nulla di tutto ciò ha efficacia retroattiva. Le domande specifiche sollevate da Chengming — dove siano finiti i dati, chi potesse decifrarli, se abbiano lasciato il Paese e che cosa comprendesse "distrutti" — sono state messe per iscritto con scadenza al 10 ottobre, per poi essere ritirate insieme all'azienda che le aveva poste. Zhipu ha promesso un rapporto completo di valutazione di terze parti senza indicare una data. Finché non ne comparirà uno, l'unico resoconto pubblico di ciò che la pipeline ha fatto con i dati ricevuti è quello dell'azienda che l'ha costruita, e l'unico artefatto misurabile in modo indipendente è un file da 313 MB che per 564 volte non è riuscito a uscire dal portatile di uno sviluppatore.