Three days after a security researcher showed that ZCode packaged users' entire workspaces, including full Git history, and uploaded them encrypted to Alibaba Cloud object storage, the company behind it has published a full remediation statement. Z.ai open-sourced the client, invited two security firms to assess the fix, and promised rewards for future vulnerability reports.
This is the follow-up to my previous article covering the original research. Here is what the new statement says, what it resolves, and what it does not.
Quick recap of the incident
On Sep 18, 2026, a researcher known as ferstar published a reverse engineering writeup of ZCode, an AI coding desktop app from Zhipu (marketed globally as Z.ai). The findings were detailed and reproducible:
- The client packed the entire workspace into an archive, including the
.gitdirectory with every commit, Git LFS caches, and reflogs. - The archive was encrypted with AES-256-CTR, and the decryption key was wrapped with an RSA public key handed over by the server. The private key lived only in Z.ai's cloud.
- The encrypted package was uploaded straight to an Alibaba Cloud OSS bucket. In one capture, a 345MB commercial workspace became a 313MB archive, with 564 failed upload attempts logged.
The encryption detail mattered most: the data on disk was unreadable to the user, so only Z.ai could say what was inside the uploads, and only Z.ai could say whether the data was ever deleted. Zhipu confirmed the behavior the same day and blamed a default-on "Repo Wiki" indexing feature.
If you want the full technical breakdown, the original writeup is at blog.ferstar.org and my walkthrough of it is on DEV.
What the new statement says
The remediation statement was posted on X on Sep 21. The key points:
- Remediation is complete, with an apology to users.
- The client is now open source at github.com/zai-org/ZCode, "placing the code under community scrutiny." The repo was created on Sep 20 and already passed 3,400 stars within a day.
- An ongoing vulnerability reporting and response process is coming, with rewards "based on the severity of the issues reported."
- The company states that the code data referenced by the community "is not retained" and "has never been used for model training."
That last claim addresses the question many developers asked after the incident: did the uploaded snapshots feed the GLM models? The statement says no. It is a flat denial, and there is no way to independently verify training data usage. Take it for what it is: a commitment, not evidence.
Two third-party assessments
This is the most substantive part of the statement. After remediation, Z.ai invited the China Academy of Information and Communications Technology (CAICT) and NSFOCUS to conduct security assessments. Their findings, as summarized in the statement:
- CAICT confirmed the
zcode-prodAlibaba Cloud OSS bucket is in a zero-data state. Remediation is complete in the ZCode v3.14.0 client: the Repo Wiki feature is removed, and the workflow that generated and uploaded local repository snapshots is disabled. - NSFOCUS confirmed all data objects in the bucket, and the bucket itself, have been deleted. It also reported finding "no functional path capable of triggering the generation of local repository snapshots or transmitting local files externally" in the remediated client.
If accurate, this closes the loop that the encryption left open. The researcher could prove data left the machine, but nobody outside Z.ai could prove what happened to it afterward. Outside assessors confirming an empty and deleted bucket is the first external evidence on that question.
Two caveats keep this from being a full stop. First, both assessments were commissioned by Z.ai itself, and only summaries are public so far. The statement promises the full security assessment report "will be released soon," and that document is where the real scrutiny should land. Second, the assessments cover the post-remediation client and the bucket's current state. They say nothing about what happened to snapshots uploaded before the fix, or whether copies existed elsewhere.
What the open-source release changes
The open-source release is the checkable part of the response. Before this, every claim about ZCode's behavior rested on reverse engineering the packaged Electron app. Now the client source is public, so the questions shift:
- Anyone can read the v3.14.0 code and confirm the snapshot upload path is really gone, rather than dormant.
- Future features can be reviewed before release instead of discovered after.
- The claim that "the agent's tool surface contains no upload tools" and that the old pipeline ran outside the agent loop can now be verified in source rather than inferred from a decompiled bundle.
The repo is one day old, so independent review has barely started. Open source is a mechanism, not a verdict. What makes it meaningful is whether security researchers actually dig in, and whether anything they find gets a fast, public fix under the new reporting process.
Where this leaves you
If you still use ZCode, the concrete items are simple: update to v3.14.0 or later, since that is the version both assessors cleared, and watch for the full assessment report before treating the third-party claims as settled. The reward program has no published scope or amounts yet.
The broader lesson from this incident still stands. The original failure was not a bug in the model or even a malicious feature. It was a product boundary problem: a default-on feature quietly moved your most sensitive files, your entire commit history, across a trust boundary you never agreed to. Encryption offered the appearance of protection while making the data unreadable to exactly the one person with the right to inspect it.
Z.ai's response is more complete than most: code you can read, assessors you can name, and a promise of a published report. Whether that earns back trust depends on the report, and on what the community finds in the source. Both are now possible, which is more than could be said a week ago.
Top comments (0)