Grok Build CLI 0.2.93 में गंभीर सुरक्षा खामियां: पूरा रिपॉजिटरी और सीक्रेट्स चुपके से अपलोड

• मॉडल-टर्न चैनल (POST /v1/responses): इस चैनल के ज़रिए एजेंट द्वारा खोली गई फाइलें मॉडल को भेजी गईं। यह किसी भी क्लाउड-बेस्ड कोडिंग एजेंट का सामान्य व्यवहार है।
• स्टोरेज चैनल (POST /v1/storage): दूसरे चैनल के ज़रिए पूरे रिपॉजिटरी को एक git बंडल के रूप में पैकेज करके लगभग 75 MB के चंक्स में grok-code-session-traces नामक Google Cloud Storage बकेट पर अपलोड किया गया ।

डेटा के इस असमानुपातिक आकार ने साबित कर दिया कि यह अपलोड एजेंट द्वारा पढ़ी गई फाइलों पर निर्भर नहीं था। एक 12 GB के टेस्ट रिपॉजिटरी पर, स्टोरेज चैनल ने 73 चंक्स (सभी HTTP 200 रिस्पॉन्स के साथ) में 5.10 GiB डेटा ट्रांसफर किया, जबकि मॉडल-टर्न चैनल ने सिर्फ 192 KB डेटा भेजा — यानी लगभग ~27,800 गुना का अंतर । यहां तक कि जब एजेंट को "बस OK कहो, कोई फ़ाइल मत पढ़ो" जैसा सख्त निर्देश दिया गया, तब भी टूल ने पूरे रिपॉजिटरी को git बंडल के रूप में अपलोड कर दिया। कैप्चर किए गए बंडल को क्लोन करने पर एक फ़ाइल (src/_probe/never_read_canary.txt) और पूरा Git कमिट इतिहास रिकवर हो गया, जिसे पढ़ने से एजेंट को स्पष्ट रूप से मना किया गया था ।

बिना रिडक्शन के ट्रांसमिट किए गए सीक्रेट्स और फाइलों के प्रकार

• .env फाइलें, जिनमें API कीज़, डेटाबेस पासवर्ड और अन्य क्रेडेंशियल्स होते हैं, दोनों चैनलों के ज़रिए बिना किसी मास्किंग या रिडक्शन के वर्बेटिम (ज्यों का त्यों) ट्रांसमिट की गईं । नियंत्रित परीक्षणों में डेटाबेस क्रेडेंशियल्स और API कीज़ वाली 48 KB की एक फ़ाइल रिक्वेस्ट बॉडी में साफ़-साफ़ दिखाई दी ।
• रिपॉजिटरी की हर ट्रैक्ड फाइल और पूरा Git इतिहास (सभी कमिट्स, ब्रांचेज़, टैग) को बंडल करके अपलोड किया गया । इसका मतलब है कि जो सीक्रेट्स महीनों पहले कमिट किए गए थे और बाद में बदल दिए गए, वे भी अपलोड किए गए डेटा में मौजूद हो सकते हैं।
• अपलोड मशीनरी की पहचान बाइनरी में मौजूद एक फर्स्ट-पार्टी Rust क्रेट (xai-data-collector) के रूप में हुई, जिसमें crates/codegen/xai-data-collector/src/gcs.rs और crates/codegen/xai-grok-shell/src/upload/ जैसे सोर्स पाथ मौजूद थे ।
• एक 12 GB के वास्तविक कोडबेस पर, जिसमें कभी न पढ़ी जाने वाली रैंडम फाइलें थीं, स्टोरेज एंडपॉइंट ने बिना किसी आकार-आधारित अस्वीकृति के अपलोड स्वीकार कर लिए। एकमात्र नॉन-200 रिस्पॉन्स मॉडल-उपयोग कोटा त्रुटियां (402/429) थीं, स्टोरेज फेलियर नहीं ।

ऑप्ट-आउट टॉगल की विफलता

शोधकर्ता ने 'Improve the model' प्राइवेसी टॉगल का परीक्षण किया और पाया कि यह अपलोड को नहीं रोकता ।

