ZCode's default key-generation method is alleged to be derivable from local machine information
BIBIBI
Correction：Classification and topic tags were corrected under the website section rules; the body and review decision remain unchanged.
AT A GLANCE
After ZCode was open-sourced, developers found that the default decryption key can be derived from the operating system, username, and user directory.
Article
Another security issue emerges after ZCode was open-sourced: the default encryption key can be derived from the username and path
Beating AI News reports that after ZCode was open-sourced, developers discovered another security issue in the code. ZCode encrypts and stores users' login credentials locally, but by default, the decryption key can be directly derived from the operating system, username, and user directory.
This information is generally not difficult to obtain. Once an attacker obtains the file in which ZCode stores credentials, they can regenerate the key using the public source code, without needing to break the encryption algorithm.
ZCode's official documentation states that these login credentials are "encrypted per device and cannot be decrypted after changing devices." However, the default implementation in the public source code does not use a device ID or hardware information. The official statement does not match the open-source code.
However, this is not a vulnerability that allows credentials to be stolen remotely out of thin air. An attacker must still first obtain the local credential file; users who set ZCODE_CREDENTIAL_SECRET themselves will not use the default key described above.
If the file is leaked, the login sessions for ZCode, Z.ai, or BigModel may be restored, allowing accounts to be impersonated or Coding Plan quotas to be consumed, but it will not result in the computer being compromised.
Original link https://m.theblockbeats.info/flash/368194
Key points
01
After ZCode was open-sourced, developers discovered another security issue in the code.
02
ZCode encrypts and stores users' login credentials locally, but by default, the decryption key can be directly derived from the operating system, username, and user directory.
03
This information is generally not difficult to obtain.
04
Once an attacker obtains the file in which ZCode stores credentials, they can regenerate the key using the public source code, without needing to break the encryption algorithm.
05
ZCode's official documentation states that these login credentials are "encrypted per device and cannot be decrypted after changing devices."
06
The default implementation in the public source code does not use a device ID or hardware information.
07
The official statement does not match the open-source code.
08
This is not a vulnerability that allows credentials to be stolen remotely out of thin air; an attacker must still first obtain the local credential file.
09
Users who set ZCODE_CREDENTIAL_SECRET themselves will not use the default key described above.
10
If the file is leaked, the login sessions for ZCode, Z.ai, or BigModel may be restored, allowing accounts to be impersonated or Coding Plan quotas to be consumed, but it will not result in the computer being compromised.
11
Original link https://m.theblockbeats.info/flash/368194。
AI-assisted interpretation
The following is analysis, separate from reported facts. Verify important claims independently.
Simply put, ZCode encrypts and stores login credentials locally. Encryption should require a key known only to the user or the device, but under the default approach in the public source code, that key is derived from the operating system, username, and user directory. This information is often not difficult to learn, so anyone who obtains the file storing the credentials can use the source code to derive the key again, decrypt the data, and do so without breaking the encryption algorithm. The official documentation says that credentials are "encrypted per device," but the default implementation in the code does not use a device ID or hardware information. Note that this is not an issue enabling remote account theft out of thin air: the local file must first be obtained; if a user sets ZCODE_CREDENTIAL_SECRET themselves, this default key is not used.
Why it matters to readers
This shows that "encrypted storage" does not necessarily mean security: if the method used to generate a key can be guessed, encryption can only deter someone casually browsing files. Once credentials are restored, the login sessions for the related accounts may be impersonated, and plan quotas may even be consumed. It also underscores that official documentation must align with open-source code; otherwise, users may overestimate the strength of the protection.
For beginners, this is a useful example for understanding "key management": encryption strength depends not only on the algorithm, but also on how the key is generated and where it is stored. When reviewing security statements for open-source projects, consider whether documented commitments match the code implementation; for local credentials, use the project's custom-key or environment-variable options whenever possible.
Risks and unknowns
Related Developments
Loading event timeline…
The evidence does not specify the identity of ZCode's developer or affiliated organization.
The evidence does not specify whether the issue has been remediated, the remediation version, or the date.
The evidence does not specify the affected version range or specific platforms.
The evidence does not specify whether the official party has responded to the discrepancy between the documentation and the code.
The evidence does not provide the security researcher's identity or the original disclosure channel.
The evidence does not specify whether any actual attacks or credential-leak incidents have occurred.
The official documentation quotation and the code-analysis conclusion in the evidence come from the same news brief, with no independent source provided.
Related concepts
Open source
This term is not in the glossary yet. Browse related concepts in the glossary.
