SpaceXAI的Grok Build工具被爆上傳用戶完整程式碼庫至雲端,馬斯克承諾「完全徹底刪除」資料

Grok Build上傳用戶程式碼的技術機制是什麼?

根據iThome報導,研究團隊cereblab針對Grok Build CLI的0.2.93版本進行通訊協議分析,發現該工具會透過兩支API——即時對話API(POST /v1/response)以及工作區狀態API(POST /v1/storage)——將讀取過的檔案內容一字一句、不加遮蔽或刪減地傳送到SpaceXAI(E8)。

研究人員以一個12GB的專案進行測試,結果顯示對話本身僅產生192KB數據,但背後卻上傳了5.10GiB(約5.4GB)的資料,兩者比率達2.7萬倍(E9)。

更關鍵的是,這些資料的目的地並非SpaceXAI自有資料中心或AWS S3,而是Google Cloud Storage(GCS)儲存桶。研究人員表示,CLI的任何文件中都未提及此機制,顯示這是預設開啟,且無法透過關閉「改善模型」(improve the model)選項來阻止(E10)。

上傳的資料範圍有多廣,包括哪些敏感內容?

Cereblab於7月14日(週一)發布報告,指出Grok Build會打包上傳整個程式碼庫,其中包括「被指示不要開啟的檔案」以及「已從歷史紀錄刪除的機密」(E2)。

倫敦國王學院獨立安全研究員Lukasz Olejnik向The Verge證實,這種資料保留程度屬於「過度(excessive)」,並指出潛在風險資料可能包括「專有原始碼、安全漏洞資訊、個資、基礎設施細節,以及憑證」(E6)。這意味著Cereblab所發現的「刪除機密仍被上傳」的情況,恰好對應到Olejnik所列出的高風險資料類型。

SpaceXAI在問題曝光後採取了什麼補救措施?

The Verge報導,Grok Build CLI被發現將用戶整個程式碼庫上傳至Google Cloud一事遭披露後,SpaceXAI已將此功能關閉(E1)。研究人員測試證實,截至7月13日(週一),SpaceXAI伺服器已回傳disable_codebase_upload: true的旗標,程式庫上傳行為「不再觸發」(E3)。

根據iThome報導,SpaceXAI在報告公開後迅速回應,表示提供零資料保留(ZDR)選項:啟用該選項的專案,公司將不再儲存程式碼和runtime;未啟用ZDR的專案,則可在CLI中輸入/privacy來關閉資料保留(E11)。

馬斯克對此事的態度與承諾是什麼?

馬斯克在X上回應此事件,發文承諾Grok Build先前上傳的所有資料將被「完全徹底刪除(completely and utterly deleted)」(E4)。但他在另一則貼文中又表示「隱私設定一向受到尊重(privacy settings are always respected)」,並要求用戶允許SpaceXAI保留其資料,理由是這「有助於除錯」(E5)。

根據iThome報導,馬斯克所稱的「全數刪除、一點也不留」意味著連用戶刻意上傳的資料也會一併刪掉;但他之後又表示,這些資料有助於SpaceXAI除錯,如果用戶願意保留他會「很感激」,不過仍尊重用戶的選擇(E12)。前後兩則發言之間,存在「承諾刪除」與「呼籲保留」的明顯落差。

SpaceXAI聲稱的隱私控制機制是否有效?

SpaceXAI對外表示,ZDR選項與/privacy指令是回應此事件的隱私控制機制(E11)。但Cereblab在報告中直接反駁,指出「/privacy只是單次對話的資料保留開關,並非真正修復此問題的控制項,不應被當作解決方案來宣稱」(E7)。換言之,SpaceXAI所提出的控制工具,與研究人員認定「已修復上傳問題」的機制,並非同一件事。

獨立安全研究員如何評估此事件的風險?

Olejnik證實,此次資料保留程度「過度」,潛在暴露的資料類型涵蓋專有原始碼、安全漏洞資訊、個資、基礎設施細節與憑證(E6)。這項評估與Cereblab報告中「連被指示不開啟的檔案、已從歷史紀錄刪除的機密都遭上傳」的發現相互呼應(E2)——也就是說,研究人員實際攔截到的檔案類型,正好落在獨立安全專家所列的高風險清單之內。

這代表什麼

把各方證據並列可以看出幾組張力:技術面上,12GB專案測試出現對話數據與實際上傳量相差2.7萬倍(E9),顯示上傳規模遠超對話本身所需,而目的地是Google Cloud而非SpaceXAI自有基礎設施(E10);內容面上,Cereblab攔截到「被禁止開啟」與「已刪除」的檔案(E2),恰與Olejnik列出的專有原始碼、漏洞資訊、憑證等風險項目吻合(E6)。補救措施上,SpaceXAI已讓伺服器回傳停用旗標(E3),但Cereblab明確指出對外宣稱的/privacy指令並非真正修復該問題的開關(E7)。而馬斯克一方面承諾資料「完全徹底刪除」(E4),一方面又表示保留資料「有助於除錯」並希望用戶保留(E5、E12)——這兩則發言之間的落差,目前仍未見進一步澄清。