ZCode a empaqueté 42 411 fichiers dans une archive que seul Zhipu pouvait ouvrir

Le 18 septembre 2026, un développeur qui écrit sous le nom ferstar a publié une analyse détaillée de ZCode, l’agent de codage IA de bureau créé par le développeur chinois de modèles Zhipu AI, après avoir remarqué qu’un dossier caché de son répertoire personnel avait dépassé 700 Mo. Il y a trouvé une archive chiffrée de 313 Mo contenant 42 411 fichiers issus d’un espace de travail de 345 Mo, dont 86,6 % d’historique Git, empaquetée par le client et préparée pour un envoi vers le stockage objet d’Alibaba Cloud. L’archive était scellée par une clé que seuls les serveurs de Zhipu pouvaient déchiffrer, et le client ne proposait aucun interrupteur permettant d’empêcher sa création. Zhipu s’est excusé le soir même. Le dossier complet, avec la note de confiance et le statut de préjudice propres à l’archive, se trouve dans Orca AI Incident Archive, qui consigne chaque incident d’IA documenté en regard de ses sources citées.

ZCode est l'agent de codage de bureau de Zhipu : il lit un projet, exécute des commandes shell et écrit du code. L'entreprise est cotée à Hong Kong sous le symbole 2513.HK et commercialise sa branche internationale sous le nom Z.ai, le nom qui apparaît sur les serveurs ZCode qu'a inspectés ferstar. The Paper, le média d'information de Shanghai qui l'a interrogé, lui et plusieurs autres développeurs par la suite, rapporte que son billet avait pour titre, en substance, « Lever le rideau sur le téléversement silencieux de l'historique Git complet par ZCode », et qu'il s'est propagé dans les groupes de développeurs chinois en quelques heures après sa publication.

Qu’y avait-il dans le dossier caché ?

Les propres chiffres de Ferstar constituent la colonne vertébrale de l’affaire, et ils ont été repris de manière cohérente par The Next Web, InfoQ et le service financier de China National Radio. L’archive dans son répertoire de points de contrôle ZCode faisait 313 Mo. Le fichier d’état à côté indiquait un espace de travail d’environ 345 Mo et 42 411 fichiers. Le dossier .git représentait 86,6 % de la charge utile : 196,1 Mo de cache Git de stockage de fichiers volumineux, 102,2 Mo d’objets Git portant l’historique complet des commits, et une petite part de reflog. Le code source et la documentation proprement dits représentaient environ 13,4 %.

La distinction est importante, car c’est dans l’historique Git que les éléments supprimés de l’arbre actuel ont tendance à subsister. Le compte rendu de The Paper le dit directement : une archive de ce type peut contenir l’historique des modifications d’un projet depuis son premier commit, du contenu supprimé, des brouillons non commités et d’anciens fichiers de configuration, y compris des identifiants qui ont été retirés du code il y a longtemps mais qui subsistent dans des commits antérieurs et dans le cache des fichiers volumineux.

L’archive personnelle de 313 Mo de Ferstar n’a jamais quitté sa machine. Son journal d’état indiquait 564 tentatives de téléversement échouées, et elle était bloquée dans un état en attente, au-delà de la limite de taille. Pour vérifier si le pipeline fonctionnait tout court, il a essayé un petit dépôt public de 538 fichiers ; cet instantané, une fois compressé et chiffré, faisait environ 15 Ko et a été accepté par le serveur. C’est ce transfert qui est consigné comme ayant été mené de bout en bout, et c’est ce qui fait passer la découverte d’un exercice de lecture de code à une exfiltration avec un point de réception démontré.

La capture n’était liée à aucune action qu’un utilisateur reconnaîtrait comme « téléverser mon dépôt ». D’après la reconstitution de ferstar, un déclencheur se lançait avant chaque prompt soumis au modèle, et un autre s’exécutait comme tâche de mise à jour de Repo Wiki. Supprimer l’archive en attente ne l’a pas arrêté : un article de la communauté des développeurs de Tencent Cloud rapporte que le paquet a été reconstruit en moins de 30 minutes et que le compteur d’échecs est passé de 564 à 565. Le seul arrêt fiable que cet auteur a trouvé consistait à rendre le répertoire de points de contrôle non accessible en écriture afin que la capture échoue à l’écriture sur disque, au prix de la perte de la restauration des points de contrôle et de l’interface de chronologie.

Une clé que seul le vendeur pouvait utiliser

