नुकत्याच समोर आलेल्या विंडोजमधील एका त्रुटीमुळे (CVE-2026-35603), कोणताही नॉन-अॅडमिन वापरकर्ता C:\ProgramData या शेअर केलेल्या फोल्डरमध्ये एक घातक कॉन्फिगरेशन फाईल टाकू शकतो, जिथे अनेक AI-आधारित कोडिंग असिस्टंट्स आपोआप सेटिंग्ज वाचतात. जेव्हा एखादा ॲडमिनिस्ट्रेटर नंतर Claude Code, Cursor, Codex CLI किंवा Gemini CLI यांसारखी साधने चालवतो—तेव्हा ती घातक फाईल पूर्ण सिस्टम प्रिव्हिलेजसह (system privileges) कार्यान्वित केली जाते, ज्यामुळे कोणताही इशारा न देता अटॅकरला मशीनचे नियंत्रण मिळते.

ही समस्या का महत्त्वाची आहे

AI कोडिंग असिस्टंट्स डेव्हलपमेंट पाइपलाइनमध्ये सामान्य झाले आहेत, जे अनेकदा कंपायलर, पॅकेज मॅनेजर किंवा अंतर्गत रिपॉझिटरीजना ॲक्सेस करण्यासाठी उच्च अधिकारांसह (elevated rights) चालवले जातात. ॲडमिनिस्ट्रेटर म्हणून चालणारा कोड इंजेक्ट करण्याची क्षमता, वर्कस्टेशनचे संरक्षण करणाऱ्या सामान्य युजर-लेव्हल सँडबॉक्सला (sandbox) बायपास करते. व्यवहारात, कमी विशेषाधिकार असलेला (low-privilege) खाते एखादी फाईल ठेवू शकतो, ॲडमिनने असिस्टंट सुरू करण्याची वाट पाहू शकतो आणि त्यानंतर असिस्टंटद्वारे यादृच्छिक कमांड्स (arbitrary commands) कार्यान्वित करणे, सिस्टम फाईल्समध्ये बदल करणे किंवा क्रेडेंशियल्स चोरणे शक्य होते. याचा परिणाम शांतपणे मालवेअर बसवण्यापासून ते कॉर्पोरेट वर्कस्टेशन्सवर पूर्ण ताबा मिळण्यापर्यंत असू शकतो.

ही त्रुटी कशी काम करते

या चारही साधनांमध्ये एक साधी डिझाइन निवड आहे: ती मशीन-वाईड कॉन्फिगरेशन C:\ProgramData मध्ये साठवतात आणि स्टार्टअपच्या वेळी ती फाईल्स आपोआप लोड करतात. विंडोजमध्ये, हे डिरेक्टरी कोणत्याही मानक वापरकर्त्यासाठी (standard user) वाचण्यायोग्य आणि लिहिण्यायोग्य (writable) असते. ही साधने फाईल्स पार्स करण्यापूर्वी त्यांच्या मालकीची किंवा अखंडतेची (integrity) पडताळणी करत नाहीत.

साधन अपेक्षित कॉन्फिगरेशन फाईल
Claude Code managed-settings.json
Cursor hooks.json
Codex CLI config.toml
Gemini CLI system-defaults.json

अटॅकर साधन ज्या नावाच्या फाईलचा शोध घेते, त्याच नावाचा एक फाईल तयार करतो, तो C:\ProgramData अंतर्गत संबंधित फोल्डरमध्ये ठेवतो आणि वाट पाहतो. जेव्हा ॲडमिनिस्ट्रेटर असिस्टंट उघडतो, तेव्हा प्रोग्राम अटॅकरच्या नियंत्रणाखालील फाईल वाचतो आणि त्यातील मजकूर कार्यान्वित करतो. Codex CLI च्या बाबतीत, घातक कॉन्फिगरेशन अंगभूत सुरक्षा सँडबॉक्स देखील बंद करू शकते, ज्यामुळे अटॅक सरफेस अधिक वाढतो.

Claude Code बनवणारी कंपनी Anthropic ने आधीच त्यांच्या सेटिंग्ज सुरक्षित ठिकाणी हलवल्या आहेत, ज्यामुळे त्या उत्पादनासाठी ही त्रुटी दूर झाली आहे. संशोधन अहवालाच्या वेळी इतर विक्रेत्यांनी यावर कोणताही उपाय (fix) काढलेला नाही, ज्यामुळे त्यांचे वापरकर्ते धोक्यात आहेत.

कोणाचा फायदा, कोणाचे नुकसान

  • अटॅकर्सना (Attackers) थेट प्रिव्हिलेज-एस्केलेशनचा मार्ग मिळतो, ज्यासाठी कर्नल बग्स किंवा झिरो-डे कोडचा वापर करण्याची गरज नसते.
  • डेव्हलपर्स आणि संस्था जे दैनंदिन कामासाठी या असिस्टंट्सवर अवलंबून आहेत, त्यांना क्रेडेंशियल्सची चोरी, कोड इंजेक्शन किंवा रॅन्समवेअरच्या धोक्याचा सामना करावा लागू शकतो.
  • टूल विक्रेते (Tool vendors) जर ही त्रुटी त्वरित दुरुस्त केली नाही, तर त्यांच्या प्रतिष्ठेला धक्का लागण्याची आणि संभाव्य कायदेशीर जबाबदारीची (liability) शक्यता आहे.

डेटा चोरीचा खर्च मोठा असू शकतो: बाधित SSH कीज, क्लाउड टोकन्स आणि Git क्रेडेंशियल्समुळे संपूर्ण नेटवर्क धोक्यात येऊ शकते. अगदी एक बाधित वर्कस्टेशन देखील कॉर्पोरेट वातावरणात लॅटरल मूव्हमेंटसाठी (lateral movement) लॉन्चपॅड बनू शकते.

