xAI's Grok Build Leaks Entire Git Repositories to Cloud Storage
xAI's Grok Build coding CLI inadvertently uploaded full Git repositories, including commit history, to xAI's storage instead of just necessary files.
xAI's Grok Build coding CLI, specifically version 0.2.93, has been found to upload entire Git repositories, complete with their commit history, to a Google Cloud Storage bucket managed by xAI. This behavior occurred even when the uploaded files were not directly relevant to the coding task at hand, raising significant concerns about data exfiltration and privacy.
A security researcher, operating under the pseudonym cereblab, discovered this vulnerability while testing the CLI. By intercepting the upload traffic, the researcher was able to retrieve the full repository data. The analysis revealed a stark contrast between the data sent for the AI model's processing and the data sent for storage: approximately 192 KB for model responses versus 5.10 GiB for storage, indicating a massive discrepancy in the volume of data being transferred.
The uploaded data was sent in approximately 75 MB chunks to a bucket named grok-code-session-traces. The researcher confirmed the transmission, acceptance, and storage of the entire repository, including a deliberately placed file (src/_probe/never_read_canary.txt) that the model was instructed not to access. This file, along with the complete commit history, was recovered from the captured bundle, demonstrating the tool's tendency to sweep up more than just the immediate files required for a task.
Beyond the wholesale repository uploads, the Grok Build CLI also exhibited a critical flaw in handling sensitive information. When the Grok model read a file containing credentials, such as fake API keys and database passwords in a .env file, these unredacted secrets were included in the model turn traffic. Furthermore, the same sensitive content was also archived and sent to the storage bucket as part of a session state, even though the test secrets were not real.
Crucially, disabling the "Improve the model" setting, which is intended to prevent data from being used for training, did not stop these extensive uploads. The CLI's server-side response indicated trace_upload_enabled: true, suggesting that this setting only controls model training and not the broader data exfiltration to storage. This lack of user control over code leaving the machine is a significant security oversight.
In response to the researcher's findings, xAI appears to have disabled the storage upload functionality server-side for version 0.2.93. The researcher observed that subsequent tests showed zero /v1/storage uploads, and the server began returning disable_codebase_upload: true and trace_upload_enabled: false. While xAI has communicated via social media, promising deletion of all user data uploaded prior to the fix and offering a /privacy command for individual subscribers to disable retention, a formal security advisory or detailed explanation of the incident's scope and duration remains absent.
This incident highlights the broader risks associated with cloud-based coding assistants. Unlike some competitors such as Claude Code, Codex, and Gemini, which reportedly do not send entire repository bundles, Grok Build's behavior was an outlier. The potential for proprietary code, internal URLs, customer data, and even previously committed but deleted credentials to be exposed through commit history underscores the need for extreme caution when using such tools.
Experts advise users who have previously employed Grok Build to rotate any credentials that the tool might have accessed, including those in tracked files or commit history, even if they were later deleted. The upload code was reportedly still present in a later binary version (0.2.99), indicating that xAI could re-enable this functionality server-side without requiring a client update, emphasizing the ongoing need for vigilance.