Le chiffrement était un chiffrement d’enveloppe classique, et c’est la partie que les utilisateurs ne pouvaient pas contourner. La reconstruction d’InfoQ, tirée de l’ingénierie inverse de ferstar, décrit le client récupérant un ID de snapshot, une clé publique RSA et des identifiants de téléversement vers Alibaba Cloud OSS depuis zcode.z.ai, empaquetant et chiffrant l’espace de travail localement, puis envoyant le texte chiffré directement à OSS. Le contenu était chiffré avec AES-256-CTR ; la clé symétrique était enveloppée avec RSA-OAEP-SHA256 sous la clé publique du serveur, dont la partie privée restait dans le cloud de Zhipu.

Le routage est aussi déterminant que la cryptographie. Comme le client a téléversé directement vers Alibaba Cloud plutôt que via les serveurs d’application propres à Zhipu, le trafic n’a pas traversé de service Zhipu susceptible de l’enregistrer ou de le filtrer ; ainsi, aucun service Zhipu ne se trouvait sur le chemin pour journaliser ou filtrer ce qui sortait. Et comme la clé privée n’a jamais été sur l’appareil, ferstar n’a pas pu ouvrir sa propre archive : The Next Web rapporte qu’il a essayé toutes les clés privées de sa machine et a échoué. Il a décrit ce dispositif dans son billet comme une clé que seul le serveur peut utiliser, qui n’a qu’un seul but.

Deux paramètres du client semblaient devoir empêcher cela, et aucun ne l’a fait. Le bouton « optimiser l’expérience » déterminait si les données pouvaient être utilisées pour l’entraînement des modèles ; le bouton « indexation des instantanés du dépôt » déterminait si le serveur construisait un index sur les instantanés déjà arrivés. Les deux agissent en aval de la capture. Ferstar a constaté que la capture s’exécutait sans condition, et The Next Web rapporte que sa lecture de la politique de confidentialité lui a montré qu’elle décrivait la collecte du texte des conversations et des fichiers, mais ne disait rien des instantanés automatiques de l’espace de travail contenant l’historique Git complet.

L'explication donnée par Zhipu, et les quatre jours qui ont suivi

Zhipu a répondu le jour même, via le groupe d'utilisateurs officiel de ZCode plutôt que par un communiqué de presse. Comme l'a rapporté Global Times et comme l'a relayé Security Inside, l'entreprise a attribué ce comportement à une fonctionnalité appelée codebase indexing, qui prend en charge l'indexation locale, la restauration de points de contrôle de session, le retour à une version antérieure et la génération de Repo Wiki, et a déclaré que c'était l'étape Repo Wiki qui avait déclenché l'envoi des dépôts vers le cloud. La fonctionnalité était activée par défaut depuis le lancement. Zhipu a affirmé que les données envoyées servaient uniquement à générer la page Repo Wiki et étaient détruites immédiatement après, qu'elles n'étaient ni stockées ni utilisées pour l'entraînement, et s'est excusé auprès des utilisateurs concernés. L'entreprise s'est engagée à publier le code source de ZCode en open source, à inviter des tiers à l'examiner et à publier les résultats, et a offert à chaque utilisateur de ZCode une réinitialisation de quota hebdomadaire supplémentaire en guise de compensation.

Le correctif est arrivé le lendemain. The Paper rapporte que ZCode 3.14.0 est sorti le 19 septembre avec une entrée de journal des modifications indiquant « corriger le problème de téléversement anormal du wiki du dépôt », et que ferstar a confirmé le jour même que la chaîne de téléversement et son point de terminaison avaient disparu. Le 20 septembre, la plateforme MaaS de Zhipu a annoncé une option de rétention zéro à venir, selon laquelle les entrées et les sorties ne seraient pas stockées statiquement ; The Paper note qu’elle est activable sur demande, qu’elle exclut Batch API et File API, et qu’elle permet encore une conservation de 30 jours ou plus lorsque la loi ou une enquête pour abus l’exige. Le 21 septembre, le code source du client est devenu public sur GitHub sous licence Apache 2.0, couvrant l’application de bureau, le client web, le backend, l’agent CLI et l’environnement d’exécution de l’agent.

Deux audits ont été commandés et leurs conclusions ont été publiées sous forme de résumés. La China Academy of Information and Communications Technology a constaté que le bucket OSS Alibaba Cloud zcode-prod se trouvait dans ce que Zhipu appelle un état zéro donnée. La société de sécurité NSFOCUS a rapporté que chaque objet de données et le bucket lui-même avaient été supprimés, et qu'elle n'avait trouvé aucun chemin restant dans ZCode 3.14.0 susceptible de déclencher un instantané de dépôt local ou d'envoyer des fichiers à l'extérieur. Le rapport d'évaluation complet n'a pas encore été publié, et The Next Web rapporte que Zhipu n'a donné aucune date pour sa publication.

