Grok Build 被曝上傳完整代碼庫，Git 歷史和密鑰一并傳走

2026 年 7 月 14 日，xAI 旗下編程工具 Grok Build CLI 被曝會在用戶不知情的情況下，將整個 Git 代碼倉庫上傳至云端，上傳內(nèi)容不僅包括當前代碼文件，還可能包含完整 Git 提交歷史以及 .env 文件中的密鑰等敏感信息。

安全研究人員 cereblab 對 Grok Build CLI 0.2.93 版本進行了網(wǎng)絡流量分析。

他在 macOS 上通過 mitmproxy 攔截工具發(fā)出的請求，并使用僅包含虛假“誘餌密鑰”的測試代碼庫進行驗證。

測試結(jié)果顯示，Grok Build 存在兩條代碼傳輸路徑。

第一條路徑是模型處理請求。當 Grok Build 主動讀取某個文件時，文件內(nèi)容會隨模型請求發(fā)送至 xAI。

研究人員發(fā)現(xiàn)，測試 .env 文件中的 API 密鑰和數(shù)據(jù)庫密碼以明文形式出現(xiàn)在請求數(shù)據(jù)中，未經(jīng)過脫敏處理。

第二條路徑則與模型是否讀取文件無關。

Grok Build 會將整個代碼倉庫打包為 Git bundle，通過 /v1/storage 接口上傳，其中包括所有受 Git 跟蹤的文件及完整提交歷史。即使研究人員明確要求 Grok“不要讀取任何文件”，一個從未被模型打開的測試文件仍可從上傳的數(shù)據(jù)包中完整恢復。

研究人員進一步使用一個包含約 12 GB 隨機文件的測試倉庫進行驗證。測試期間，與模型交互相關的數(shù)據(jù)量只有約 192 KB，但代碼存儲接口累計上傳約 5.1 GiB 數(shù)據(jù)，相關上傳請求均返回 HTTP 200。即使模型請求因額度限制返回錯誤，代碼庫上傳仍在繼續(xù)。

分析顯示，這些代碼數(shù)據(jù)被發(fā)送至名為 grok-code-session-traces 的 Google Cloud Storage 存儲桶。Grok Build 客戶端程序中還包含與該存儲桶、Google 云存儲地址及上傳隊列有關的代碼和字符串。

值得注意的是，關閉 Grok 設置中的“Improve the model”（幫助改進模型）選項，并不一定會停止代碼上傳。

研究人員測試時，服務器仍返回 trace_upload_enabled: true。這說明該選項主要控制模型訓練授權，與代碼是否離開本地設備并非同一機制。

不過，現(xiàn)有證據(jù)只能證明代碼數(shù)據(jù)經(jīng)過傳輸、被服務器接收并進入存儲流程，不能證明 xAI 已使用這些代碼訓練模型，也不能證明 xAI 員工曾查看相關代碼。研究人員的測試也僅針對 Grok Build CLI 0.2.93 版本及特定賬戶環(huán)境。

報道公開后，研究人員再次測試發(fā)現(xiàn)，xAI 疑似已通過服務器端配置暫停相關上傳。

新的服務器配置返回 disable_codebase_upload: true 和 trace_upload_enabled: false，連續(xù)多次測試均未再次發(fā)現(xiàn)代碼倉庫上傳。

這一調(diào)整沒有通過客戶端更新發(fā)布，也未出現(xiàn)在 Grok Build 更新日志中。

xAI 官方更新日志顯示，7 月 12 日發(fā)布的最新版本為 0.2.98，但其中沒有提到代碼倉庫上傳、數(shù)據(jù)留存或安全修復。

xAI 隨后回應稱，對于啟用“零數(shù)據(jù)保留”（ZDR）的團隊，Grok Build 不會保留任何運行軌跡或代碼數(shù)據(jù)，通過 API 密鑰使用 Grok Build 時同樣遵循 ZDR。若用戶未啟用 ZDR，可在 CLI 中輸入 /privacy 命令關閉數(shù)據(jù)保留；xAI 表示，該操作還會刪除此前已經(jīng)同步的數(shù)據(jù)，用戶也可隨時通過該命令查看或修改隱私設置。

xAI 于 2026 年 5 月推出 Grok Build，定位為直接運行在終端中的編程智能體，目前仍處于測試階段，可用于代碼分析、修改、測試和多智能體協(xié)作等復雜軟件開發(fā)任務。

參考資料：

https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547

云頭條聲明：如以上內(nèi)容有誤或侵犯到你公司、機構、單位或個人權益，請聯(lián)系我們說明理由，我們會配合，無條件刪除處理。