Grok Build CLI ने चुपचाप आपका पूरा रिपॉजिटरी अपलोड कर दिया

cereblab नाम के एक शोधकर्ता ने पाया कि xAI का Grok Build CLI, संस्करण 0.2.93, पूरे git रिपॉजिटरी — सीक्रेट, पूरा इतिहास, सब कुछ — को Google Cloud Storage बकेट में कॉपी कर रहा था, बिना उपयोगकर्ता को बताए।

क्या हुआ

टूल ने दो तरह के आउटबाउंड अनुरोध भेजे। मॉडल को भेजे गए अनुरोध POST /v1/responses पर जाते थे। लेकिन एक अलग POST /v1/storage कॉल पूरे वर्किंग ट्री और पूरे .git इतिहास को बंडल करके gs://grok-code-session-traces पर भेज देती थी।

यह बकेट xAI की है। अपलोड CLI के इस्तेमाल का एक साइड इफेक्ट मात्र था — कोई “एक्सपोर्ट” बटन नहीं, कोई संकेत नहीं, कोई चेतावनी नहीं।

आंकड़े चौंकाने वाले हैं। 12 GB के टेस्ट रिपॉजिटरी के साथ जहाँ मॉडल ने कोई फ़ाइल नहीं पढ़ी, /v1/responses ने ~192 KB ट्रांसमिट किया। /v1/storage ने 73 चंक्स में 5.10 GiB भेजा। यह 27,800× का अंतर है। मॉडल ने 192 KB संदर्भ का उपयोग किया; xAI के सर्वरों को आपका पूरा रिपॉजिटरी मिल गया।

कैनरी टेस्ट

cereblab ने एक अनोखी स्ट्रिंग के साथ never_read_canary.txt नामक फ़ाइल रखी। प्रॉम्प्ट शाब्दिक रूप से था “Reply with exactly: OK. Do not read or open any files.” मॉडल ने टेक्स्ट का पालन किया। कैनरी स्ट्रिंग अपलोड किए गए बंडल से बरामद कर ली गई।

तो यह डेटा निष्कासन मॉडल द्वारा मांग पर फ़ाइलें पढ़ने से प्रेरित नहीं था। यह एक बिल्ट-इन पाइपलाइन थी जो आपके अनुरोध की परवाह किए बिना चलती थी।

ऑप्ट आउट ने काम क्यों नहीं किया

“मॉडल को बेहतर बनाएँ” नामक एक सेटिंग है। इसे बंद करने से आपके डेटा का प्रशिक्षण उपयोग रुक जाना चाहिए। cereblab के कैप्चर ने दिखाया कि सर्वर फिर भी trace_upload_enabled: true और upload_enabled: true लौटा रहा था। अपलोड जारी रहा।

CLI में --deny फ्लैग है जो सीमित करता है कि मॉडल कौन सी फ़ाइलें पढ़ सकता है। यह केवल पढ़ने को रोकता है। नेटवर्क ईग्रेस पर इसका कोई प्रभाव नहीं — बंडल पहले ही बाहर जा रहा था।

gist में निष्कर्ष सीधे शब्दों में कहा गया है: “ऑप्ट आउट करने से आपका रिपॉजिटरी मशीन छोड़ने से नहीं रुकता।”

क्रॉस-टूल लीक

कैप्चर ने दिखाया कि टूल ने ~/.claude/ के तहत फ़ाइलें भी समेट लीं। यह एक अलग उत्पाद की कॉन्फ़िग निर्देशिका है। असंबंधित सेवाओं की कुंजियाँ — cereblab Baidu Miaoda API कुंजी का हवाला देता है — आपके रिपॉजिटरी के साथ मशीन छोड़ गईं।

एक अन्य शोधकर्ता जिसने निष्कर्षों को पुन: प्रस्तुत किया, ने अपने लॉग में 339 स्वचालित अपलोड पाए। उनमें से एक अपलोड में उनकी पूरी होम डायरेक्टरी थी — संभावित रूप से SSH कुंजी, पासवर्ड मैनेजर डेटा, ब्राउज़र प्रोफ़ाइल, सब कुछ उजागर।

रिमोट किल स्विच

12 जुलाई को, जैसे ही कहानी वायरल हुई, कुछ ऐसा हुआ जिसकी xAI ने कभी घोषणा नहीं की: वही क्लाइंट बाइनरी, उसी SHA-256 हैश के साथ, अचानक अलग सर्वर प्रतिक्रियाएँ प्राप्त करने लगी।

disable_codebase_upload: true. trace_upload_enabled: false.

अपलोड रुक गए। कोई क्लाइंट अपडेट नहीं। कोई चेंजलॉग नहीं। कोई सूचना नहीं।