Le client qui a allégué davantage, puis s’est rétracté

La plus grave allégation de perte réelle ne provenait pas de ferstar. Le 19 septembre, selon China National Radio, Taiyuan Chengming Technology a envoyé à Zhipu une lettre juridique portant la référence Chengming [2026] Legal Letter No. 1, reproduite en détail par ChainCatcher. La société a déclaré que six de ses espaces de travail de codage avaient été téléversés sans son consentement — 34 500 fichiers et environ 425 Mo en clair — et y listait du code source complet, l’architecture système, l’historique des versions, des mots de passe de bases de données, des identifiants cloud et des informations personnelles d’employés. Elle indiquait qu’un septième espace de travail de 1 947 fichiers et d’environ 144 Mo avait été empaqueté et chiffré, mais que 32 tentatives de téléversement avaient échoué. Elle notait également que son client avait été mis à jour vers la version 3.12.3 le 16 septembre, mais que des téléversements étaient encore détectés à 00 h 28 le 18 septembre, le matin où Zhipu a présenté ses excuses.

La lettre posait une question à laquelle les audits ne répondent pas : si les données avaient quitté le pays. Chengming a déclaré que les requêtes réseau de ZCode pointaient vers une entité singapourienne, tandis que son contrat de service avait été signé avec Beijing Zhipu Huazhang, et elle demandait à Zhipu d’identifier la partie responsable et de préciser si un transfert ou un stockage avait eu lieu hors de Chine continentale. La lettre énonçait douze exigences, notamment supprimer toutes les données téléversées et leurs dérivés, caches et sauvegardes, et fournir un certificat écrit ; expliquer où les données sont allées et si elles ont été partagées avec des tiers ou utilisées pour l’entraînement ; décrire comment la clé privée est conservée et produire les journaux d’accès ; définir la portée exacte de l’affirmation selon laquelle les données ont été « détruites » ; et s’engager par écrit à ne plus jamais téléverser de données. Elle donnait à Zhipu jusqu’au 10 octobre pour répondre par écrit et se réservait le droit de réclamer des dommages-intérêts et de déposer plainte auprès des autorités de régulation. Caixin Global rapporte que Zhipu a qualifié ces allégations de fausses.

Deux jours plus tard, Chengming les a retirées. Le service financier de China National Radio rapporte que, le 21 septembre, l’entreprise a publié une rétractation indiquant que ses déclarations antérieures reposaient sur des preuves erronées, une description imprécise et une formulation outrancière, qu’elles avaient nui à la réputation de Zhipu et qu’elle cesserait de s’exprimer auprès des médias. Selon The Next Web, Reuters a également rapporté le retrait. L’entrée d’archive relative à cet incident est datée du 18 septembre, jour de la découverte ; la lettre, son échéance du 10 octobre et la rétractation sont toutes intervenues après cette date. Dans les documents publics disponibles fin octobre, aucune entreprise nommée ne soutient une affirmation selon laquelle ses secrets auraient été exposés.

Une version open source dont l’historique a été effacé

L’ouverture du code source du client était le remède sur lequel Zhipu s’est le plus appuyé, et il s’accompagnait d’un trou. The Paper rapporte que le dépôt publié contient deux commits : un commit initial vide et un commit unique ajoutant environ 6 973 fichiers et 1,03 million de lignes, les pull requests étant verrouillées et les tickets fermés. Quelle que soit l’allure du pipeline de téléversement au moment de la livraison, et quelles que soient les versions qui le contenaient, cela ne figure pas dans l’historique que quiconque peut désormais lire.

La relance de Ferstar rend la limite explicite. Il a confirmé que le pipeline d’importation avait disparu et que le mécanisme de point de contrôle restant n’effectue que des opérations Git locales, puis il a souligné ce qu’un audit du bucket pouvait et ne pouvait pas démontrer : vider et supprimer le bucket est la bonne action de limitation des pertes, mais un contrôle effectué par un tiers après le 20 septembre ne peut établir que le bucket était vide à ce moment-là. Il ne peut pas reconstituer ce qui est passé avant le 18 septembre, si quoi que ce soit a été déchiffré, copié ou sauvegardé, ni depuis combien de temps le pipeline fonctionnait. Une affirmation de suppression repose encore largement sur la parole de la partie qui a supprimé.