• टॉगल को बंद करके रीस्टार्ट करने के बाद भी, सर्वर सेटिंग्स एंडपॉइंट trace_upload_enabled: true ही रिटर्न कर रहा था ।
• स्टोरेज चैनल HTTP 200 रिस्पॉन्स के साथ चंक्ड git-बंडल अपलोड स्वीकार करता रहा ।
• हार्नेस सेटिंग्स में disable_codebase_upload=true नामक एक कॉन्फिग ऑप्शन मौजूद है, लेकिन सर्वर-साइड व्यवहार के साथ इसका संबंध अप्रलेखित (undocumented) है, और शोधकर्ता के परीक्षणों ने दिखाया कि सर्वर ने क्लाइंट-साइड प्राथमिकताओं का सम्मान नहीं किया ।

प्रभावित डेवलपर्स के लिए अनुशंसित उपाय

मूल शोधकर्ता और बाद के विश्लेषणों ने निम्नलिखित उपाय सुझाए हैं :

उन टीमों के लिए तत्काल कार्रवाई जिन्होंने प्राइवेट रिपॉजिटरी पर Grok Build CLI का उपयोग किया:

• सभी क्रेडेंशियल्स को तुरंत बदलें (रोटेट करें) जो किसी भी .env फ़ाइल, कॉन्फ़िगरेशन फ़ाइल, या Grok Build के साथ उपयोग किए गए रिपॉजिटरी के Git इतिहास में मौजूद थे। हो सकता है कि वे grok-code-session-traces GCS बकेट में ट्रांसमिट और स्टोर हो गए हों ।
• Git इतिहास का ऑडिट करें उन सीक्रेट्स के लिए जो किसी पिछले कमिट में मौजूद रहे हों, क्योंकि CLI ने पूरा कमिट इतिहास भेजा है ।
• मान लें कि डेटा स्टोर हो गया है, सिर्फ ट्रांसमिट नहीं हुआ — सर्वर ने सभी स्टोरेज रिक्वेस्ट पर HTTP 200 रिस्पॉन्स दिया, जो स्वीकृति की पुष्टि करता है ।
• xAI से पूछें कि क्या बकेट डिलीट कर दी गई, उस पर कौन से एक्सेस कंट्रोल थे, और क्या उस पर कोई डेटा प्रोसेसिंग एग्रीमेंट (DPA) लागू था (खुलासे के समय कोई DPA प्रकाशित नहीं था) ।

किसी भी कोडिंग एजेंट के लिए आर्किटेक्चरल उपाय:

• एजेंट को कंटेनर/VMs में चलाएं जिसमें सिर्फ कार्य वाली डायरेक्टरी (task directory) माउंट हो, होम डायरेक्टरी, SSH एजेंट, Docker सॉकेट, या क्लाउड क्रेडेंशियल डायरेक्टरी एक्सपोज़ न हो ।
• एग्रेस कंट्रोल लागू करें: मॉडल इन्फ्रेंस एंडपॉइंट और ऑथेंटिकेशन होस्ट्स को अनुमति दें, लेकिन सीधे जेनेरिक ऑब्जेक्ट-स्टोरेज अपलोड को ब्लॉक करें। 100 MB से अधिक के ट्रांसफर पर अलर्ट जारी करें ।
• फुल-होस्ट पैकेट कैप्चर, DNS लॉगिंग और एंडपॉइंट नेटवर्क टेलीमेट्री का उपयोग करें ताकि बैकग्राउंड कोऑर्डिनेटर प्रोसेसेज द्वारा किए जाने वाले अपलोड का पता लगाया जा सके, जिन्हें फोरग्राउंड बाइट काउंटर मिस कर सकते हैं ।
• वायर कैप्चर के तहत न्यूनतम और अधिकतम प्रॉम्प्ट का परीक्षण करें — जहां एजेंट को फाइलें न पढ़ने का आदेश दिया गया हो, ऐसे मामले कॉन्टेक्स्ट विंडो से परे एक्सफिल्ट्रेशन का पता लगाने के लिए महत्वपूर्ण हैं ।
• कम से कम तीन प्रॉम्प्ट मामलों पर टेस्ट चलाएं: (1) "बस OK कहो, कोई फ़ाइल मत पढ़ो," (2) एक विशिष्ट फ़ाइल पढ़ो, (3) प्रोजेक्ट की भाषा का निरीक्षण करो — फिर प्रति एंडपॉइंट बाइट्स की तुलना करें ।