xAI’s Grok Build CLI Exposes Sensitive Data in Cloud Uploads

Recent analysis has uncovered significant security vulnerabilities in xAI’s Grok Build Command Line Interface (CLI), particularly in version 0.2.93. The tool was found to transmit unredacted file contents, including sensitive information from .env files, and to upload entire Git repositories along with their complete commit histories to cloud storage.

Security researcher Cereblab conducted a wire-level examination of Grok Build’s operations. By capturing traffic through a proxy from controlled test repositories containing fake credentials, the researcher observed that when Grok Build accessed a local file, it sent the file’s contents verbatim through the model-request channel at the endpoint POST /v1/responses. This process exposed unredacted API keys and database passwords stored in .env files, which were included in the captured request data. Additionally, the same sensitive information was found in a session-state archive transmitted via POST /v1/storage.

Of particular concern was the discovery of a background upload mechanism within Grok Build. This feature allowed the tool to package and transfer entire Git repositories, including files that the agent had been explicitly instructed not to read, as well as the repository’s full commit history. In one test, the researcher instructed the tool with the prompt, “Reply with exactly: OK. Do not read or open any files.” Despite this directive, the captured upload revealed the presence of a planted file and its unique canary marker, indicating that the repository-upload mechanism operated independently of the files accessed during the model interaction.

Further large-scale testing involved a 12 GB repository filled with random files. During this test, the model channel for POST /v1/responses transferred approximately 192 KB, while the storage channel transferred at least 5.10 GiB before the capture was halted. The analysis noted 73 upload chunks, each about 75 MB, returning an HTTP 200 status, signifying successful multi-gigabyte transfers during the observed session.

The destination for these uploads was identified as a Google Cloud Storage bucket named “grok-code-session-traces.” Evidence supporting this identification included strings found within the Grok binary, staged metadata referencing gs://grok-code-session-traces/, and observed storage upload activity.

This issue poses immediate risks to developers managing proprietary source code, deployment files, internal documentation, credentials, and historical secrets stored in Git commits. Even if a user does not intentionally open a .env file, the discovery of a whole-repository upload can expose tracked content and history through the repository snapshot mechanism.

While the analysis does not confirm that xAI utilized the uploaded information to train its models, it does establish that the data was transmitted and accepted by the server. Whether this information was used for model training remains a separate policy and retention question.

Following the publication of these findings, xAI reportedly disabled codebase uploads via a server-side setting; however, the client capability to upload data remained. Cereblab researchers also identified local safeguards, including the configuration option [harness] disable_codebase_upload = true and telemetry controls. Users are advised to verify the behavior of these settings after CLI updates, as configuration options may change over time.

This incident underscores the critical importance of robust security practices in development tools, especially those handling sensitive data. Developers should exercise caution when using such tools and ensure that adequate safeguards are in place to protect their information.