Cursor ज़ीरो-डे: क्यों पूर्ण खुलासा ही बचा हुआ सुरक्षा उपाय बन गया

 (mindgard.ai)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Windows के लिए Cursor, प्रोजेक्ट खोलते समय workspace root में मौजूद git.exe को अपने-आप चलाता है, इसलिए केवल ऐसे repository को खोलने भर से जिसमें malicious binary हो, बिना user interaction के arbitrary code execute हो सकता है
  • Git path खोजने के दायरे में repository के अंदरूनी हिस्से भी शामिल हैं; यह बिना warning या approval के file execute करता है, और project खुला रहने के दौरान उसे periodically फिर से चलाता भी है
  • Mindgard ने 15 दिसंबर 2025 को report किया और HackerOne के जरिए reproduce व forward करने की प्रक्रिया भी पूरी की, लेकिन 6 महीने से अधिक और 197 से ज्यादा नए versions के बाद भी latest test version में समस्या बनी रही
  • Managed Windows environments को AppLocker या Windows App Control की path-based deny rules लागू करनी चाहिए, और आम users को patch आने तक untrusted repositories को VM या Windows Sandbox में खोलना चाहिए
  • Mindgard ने माना कि coordinated disclosure process से users का risk कम नहीं हो पा रहा है, इसलिए उसने पूरी details सार्वजनिक कर दीं; AI development tools चुनते समय vendor की security response और communication capability को भी trust का आधार बनाना चाहिए

केवल repository खोलने भर से चलने वाला git.exe

  • Cursor project load करते समय कई locations पर Git binary खोजता है, और search target में current workspace भी शामिल होता है
  • अगर attacker repository root में malicious git.exe रख दे, तो Cursor उसे warning, approval dialog या किसी extra click के बिना automatically execute कर देता है
  • Developer द्वारा उस project को खोलते ही attack शुरू हो जाता है; prompt injection, model manipulation, jailbreak, memory corruption या complex exploit chain की जरूरत नहीं होती
  • Execute हुआ code मौजूदा Cursor user के permission scope में काम करता है

Reproduction process और repeated execution का record

  • Mindgard ने safe proof of concept के लिए Windows Calculator का नाम बदलकर git.exe किया और उसे repository root में रखा
  • Cursor में repository खोलते ही Calculator चल गया, और project खुले रहने पर कई अतिरिक्त windows दिखाई दीं
    • ऐसा नहीं था कि researcher ने manually कई windows खोली हों
    • यह one-time startup behavior नहीं था, बल्कि normal use के दौरान workspace की executable file को periodically re-execute करने का परिणाम था
  • वास्तविक attack में Calculator की जगह attacker-controlled code रखा जा सकता है
  • Sysinternals Process Monitor records में दिखा कि Cursor.exe repository के अंदर मौजूद git.exe चलाते हुए यह command pass कर रहा था
git rev-parse --show-toplevel
  • आखिरी verification 30 अप्रैल 2026 को Windows के लिए Cursor 3.2.16 पर किया गया

बड़े user base में बची रही vulnerability

  • Cursor इस scale पर इस्तेमाल होने वाला AI-assisted development environment है
    • 70 लाख से अधिक active users
    • 10 लाख से अधिक daily users
    • 10 लाख से अधिक paid users
    • 50,000 से अधिक companies इस्तेमाल कर रही हैं
  • Reported market value 60 अरब डॉलर है
  • Mindgard ने 15 दिसंबर 2025 को vulnerability पाई और उसी दिन report की
  • लेख की शुरुआत के आधार पर, 6 महीने से अधिक और 197 से ज्यादा नए versions के बाद भी latest test version में vulnerability मौजूद थी
  • Response timeline बताने वाले body में दर्ज है कि features और announcements जारी रहने के दौरान 70 से अधिक versions release हुए, लेकिन समस्या बनी रही
  • एक simple और आसानी से reproduce होने वाली arbitrary code execution vulnerability कई महीनों तक fix नहीं हुई, जिससे Cursor deploy करने वाले individuals और organizations दोनों प्रभावित हुए

Patch से पहले लागू किए जा सकने वाले temporary mitigations

  • Managed Windows systems में AppLocker या Windows App Control policies से development workspace directories में उस executable file name को block किया जा सकता है
  • हर binary का hash अलग हो सकता है, इसलिए hash-based blocklists के बजाय repository/workspace root तक scope सीमित रखने वाली path-based deny rules ज्यादा उपयुक्त हैं
