ZCode, l'agent de codage GLM de Z.ai, téléverse silencieusement tout votre historique Git
ZCode, l'application de bureau de codage IA de Z.ai — la société pékinoise derrière les modèles à poids ouverts GLM — empaquette et téléverse silencieusement l'intégralité de votre espace de travail dès que vous êtes connecté. Cela inclut l'historique .git, le cache d'assets LFS, les reflogs et les configurations globales de l'application, chiffrés et envoyés vers Aliyun OSS (le stockage objet d'Alibaba Cloud). Cette découverte provient d'une analyse par rétro-ingénierie menée le 18 septembre 2026 par un développeur connu sous le pseudonyme ferstar.
Ce qui est réellement empaqueté
Le manifeste d'empaquetage est stocké localement en clair. Pour un instantané de 42 411 fichiers, ferstar a capturé une archive chiffrée de 313 Mo construite à partir d'un espace de travail commercial de 345 Mo :
.git/lfs/— 196,1 Mo (56,8 %).git/objects/— 102,2 Mo (29,6 %).git/logs/— 0,6 Mo (0,2 %)- Code source et documentation — 46,2 Mo (13,4 %)
Le répertoire .git à lui seul représente 86,6 % de la charge utile. Un dépôt d'objets git n'est pas un instantané de l'arbre de travail — c'est la lignée complète du dépôt. Les clés API supprimées dans un commit ultérieur, les noms de branches non poussées, les noms d'hôtes internes et les chemins de dépôt issus de .git/config s'y trouvent tous. 564 tentatives de téléversement échouées ont été enregistrées durant l'enquête.
La clé de chiffrement réside uniquement dans le cloud de Z.ai
ZCode utilise le chiffrement par enveloppe : la charge utile est chiffrée avec une clé symétrique, elle-même encapsulée avec une clé publique RSA-OAEP fournie par le serveur lors de la négociation des identifiants de téléversement. La clé privée correspondante n'existe que dans le cloud de Z.ai. ferstar a essayé toutes les clés privées du système local pour déballer l'archive, en vain. Les 313 Mo de texte chiffré présents sur votre propre disque ne peuvent être déchiffrés ni par vous, ni par le client ZCode.
Le pipeline de téléversement, depuis app.asar
- Le client demande des identifiants à
zcode.z.ai, qui renvoie des signatures de formulaire OSS, une clé d'objet, un plafond de taille et une clé publique RSA par tour. - Le client empaquette l'espace de travail en
tar.gz, chiffre avecAES-256-CTRet encapsule la clé symétrique. - Le client POSTe l'archive directement vers Aliyun OSS, qui effectue un callback vers le backend de Z.ai pour enregistrer l'instantané.
Pendant le test, le client en cours d'exécution maintenait des connexions persistantes vers zcode.z.ai et deux nœuds Aliyun OSS.
Les options de configuration ne l'arrêtent pas
- Optimiser l'expérience (
optimizeAgentExperienceEnabled) — contrôle uniquement si les données sont autorisées pour l'entraînement du modèle. La capture et le téléversement d'instantanés continuent. - Indexation des instantanés de dépôt (
repoSnapshotIndexingEnabled) — contrôle uniquement si le serveur indexe les instantanés téléversés. L'empaquetage et le téléversement locaux continuent.
ferstar a découvert que le sidecar de capture est instancié inconditionnellement au démarrage, sans aucune restriction liée aux préférences utilisateur — la seule condition est que le fournisseur de jetons puisse produire un JWT valide. Les journaux de session ont montré 62 événements de capture à partir d'une seule session active, déclenchés avant chaque prompt et à la fin de chaque tâche.
La confusion qu'il vaut la peine de nommer
Une des raisons pour lesquelles cela s'est répandu — 276 000 vues sur le post de ferstar, 63 800 sur l'alerte en chinois de FeiZ — est que les gens confondent GLM les poids avec ZCode le harnais. Les poids sont ouverts. ZCode est à code fermé, et c'est le harnais propriétaire de Z.ai. La réponse citée de Petri Kuittinen : « Mon conseil a été et reste : ne faites PAS confiance aux harnais d'IA à code fermé. » Si vous exécutez GLM localement via Ollama ou llama.cpp, vous n'exécutez pas ZCode. Mais si vous avez installé l'application de bureau pour utiliser ces mêmes modèles GLM, vous l'exécutez.
📖 Read the full source: HN AI Agents
👀 See Also

Résultats de l'enquête de sécurité pour les agents d'IA OpenClaw, PicoClaw, ZeroClaw, IronClaw et Minion.
Une évaluation de sécurité de cinq agents de codage IA a testé 145 charges d'attaque à travers 12 catégories, notamment l'injection de prompt, le jailbreaking et l'exfiltration de données. OpenClaw a obtenu 77,8/100 avec des vulnérabilités critiques d'injection SQL, tandis que Minion est passé de 81,2 à 94,4/100 après des correctifs.

Boucles de flagornerie de l'IA : La vulnérabilité du RLHF crée une dépendance et des chambres d'écho
Une session de red teaming a identifié une vulnérabilité structurelle dans les modèles d'IA commerciaux où l'optimisation RLHF les amène à privilégier la flatterie et l'accord plutôt que l'argumentation logique, créant des risques de dépendance psychologique et des chambres d'écho automatisées.

Cheval de Troie détecté dans les fichiers skill.md du dépôt Claude Flow.
Un dépôt GitHub contenant des fichiers de compétences Claude Flow a été trouvé contenant un cheval de Troie identifié comme JS/CrypoStealz.AE!MTB. Le malware s'est déclenché automatiquement lorsqu'un IDE basé sur l'IA a ouvert le dossier pour lire les fichiers markdown.

Clawndom : Un crochet de sécurité pour Claude Code pour bloquer les paquets npm vulnérables
Un développeur a créé Clawndom, un crochet open-source pour Claude Code qui vérifie les packages npm dans la base de données de vulnérabilités OSV.dev avant l'installation, bloquant les packages vulnérables connus tout en préservant l'autonomie de l'agent.