तुम्ही आजच घेऊ शकता असे प्रतिबंधात्मक उपाय

जोपर्यंत विक्रेते पॅचेस (patches) पाठवत नाहीत, तोपर्यंत ॲडमिनिस्ट्रेटर स्वतः फोल्डर्स अधिक सुरक्षित करू शकतात. खालील PowerShell कमांड्स, उच्च अधिकारांसह (elevated rights) चालवल्यास, अपेक्षित डिरेक्टरीज तयार करतील (जर त्या आधीच अस्तित्वात नसतील) आणि त्या लॉक करतील जेणेकरून केवळ सिस्टम आणि ॲडमिनिस्ट्रेटरनाच लिहिण्याचा अधिकार (write access) असेल:

# Create the directories
$paths = @(
    "C:\ProgramData\ClaudeCode",
    "C:\ProgramData\Cursor",
    "C:\ProgramData\openai\codex",
    "C:\ProgramData\gemini-cli"
)
foreach ($p in $paths) { New-Item -ItemType Directory -Path $p -Force }

# Remove inherited permissions and grant only the needed accounts
foreach ($p in $paths) {
    icacls $p /inheritance:r
    icacls $p /grant "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F" "Users:(OI)(CI)RX"
}

ACLs (access-control lists) लागू केल्यानंतर, फोल्डर्समध्ये कोणत्याही मानक वापरकर्त्याच्या मालकीच्या फाईल्स आहेत का ते तपासा. अशी फाईल सापडणे हे मशीन आधीच बाधित झाले आहे याचे प्रबळ लक्षण आहे; अशा परिस्थितीत, सर्व प्रायव्हेट कीज, क्लाउड ॲक्सेस टोकन्स आणि व्हर्जन-कंट्रोल क्रेडेंशियल्स त्वरित बदलून घ्या (rotate).

कशाकडे लक्ष द्यावे

  • विक्रेत्यांचे पॅचेस (Vendor patches) – बाधित विक्रेत्यांच्या रिलीज नोट्सवर लक्ष ठेवा. सेटिंग्ज सुरक्षित ठिकाणी हलवणे किंवा कॉन्फिगरेशन फाईल्ससाठी इंटिग्रिटी चेक (integrity check) करणे यामुळे ही समस्या सुटू शकते.
  • सुरक्षा साधनांचे अपडेट्स (Security tooling updates) – एंडपॉइंट डिटेक्शन प्लॅटफॉर्म्स C:\ProgramData मधील फाईल निर्मितीच्या या विशिष्ट पॅटर्नसाठी सिग्नेचर जोडू शकतात. हे अपडेट्स लागू केल्यास लवकर सूचना मिळू शकतात.
  • कम्युनिटी डिस्क्लोजर्स (Community disclosures) – सुरक्षा संशोधक प्रूफ-ऑफ-कॉन्सेप्ट एक्स्प्लॉइट्स (proof-of-concept exploits) किंवा डिटेक्शन स्क्रिप्ट्स प्रकाशित करू शकतात, ज्याचा वापर अंतर्गत मॉनिटरिंगमध्ये केला जाऊ शकतो.

प्रतिवाद

काही जण असा युक्तिवाद करू शकतात की हा धोका केवळ अशा मशीनपुरता मर्यादित आहे जिथे अनेक युजर अकाउंट्स आहेत, किंवा ही टूल्स क्वचितच ॲडमिनिस्ट्रेटर हक्क (administrator rights) वापरून चालवली जातात. जरी या घटकांमुळे अटॅक सरफेस (attack surface) कमी होत असला, तरी ते तो पूर्णपणे नष्ट करत नाहीत. अनेक कॉर्पोरेट लॅपटॉप्सचे व्यवस्थापन मध्यवर्ती पद्धतीने केले जाते आणि कंपायलर (compilers) किंवा SDKs इंस्टॉल करण्यासाठी डेव्हलपर्सना अनेकदा ॲडमिन हक्क दिले जातात. शिवाय, मालवेअर (malware) ॲडमिन-लेव्हल ट्रिगरशिवाय देखील सिस्टममध्ये टिकून राहण्यासाठी याच फोल्डरचा वापर करू शकते, जिथे ते AI असिस्टंटचा केवळ एक सोयीस्कर एक्झिक्यूशन वेक्टर (execution vector) म्हणून वापर करते.

निष्कर्ष

CVE-2026-35603 हे दर्शवते की, एक वरवरचा निष्पाप वाटणारा डिझाइन निर्णय—जसे की 'वर्ल्ड-राईटेबल' (world-writable) फोल्डरमधून कॉन्फिगरेशन वाचणे—जेव्हा AI टूल्सचा समावेश असतो, तेव्हा तो किती शक्तिशाली एस्केलेशन पाथ (escalation path) बनू शकतो. जोपर्यंत विक्रेते या त्रुटीचे निराकरण करत नाहीत, तोपर्यंत एकमेव विश्वसनीय बचाव म्हणजे या असिस्टंट्सद्वारे वापरले जाणारे C:\ProgramData सबफोल्डर्स लॉक करणे आणि तिथे आढळणाऱ्या कोणत्याही अनपेक्षित फाईल्सना सिस्टममध्ये घुसखोरीचे (compromise) लक्षण मानणे. या समस्येकडे दुर्लक्ष केल्यास, कमी विशेषाधिकार (low-privilege) असलेल्या अकाउंट्सना विंडोज वर्कस्टेशनवर पूर्ण नियंत्रण मिळवण्याचा थेट मार्ग मोकळा होतो.