%USERPROFILE%\source\repos\*\filename.exe
  • Windows में ऐसा सामान्य built-in rule नहीं है जो केवल किसी specific parent process द्वारा चलाए जाने पर arbitrary child executable को block करे
    • Parent process-aware controls के लिए EDR या custom endpoint security products की जरूरत होती है
  • आम users को IDE patch होने तक untrusted repositories को केवल isolated VM, Windows Sandbox या disposable environment में खोलना चाहिए
  • Binary बदलते ही hash बदल सकता है, इसलिए इस vulnerability के लिए file hash blocklist पर भरोसा नहीं करना चाहिए

Report के बाद रुक गई coordinated process

  • शुरुआती report Cursor के security.txt में दिए गए security reporting email पर भेजी गई, लेकिन receipt confirmation नहीं आया
  • Mindgard ने follow-up emails और public contact request के जरिए सही security contact खोजने की कोशिश की
  • Cursor CISO ने जवाब दिया कि internal automation failure के कारण तय HackerOne process शुरू नहीं हुआ, और Mindgard को manually private bug bounty program में invite किया
  • HackerOne पर दोबारा submit की गई report शुरू में Informative और out of scope कहकर बंद कर दी गई
    • Mindgard ने इस decision को challenge किया
    • HackerOne ने issue reproduce करने के बाद report फिर से खोली और confirm किया कि details Cursor को भेज दी गई हैं
  • इसके बाद update requests, HackerOne के जरिए escalation, और Cursor CISO व executives से direct contact के बावजूद कोई meaningful response नहीं मिला
  • Mindgard को कोई evidence नहीं मिला कि fix शुरू हुआ है, engineering team जांच कर रही है, या affected users को risk communicate किया गया है

Report से full disclosure तक timeline

  • 15 दिसंबर 2025

    • Mindgard ने vulnerability खोजी
    • security-reports@cursor.com पर report की

  • 18 दिसंबर 2025

    • Receipt confirmation मांगते हुए follow-up contact भेजा

  • 13 जनवरी 2026

    • Cursor contact खोजने के लिए LinkedIn post डाली
    • Comment में एक user ने Cursor CISO को point out किया

  • 15 जनवरी 2026

    • Cursor CISO ने HackerOne private bounty invite automation failure की जानकारी दी और manually invite किया
    • Mindgard ने HackerOne के जरिए vulnerability submit की

  • 16 जनवरी 2026

    • Report को Informative और out of scope कहकर बंद किया गया
    • Mindgard ने decision को challenge किया
    • Reproduction सफल होने के बाद report फिर से खोली गई

  • 20 जनवरी 2026

    • HackerOne ने confirm किया कि report Cursor को forward कर दी गई है

  • 16 फरवरी 2026, 3 मार्च 2026

    • Mindgard ने updates मांगे, लेकिन response नहीं मिला

  • 17 मार्च 2026

    • Cursor CISO से direct update मांगा

  • 18 मार्च 2026

    • HackerOne ने बताया कि उसने Cursor से contact किया है

  • 1 अप्रैल 2026

    • Mindgard ने फिर से update मांगा, लेकिन response नहीं मिला
    • HackerOne ने भी confirm किया कि Cursor की ओर से कोई update नहीं है

  • 1 जून 2026

    • Mindgard ने HackerOne को disclosure के इरादे की जानकारी दी

  • 3 जून 2026

    • HackerOne ने disclosure guidance दी

  • 14 जुलाई 2026

    • Vulnerability details वाला post public किया

Coordinated disclosure user protection तक क्यों नहीं पहुँचा

  • सामान्य coordinated disclosure में reporting, discussion, severity debate, engineering investigation, fix development, user protection और disclosure का क्रम होता है
  • यह process तब काम करती है जब सभी participants risk reduction का लक्ष्य साझा करते हैं
  • इस मामले में 7 महीनों तक vendor की meaningful participation नहीं रही, इसलिए process risk reduction stage तक नहीं बढ़ पाई
  • तेज़ी से बदलते बड़े platforms में fixes में समय लग सकता है, लेकिन महीनों तक communication, updates या visible progress न होने पर इंतजार जारी रखना मुश्किल हो जाता है
  • Researchers के पास केवल दो options बचे थे
    • चुप रहें और users को इस गलत assumption के तहत काम जारी रखने दें कि वे सुरक्षित हैं
    • Disclosure करें ताकि organizations risk समझकर response तय कर सकें
  • Mindgard ने बाकी सभी रास्ते विफल होने पर इस्तेमाल की जाने वाली full disclosure को चुना