इसका मतलब है कि xAI के पास हमेशा से किसी भी Grok CLI इंस्टॉलेशन पर, किसी भी समय, उपयोगकर्ता की जानकारी के बिना डेटा संग्रह को दूरस्थ रूप से सक्षम या अक्षम करने की क्षमता थी। उन्होंने बस इसे डिफ़ॉल्ट रूप से चालू छोड़ना और कभी इसका उल्लेख न करना चुना।

मस्क का जवाब

14 जुलाई को, एलन मस्क ने विवाद का जवाब एक शब्द के साथ दिया: “True.” उन्होंने आगे कहा:

“एहतियाती उपाय के रूप में, SpaceXAI पर अब तक अपलोड किया गया सभी उपयोगकर्ता डेटा पूरी तरह और संपूर्ण रूप से हटा दिया जाएगा। कुछ भी बिल्कुल शेष नहीं रहेगा।”

xAI ने एक साथ Grok CLI के लिए /privacy कमांड की घोषणा की:

/privacy — आपकी वर्तमान डेटा अवधारण स्थिति दिखाता है
/privacy opt-out — अवधारण को अक्षम करता है और पहले से सिंक किए गए डेटा का पूर्वव्यापी विलोपन ट्रिगर करता है

एंड्रयू मिलिच, Grok Build के प्रमुख, ने पुष्टि की कि गोपनीयता सेटिंग्स बदलने से पहले सिंक किए गए क्लाउड डेटा का विलोपन ट्रिगर होता है। एंटरप्राइज़ ग्राहकों को “Zero Data Retention” (ZDR) मोड मिलता है।

लेकिन यहाँ वह है जो नहीं बदला: कोई सुरक्षा सलाह जारी नहीं की गई। बिना सहमति के पूरे रिपॉजिटरी क्यों एकत्र किए गए, इसकी कोई व्याख्या नहीं। विलोपन का कोई स्वतंत्र ऑडिट नहीं। v0.2.98 चेंजलॉग ने रिपॉजिटरी अपलोड का कोई उल्लेख पूरी तरह छोड़ दिया।

कैसे जाँचें कि आप प्रभावित हुए या नहीं

CLI को MITM प्रॉक्सी के पीछे चलाएँ: HTTPS_PROXY=http://127.0.0.1:8080। grok-code-session-traces बकेट को हिट करने वाले POST /v1/storage पर नज़र रखें।
बाइनरी / स्ट्रिंग्स में हार्डकोडेड बकेट नाम grok-code-session-traces खोजें।
cereblab के रिप्रो रिपॉजिटरी में verify.sh है जो लौटाए गए बंडलों को फिर से डाउनलोड और अनपैक करता है ताकि आप देख सकें कि वास्तव में क्या गया।
किसी भी Grok CLI सत्र के दौरान Google Cloud Storage के लिए ट्रैफ़िक के आउटबाउंड ईग्रेस लॉग जाँचें।
अपनी वर्तमान डेटा अवधारण स्थिति देखने के लिए Grok CLI में /privacy चलाएँ।
एक अन्य शोधकर्ता ने अपने लॉग जाँचकर 339 अपलोड पाए — यदि आपने यह टूल कभी इस्तेमाल किया है, तो मान लें कि आपके रिपॉजिटरी मशीन छोड़ गए।

क्या करें

आगे डेटा अवधारण रोकने और पहले से अपलोड किए गए डेटा के विलोपन का अनुरोध करने के लिए तुरंत /privacy opt-out चलाएँ।
प्रभावित संस्करण (0.2.93) को पूरी तरह अनइंस्टॉल करें।
नेटवर्क स्तर पर Google Cloud Storage के लिए ईग्रेस ब्लॉक करें — फ़ायरवॉल नियम या Clash अस्वीकार नियम: (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com)।
यदि आपको इसका उपयोग जारी रखना ही है, तो ~/.grok/config.toml में जोड़ें:
```
[harness] disable_codebase_upload = true
[features] telemetry = false
[telemetry] trace_upload = false
```
हर उस क्रेडेंशियल को बदलें जो कभी इस संस्करण के साथ खोले गए किसी रिपॉजिटरी में था। .env फ़ाइलें अक्सर ट्रैक होती हैं या वर्किंग ट्री में रहती हैं, और .gitignore आपकी रक्षा नहीं करता — बंडल ने परवाह किए बिना ट्रैक की गई फ़ाइलें ले लीं। सब कुछ समझौता हुआ मानें।

डेटा मिटाया जा सकता है। भरोसा, इतनी आसानी से नहीं।

संदर्भ

ड्राफ़्ट रिपोर्ट: grokprivacy-draft
शोधकर्ता: github.com/cereblab
पुनरुत्पादन रिपॉजिटरी: cereblab/grok-build-exfil-repro
तकनीकी gist: cereblab का gist

Grok Build CLI ने चुपचाप आपका पूरा रिपॉजिटरी अपलोड कर दिया — .env फ़ाइलें भी शामिल