L’analyse d’InfoQ dresse la liste des questions qui restent ouvertes dans les mêmes termes : combien d’instantanés de dépôt ont été téléversés avec succès et par combien d’utilisateurs, pendant combien de temps les objets ont été conservés, quels systèmes côté serveur ou quels membres du personnel pouvaient les déchiffrer, s’il existe un journal d’accès complet, et si la suppression couvrait les sauvegardes et les autres copies. Elle note aussi ce que ZCode est encore après le correctif. Le NOTICE du projet lui-même avertit que le runtime d’agent partagé ne fournit pas de bac à sable au niveau du système d’exploitation par défaut, et que le client conserve des surfaces shell, terminal, Git, MCP, plug-in et navigateur intégré qui peuvent lire des fichiers, démarrer des processus et accéder au réseau dans les limites des autorisations du compte de l’utilisateur.

Ce qui est établi, et ce à quoi aucune source ne répond

Le mécanisme ne fait pas débat. Les déclarations de Zhipu reconnaissent elles-mêmes que les données des dépôts ont été téléversées, que la fonctionnalité était activée par défaut et que les données sont allées dans un bucket cloud contrôlé par l’entreprise. Les mesures de Ferstar, les excuses du fournisseur, deux audits commandités et la publication en open source décrivent tous la même chaîne. Rien au dossier ne conteste que des espaces de travail ont quitté les machines sans possibilité de refus exploitable. Le préjudice consigné au dossier est réel et non hypothétique : les transferts ont eu lieu, et les personnes dont le code s’y trouvait ne pouvaient ni les empêcher ni les inspecter.

Ce qui est contesté, ou simplement inconnu, c’est l’ampleur et les conséquences. Aucune source n’indique combien d’utilisateurs ont utilisé les paramètres par défaut concernés, pendant combien de temps le pipeline a fonctionné avant le 18 septembre, ni si un objet téléversé a été un jour déchiffré. L’assurance de Zhipu selon laquelle les données ont été détruites après la génération du wiki et n’ont jamais servi à l’entraînement n’est que la déclaration de l’entreprise ; les conclusions de CAICT et de NSFOCUS décrivent l’état du bucket après la correction, et non ce qui y a transité. L’archive attribue au dossier la note A pour la documentation, et la documentation est solide sur le mécanisme mais lacunaire sur la portée.

Ce qui a changé, et ce qui n’a pas changé

Le coût commercial a été immédiat. China National Radio rapporte que les actions de Zhipu cotées à Hong Kong ont chuté de 1,79 % le 21 septembre, de 6,55 % le 22 septembre et de 12,4 % le 23 septembre, soit une baisse cumulée de plus de 16 % sur trois séances de bourse, et que Zhipu n'a pas précisé combien d'utilisateurs avaient été affectés ni si les données historiques avaient été déchiffrées ou sauvegardées.

Ce qu'un utilisateur de ZCode a réellement reçu dans les quatre jours suivant la découverte :

• 18 septembre : des excuses publiques désignant l’indexation de la base de code comme la cause, la promesse de rendre le client open source et de commander un examen par un tiers, ainsi qu’une réinitialisation supplémentaire du quota hebdomadaire par utilisateur.

• 19 septembre : ZCode 3.14.0, avec la suppression de Repo Wiki et la suppression de la génération locale d'instantanés ainsi que du chemin de téléversement. Ferstar a confirmé le lendemain que la chaîne de téléversement avait disparu.

• 20 septembre : une option de rétention zéro annoncée pour la plateforme MaaS de Zhipu, sur opt-in, à l'exclusion de Batch API et File API, et toujours soumise à une conservation légale de 30 jours ou plus.

• 21 septembre : ZCode publié sous Apache 2.0 sans l'historique de commits antérieur à l'incident ; les résumés de la CAICT et de NSFOCUS indiquent que le bucket de stockage est vide et que le chemin de sortie est absent.

Rien de tout cela n’a d’effet rétroactif. Les questions précises soulevées par Chengming — où étaient allées les données, qui pouvait les déchiffrer, si elles avaient quitté le pays et ce que recouvrait « détruit » — ont été consignées par écrit avec une échéance au 10 octobre, puis retirées en même temps que l’entreprise qui les avait posées. Zhipu a promis un rapport d’évaluation complet par un tiers, sans date. Tant qu’un tel rapport n’aura pas paru, le seul compte rendu public de ce que le pipeline a fait des données qu’il a reçues est celui de l’entreprise qui l’a construit, et le seul artefact mesurable de manière indépendante est un fichier de 313 Mo qui a échoué 564 fois à quitter l’ordinateur portable d’un développeur.