Bug bounty और AI security response systems ने जो सवाल छोड़े

  • Resolution में देरी के कारणों को लेकर ये संभावनाएं पूछी गईं
    • क्या modern bug bounty programs overload में हैं
    • क्या Mythos जैसे ज्यादा सक्षम models के कारण report volume संभालना मुश्किल हो गया है
    • क्या Cursor ने SpaceX acquisition पर focus करते हुए user safety की priority घटा दी
    • क्या अरबों डॉलर दांव पर होने की स्थिति में user safety सच में concern है
  • AI products के फैलाव से security findings की संख्या बहुत बढ़ रही है, और उनमें से काफी findings existing vulnerability classifications में साफ-साफ fit नहीं होतीं
  • करीब 20 साल से जिन classification और intake processes पर निर्भरता रही है, वे AI environment में basic assumptions हिलने के कारण तेजी से fail हो रही हैं
  • अगर disclosure pipeline overload में है, तो industry को इसे transparently बताना चाहिए ताकि researchers, customers और users स्थिति का आकलन कर सकें
  • तेजी से बढ़ती companies को security failures ठीक करने के साथ-साथ users को purchase experiment targets नहीं, बल्कि valuable customers की तरह treat करना चाहिए

AI development tools पर भरोसा करने की शर्तें

  • AI companies code, repositories, terminal, secrets और workflows तक unprecedentedly व्यापक access मांगती हैं, और suggestion व execution के बीच की boundary भी धीरे-धीरे धुंधली हो रही है
  • Users production software को source code, credentials, proprietary intellectual property और increasingly autonomous features सौंप रहे हैं
  • केवल productivity बढ़ाने के कारण systems पर भरोसा नहीं करना चाहिए; trust security report responses, affected users के साथ communication और fix prioritization के जरिए earn किया जाना चाहिए
  • Trust के लिए accountability चाहिए और accountability के लिए communication चाहिए, लेकिन जब users, researchers और public platforms को महीनों तक basic status update भी न मिले, तो उस accountability को verify करना मुश्किल हो जाता है
  • Mindgard ने full details इसलिए public कीं ताकि organizations exposure का assessment कर सकें, compensating controls लागू कर सकें और security posture तय कर सकें
  • जब information छिपाते रहना users की जगह सिर्फ silence को protect करने लगे, तो असुविधाजनक होने पर भी user safety को priority देनी चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • सुरक्षा रिपोर्ट प्राप्त करने वालों के दृष्टिकोण से LLM द्वारा बनाई गई कम-गुणवत्ता वाली रिपोर्टें इतनी अधिक आ रही हैं कि उन्हें संभालना मुश्किल हो गया है, और उनमें आम तौर पर प्रोडक्ट डिज़ाइन या सुरक्षा दायरे की समझ नहीं होती। कभी-कभी बहुत अच्छी रिपोर्ट भी आती हैं, इसलिए हर एक को खुद जांचना पड़ता है, लेकिन LLM द्वारा बनाए गए लंबे-चौड़े “तर्क” और भेजना समाधान नहीं है, और यह लेख भी अधिकांशतः LLM से लिखा हुआ लगता है
    इस मामले में भी, यदि यह ऐसी स्थिति है जहाँ सॉफ़्टवेयर मनचाहा code या binary चला सकता है और ऐसे environment में malicious binary रखी गई हो, तो जब तक Cursor यह नहीं कहता कि वह user environment की सुरक्षा की भी जिम्मेदारी लेगा, यह ज़्यादा workspace को isolate और protect करने वाली तरफ की जिम्मेदारी लगती है
    LLM से CVE रिपोर्ट बनाते समय इसका उपयोग निर्णायक रूप से reproduce करने की प्रक्रिया में करना चाहिए, और मुख्य लेखन खुद संक्षेप में करना चाहिए, साथ ही LLM-शैली के अनावश्यक विशेषणों और अतिशयोक्ति को हटा देना चाहिए

    • सिर्फ इसलिए कि नया clone किया गया repository Cursor में खोला गया है, उसके अंदर की binary अपने-आप execute नहीं होनी चाहिए
    • PATH variable का अस्तित्व ही ऐसे मुद्दों को नियंत्रित करने के लिए है। अगर मेरी समझ सही है, तो Cursor user approval के बिना repository को तुरंत PATH में जोड़ देता है
    • इसका कोई आसान समाधान नहीं है, और यदि सुरक्षा को गंभीरता से लेना है, तो बदले हुए environment के अनुसार review staff बढ़ाना होगा। LLM-जांच की एक और परत जोड़ देने से समस्या हल नहीं होगी

  • समस्या की जड़ यह है कि Cursor repository clone और code execution को दो अलग security boundaries के रूप में नहीं देखता। Cursor डिफ़ॉल्ट रूप से Workspace Trust को निष्क्रिय करता है[0], और ऐसा repository खोलते ही जिसमें .vscode/tasks.json में "runOn": "folderOpen" हो, arbitrary code पहले से ही execute हो जाता है[1]
    [0] https://cursor.com/docs/agent/security#workspace-trust
    [1] https://www.oasis.security/blog/cursor-security-flaw

  • Mindgard ने vulnerability को पहली बार 15 दिसंबर 2025 को खोजा और उसी दिन तथा उसके बाद कई बार रिपोर्ट किया, लेकिन 6 महीने और 197 से अधिक नए versions के बाद भी यह नवीनतम Cursor में मौजूद बताया गया
    शुरू में इसे informational/out-of-scope रिपोर्ट कहकर बंद कर दिया गया, और आपत्ति के बाद HackerOne ने इसे फिर खोला, reproduce किया और Cursor को भेजा, लेकिन उसके बाद update requests, अतिरिक्त पूछताछ, HackerOne के माध्यम से escalation, और Cursor management को भेजे गए संदेश—इन सबका भी कोई जवाब नहीं मिला; Cursor ऐसा व्यवहार क्यों कर रहा है, यह समझना कठिन है

    • CVE handling process ही टूट चुकी है। एजेंट-आधारित AI की प्रगति के साथ HackerOne और कंपनी vulnerability disclosure programs में कम-गुणवत्ता वाली रिपोर्टों और वास्तव में उत्कृष्ट रिपोर्टों—दोनों की बाढ़ आ गई है, और चूँकि वही AI दोनों लिख रही है, सिर्फ सतह देखकर उनमें अंतर करना लगभग असंभव है
      परिणामस्वरूप कंपनियाँ पहले की तरह जवाब नहीं दे रहीं, और जून के cyber security conference में भी यह भावना प्रबल थी कि responsible disclosure मर चुकी है या मर रही है, इसलिए सार्वजनिक रूप से उजागर करना बेहतर है। Microsoft और Nightmare Eclipse मामले का अक्सर उल्लेख हुआ
    • जानबूझकर डाले गए backdoor की संभावना भी ध्यान में आती है। यदि NSA या FBI किसी target repository में git.exe रख दे और target उसे clone करे, तो payload execute हो सकता है
      Cursor चूँकि VS Code-आधारित है, इसलिए यह जानने की जिज्ञासा है कि क्या VS Code में भी यही बात होती है

  • यह एक गंभीर vulnerability है, इस पर पूरी तरह सहमत होना कठिन है। वास्तविक exploitation के लिए attacker को पहले user के code folder में git.exe नाम का malicious executable रखना होगा, और यह कुछ-कुछ ऐसा है जैसे .bashrc बदलकर ls को /tmp/mega-big-virus.sh चलाने वाला alias बना दिया जाए और उसे vulnerability कहा जाए
    यह attack path तो है, लेकिन यदि ऐसा file पहले से filesystem में पहुँच चुका है, तो इसे पूर्ववर्ती compromise की स्थिति माना जा सकता है

    • केवल GitHub repository clone करके उसे default editor Cursor में खोलने से भी संक्रमण हो सकता है। यह वैसा ही है जैसे CD डालते ही autorun.exe चल जाए और Windows संक्रमित हो जाए
      यह कहा जा सकता है कि user को repository की सभी files और git.exe जैसे संदिग्ध binaries को isolate किए गए environment में स्वयं inspect करना चाहिए, लेकिन व्यवहार में इसे user नहीं बल्कि auto-execution को रोकने वाली security policy नियंत्रित करती है, और Cursor में भी इसे इसी तरह disable होना चाहिए
    • .bashrc के विपरीत, code folders अक्सर अविश्वसनीय स्रोतों से लाए जाते हैं। सिर्फ GitHub project की समीक्षा के लिए उसे खोलने भर से arbitrary code execution की अनुमति नहीं दी जानी चाहिए
      हालांकि प्रमुख IDEs में यह boundary टूटे हुए काफी समय हो चुका है, और VS Code की SSH तथा devcontainer remote features भी design के अनुसार remote code execution की अनुमति देती हैं
    • पेज के पहले पैराग्राफ़ से ही Cursor स्पष्ट रूप से दो वाक्यों में कहता है कि project खोलने के बाद वह current workspace सहित कई स्थानों पर Git binary खोजता है, और यदि repository root में malicious git.exe रखा हो, तो वह user input या confirmation के बिना उसे execute कर देता है। यह कोई ऐसी पोस्ट नहीं है जो मुख्य behavior को छिपाती हो
    • सिर्फ repository clone करके IDE में खोलना ही repository owner को remote code execution अधिकार देने जैसा है, और इसे folder खोलने की क्रिया में निहित कोई स्वाभाविक अनुबंध मानना कठिन है
    • 30 साल पहले भी MP3 या photo folders में संक्रमित alternate DLL रखकर Winamp या Windows photo viewer से उन्हें load करवाने वाले DLL search order attacks होते थे, और यह मामला उनसे बहुत मिलता-जुलता है

  • Cursor का बिना confirmation arbitrary executable चलाना अजीब है, और शोधकर्ताओं को महीनों तक कोई ठीक-ठाक जवाब न मिलना भी चिंताजनक है
    हालांकि calculator चलाने वाला उदाहरण कुछ हद तक भ्रामक हो सकता है। malicious executable को पहले से system पर डाउनलोड किया हुआ होना चाहिए, और मेरी समझ के अनुसार Cursor जब उसे चलाने की कोशिश करेगा, तो ACL काम करेगा और पहली बार unsigned नया app चलाने की अनुमति पूछेगा। वास्तविक exploitation के लिए संभव है कि ACL पूरी तरह disabled होनी चाहिए

    • यदि prompt में “git.exe को execute करना है?” जैसा संदेश आए, तो संभावना है कि user यह सोचे कि Cursor को Git चाहिए और permissions में कुछ गड़बड़ है, इसलिए वह उसे वैसे ही approve कर दे
    • यदि कोई PS1 का उपयोग करके current Git branch दिखाता है और current directory को PATH में शामिल करता है, तो वही बात वहाँ भी हो सकती है। तब क्या Bash के लिए भी high-risk CVE दर्ज करनी चाहिए, यह सवाल उठता है

  • यह सिर्फ Cursor का बग नहीं लगता, बल्कि Windows-विशिष्ट search order से जुड़ा दिखता है, जहाँ Windows, PATH देखने से पहले current working directory में executable ढूँढता है। Windows के कई प्रोग्राम इसी तरह के हमलों के प्रति exposed हो सकते हैं

    • जो software security को गंभीरता से लेते हैं, वे इस समस्या को पहले ही ठीक कर चुके हैं
      https://go.dev/blog/path-security में बताया गया है कि Command और LookPath OS conventions के अनुसार current PATH में listed directories में program ढूँढते हैं, लेकिन आधुनिक संदर्भ में current directory को शामिल करना अक्सर अप्रत्याशित होता है और security issues तक ले जाता है
      https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
    • अगर known system path में असल Git executable को खोजा जाए या user से path configure कराया जाए, तो इसे आसानी से mitigate किया जा सकता है; मेरी जानकारी में VS Code भी यही तरीका अपनाता है
    • Windows के लिए software बनाते समय इससे बचाव करना एक पुराना और अच्छी तरह जाना-पहचाना security pitfall है
    • तो आखिर इसका मतलब यही लगता है कि Cursor के Windows version में bug भी है और vulnerability भी

  • कंपनियों का security को प्राथमिकता न देना बहुत आम है, और दुखद होते हुए भी कुछ हद तक समझ में आता है। यह भी समझ में आता है कि security startup इंतज़ार करते-करते थक जाए और लगाए गए खर्च का कुछ हिस्सा publicity के असर से वापस पाने के लिए disclosure करे, और कुछ मौकों पर public vulnerability disclosure ज़रूरी भी होता है
    लेकिन अगर उनका मकसद सच में fix में मदद करना था, तो शायद HackerOne पर follow-up करने और CISO को LinkedIn पर एक message भेजने से ज़्यादा किया जा सकता था। अब यह सब कुछ ऐसा लगता है मानो किसी को सच में परवाह ही नहीं है, जो कड़वा लगता है

    • असल में fix में ईमानदारी से मदद करना किसे कहा जाएगा, और यहाँ कहा गया sunk cost ठीक-ठीक क्या है, यह स्पष्ट नहीं है। कुल मिलाकर बात ज़रूरत से ज़्यादा अस्पष्ट लगती है

  • जिज्ञासा इस बात की है कि Cursor executable को अपने-आप क्यों चलाता है, और किस decision flow में यह behavior आया। Vim में भी %{expr} जैसी explicit features के कारण file load करते समय unexpected code execution की समस्या रही है, लेकिन Cursor आखिर git.exe को क्यों खोजता है और यह feature किसके लिए उपयोगी है, यह समझना मुश्किल है
    Cursor कभी इस्तेमाल न करने वाले व्यक्ति के नज़रिए से भी यह सवाल उठता है कि ऐसा आसानी से fix होने वाला दोहरावदार CVE आखिर मौजूद क्यों है

    • एक आम flow यह है कि user Cursor से किसी existing repository का summary बनाकर README लिखने को कहता है, फिर Cursor repository और code पढ़कर development branch या previous tag जैसे metadata देने के लिए Git commands चलाता है
      समस्या यह है कि जब उसे remote repository evaluate करने को कहा जाता है, तो repository clone करने के बाद अगर working directory में git ... चलाया जाए, तो Windows उसी directory में मौजूद git file को executable target मान सकता है। Untrusted repository या compromised branch पर switch करते ही तुरंत code execution हो सकता है
      सामान्य समाधान यह है कि system में installed Git का full path इस्तेमाल किया जाए; इंसान के लिए यह टाइप करना भले झंझट हो, Cursor के लिए यह मामूली काम है
    • ऐसा लगता है कि built-in agent का इरादा user के वास्तविक Git को ढूँढने का है ताकि वह कई branches और worktree में context पढ़ सके। इससे ज़्यादा सुरक्षित तरीके मौजूद हैं, लेकिन ऐसे छोटे shortcuts AI-assisted workflows में आसानी से गलत साबित होते हैं, और AI-आधारित bug triage में भी ऐसे बिंदुओं पर alerts छूट जाना आसान है

  • क्योंकि development agents को अक्सर Git repositories pull और push करने की permission दी जाती है, यह एक बड़ा supply chain attack vector बन जाता है। अगर चल रहा Cursor agent latest files pull करे और attacker ने project में कोई executable डाल रखा हो, तो अचानक लाखों users के systems पर default user privileges के साथ arbitrary EXE चल सकता है

  • यह report कुछ हद तक AI द्वारा लिखी हुई लगती है। Exploit के लिए malicious payload का clone या download जैसी किसी प्रक्रिया से पहले से PC पर पहुँचना ज़रूरी होगा, इसलिए severity समझ में आती है, लेकिन स्वाभाविक उम्मीद यही होती है कि कोई उस स्थिति में पहुँचे ही नहीं

    • आधुनिक coding agents, जब उनसे किसी poorly documented API के बारे में पूछा जाता है, तो repository clone करके code पढ़ते भी हैं, इसलिए यह vulnerability वास्तव में exploitable है
    • Malicious payload remote repository में हो सकता है। Repository को git clone करने के बाद अगर उसे Cursor में सिर्फ खोल दिया जाए, तो compromise पूरा हो जाता है
    • Open source developers को git.exe शामिल करने वाला pull request भी मिल सकता है
    • आम तौर पर source देखने के लिए repository download करना, malicious payload activate करने के बराबर नहीं माना जाता, और चिंता की बात यही है। भले AI शैली खटकती हो, आलोचना report लिखने के तरीके की नहीं बल्कि vulnerability के substance की होनी चाहिए
    • यह मान लेना मुश्किल है कि payload पहले से PC पर होना ही चाहिए। अगर prompt injection के जरिए download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;) जैसा command करवाया जा सके, तो agent git.exe download करके उसे execute भी कर सकता है