xAI Grok CLI Exposed Git Repos and .env Secrets on Cloud Storage

Key Takeaways

• xAI’s Grok Build CLI (version 0.2.93) was found to transmit unredacted sensitive information, including API keys and database passwords from .env files.
• The CLI also uploaded entire Git repositories, complete with their full commit history, to a Google Cloud Storage bucket.
• This data exposure occurred even when users explicitly instructed the agent not to read or open files, indicating an independent background upload mechanism.
• While xAI has reportedly disabled codebase uploads server-side, the client-side capability persists, urging users to verify local safeguards and exercise caution.

A recent deep dive into the network traffic generated by xAI’s Grok Build CLI, specifically version 0.2.93, has uncovered critical security vulnerabilities. The analysis revealed that the tool was transmitting unredacted file contents, including sensitive data from .env configuration files, and was also uploading complete Git repositories, along with their entire commit histories, to cloud storage.

These concerning findings emerged from controlled tests conducted by security researcher Cereblab. The researcher employed proxy-based traffic capture against test repositories provisioned with fake canary credentials to monitor the CLI’s behavior.

Unredacted Secrets and Full Git Repositories Exposed

According to Cereblab’s report, when Grok Build accessed a local file, its contents were sent in an unmasked format through the model-request channel via POST /v1/responses. During testing, fake API keys and database passwords, typically stored in .env-style files, were observed unredacted within the captured request data. This same sensitive information was also found within a session-state archive transmitted via POST /v1/storage.

Even more alarming was the discovery of a distinct background upload mechanism. The analysis indicated that Grok Build possessed the capability to package and transfer an entire Git repository, extending beyond just the specific files required for a coding task. A captured Git bundle contained files that the agent had been explicitly instructed to ignore, alongside the repository’s complete commit history.

The Cereblab researcher tested this behavior using the prompt, “Reply with exactly: OK. Do not read or open any files.” Despite this clear instruction, the subsequent upload captured by the proxy included the planted file and its unique canary marker. This suggests that the repository-upload mechanism operated independently of the files directly engaged during model interaction.

Massive Data Transfers to Google Cloud Storage

The scale of these uploads was significant. In a large-scale test involving a 12 GB repository filled with random data, the model channel (POST /v1/responses) transferred approximately 192 KB. In stark contrast, the storage channel transferred at least 5.10 GiB before the capture process was halted. The report documented 73 upload chunks, each around 75 MB, all returning an HTTP 200 status, confirming 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 destination included strings found within the Grok binary, staged metadata referencing gs://grok-code-session-traces/, and the observed storage upload activity.

This vulnerability poses immediate and severe risks for developers and organizations. Proprietary source code, deployment configurations, internal documentation, credentials, and historical secrets embedded within Git commits are all potentially exposed. Even if a user does not explicitly open a .env file, the whole-repository upload mechanism can expose all tracked content and its full history through these repository snapshots.

While the analysis confirms the transmission and server-side acceptance of this data, it does not definitively prove that xAI utilized the uploaded information for model training. Whether this data was used for training remains a separate question pertaining to policy and retention practices.

Following the public disclosure of these findings, xAI reportedly disabled codebase uploads through a server-side configuration. However, the client-side capability to perform these uploads remains present. The Cereblab researchers also identified local safeguards, such as the configuration option [harness] disable_codebase_upload = true and telemetry controls. Users are strongly advised to verify the behavior of these settings after any CLI updates, as configuration precedence and remote feature flags can change.

What You Should Do

• Organizations utilizing Grok Build should consider their repositories potentially compromised until they can verify their installed version and configuration.
• Immediately remove all secrets, API keys, and sensitive credentials from Git repositories.
• Rotate any credentials that may have been exposed through previous Grok Build CLI usage.
• Conduct thorough scans of Git history to identify and purge any sensitive information.
• Restrict the Grok Build CLI to isolated development environments or sandboxed workspaces.
• Implement network monitoring to detect and alert on any unexpected outbound traffic originating from systems running the Grok Build CLI.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.