Cursor चे कोड-एडिटिंग टूल अजूनही प्रोजेक्ट फोल्डरमध्ये ठेवलेली एक घातक git.exe फाईल रन करते, ही एक गंभीर झिरो-डे (zero-day) त्रुटी आहे जी गेल्या सात महिन्यांपासून न सुटलेली आहे. ही त्रुटी कोणत्याही एक्झिक्युटेबलला Git असल्याचे भासवून, वापरकर्त्याच्या परवानग्यांसह (privileges) आपोआप रन होऊ देते, ज्यामुळे डेव्हलपर्सना कोणत्याही क्लिक किंवा चेतावणीशिवाय रिमोट कोड एक्झिक्यूशनचा (remote code execution) धोका निर्माण होतो.
ही त्रुटी सुरक्षा संशोधक Mindgard यांनी 15 डिसेंबर 2025 रोजी शोधली, त्याच दिवशी त्याची तक्रार करण्यात आली, आणि 197 हून अधिक अपडेट्स आणि $60 बिलियन कंपनी व्हॅल्युएशन असूनही जुलै 2026 च्या रिलीजमध्ये ती अजूनही कायम आहे.
ही त्रुटी कशी काम करते
Cursor रिपॉझिटरी रूटसह अनेक ठिकाणी Git बायनरीज शोधण्यासाठी प्रोजेक्टच्या डिरेक्टरीचे स्कॅनिंग करते. जेव्हा त्याला git.exe नावाचा फाईल सापडतो, तेव्हा ते व्हर्जन-कंट्रोल वैशिष्ट्ये प्रदान करण्यासाठी तो प्रोग्राम सुरू करते. ही प्रक्रिया कोणत्याही UI प्रॉम्प्टशिवाय शांतपणे (silently) घडते आणि सध्याच्या वापरकर्त्याच्या परवानग्या (permissions) घेते.
जो अटॅकर रिपॉझिटरीमध्ये फाईल जोडू शकतो, तो अपेक्षित Git बायनरीऐवजी कोणतेही एक्झिक्युटेबल फाईल ठेवू शकतो. Mindgard ने Windows Calculator चे नाव बदलून git.exe केले, ते एका रिपॉझिटरीमध्ये टाकले आणि Cursor मध्ये तो फोल्डर उघडला, याद्वारे या परिणामाचे प्रदर्शन केले. जोपर्यंत प्रोजेक्ट उघडा होता, तोपर्यंत वारंवार Calculator विंडोज पॉप-अप होत होत्या—हे वास्तविक मालवेअर (malware) देखील याच पद्धतीने कार्यान्वित होऊ शकते याचे उदाहरण आहे.
माहिती उघडकीस येण्याचा कालक्रम
- 15 डिसेंबर 2025 – Mindgard ने Cursor च्या सुरक्षा पत्त्यावर पूर्ण अहवाल ईमेल केला.
- 15 जानेवारी 2026 – Cursor च्या मुख्य माहिती सुरक्षा अधिकारी (CISO) ने एक महिन्यानंतर उत्तर दिले.
- 16 जानेवारी 2026 – Cursor द्वारे वापरला जाणारा बग-बाउंटी प्लॅटफॉर्म HackerOne, या अहवालाला 'आउट ऑफ स्कोप' (out of scope) म्हणून वर्गीकृत करतो.
- 16 जानेवारी 2026 – Mindgard ने प्रूफ-ऑफ-कॉन्सेप्ट (proof-of-concept) सादर केला, ज्यामुळे HackerOne ला तिकीट पुन्हा उघडण्यास भाग पाडले.
- 20 जानेवारी 2026 – Cursor ला अधिकृतपणे अहवाल प्राप्त झाला असल्याची HackerOne ने पुष्टी केली.
20 जानेवारीनंतर, Mindgard कडून पाठवलेल्या फॉलो-अप मेसेजना कोणतेही उत्तर मिळाले नाही. Cursor नवीन फीचर्स लाँच करत राहिले आणि अतिरिक्त निधी उभारत राहिले, परंतु ही त्रुटी कोडबेसमध्ये तशीच राहिली.
विलंब चिंताजनक का आहे
ही समस्या एक क्लासिक सप्लाय-चेन रिस्क (supply-chain risk) आहे: कोणताही योगदानकर्ता (contributor) जो शेअर केलेल्या रिपॉझिटरीमध्ये फाईल पुश करू शकतो, तो प्रत्येक डेव्हलपरच्या मशीनवर चालणारा घातक कोड इंजेक्ट करू शकतो.
तुम्ही आता घेऊ शकता असे प्रतिबंधात्मक उपाय
एंटरप्राइझ विंडोज (Enterprise Windows) वातावरण
- AppLocker किंवा Windows App Control पॉलिसीज तैनात करा ज्या वर्कस्पेस डिरेक्टरीमध्ये
git.exeनावाचे कोणतेही एक्झिक्युटेबल सुरू होण्यापासून रोखतील. - हॅश-आधारित अलाऊलिस्ट्स (hash-based allowlists) वर अवलंबून राहू नका; अटॅकर्स फाईलचे नाव न बदलता तिचा हॅश सहज बदलू शकतात.
वैयक्तिक डेव्हलपर्स
- अविश्वसनीय स्रोतांकडून आलेली रिपॉझिटरी फक्त व्हर्च्युअल मशीन (virtual machine) किंवा Windows Sandbox मध्ये उघडा.
- फाईल-हॅश ब्लॉकलिस्ट्सवर (file-hash blocklists) अवलंबून राहू नका; ते सुरक्षेचा खोटा आभास देतात.
सामान्य सर्वोत्तम पद्धती
- प्रत्येक नवीन रिपॉझिटरीकडे संभाव्य सप्लाय-चेन वेक्टर (supply-chain vector) म्हणून पहा. सर्व बायनरीज कार्यान्वित करण्यापूर्वी त्यांच्या उगमस्थानाची (provenance) पडताळणी करा.
हा प्रसंग एक व्यापक धडा देतो: AI-आधारित डेव्हलपमेंट टूल्सना सिस्टमचा सखोल प्रवेश (deep system access) आवश्यक असतो आणि तो प्रवेश इतर कोणत्याही विशेषाधिकार प्राप्त सॉफ्टवेअरप्रमाणेच कडकतेने सुरक्षित ठेवला पाहिजे. जेव्हा अब्जावधी डॉलर्सच्या कंपनीमध्ये उच्च-परिणामकारक त्रुटी (high-impact vulnerability) महिनोनमहिने तशीच राहते, तेव्हा डेव्हलपर्सना त्या प्लॅटफॉर्मवरील त्यांच्या विश्वासाचा पुनर्विचार करण्यासाठी एक स्पष्ट संकेत मिळतो.
