باز کردن یک مخزن کدنویسی در Cursor روی ویندوز، تنها با قرار دادن یک فایل بهظاهر بیخطر به نام git.exe در پوشه اصلی پروژه، منجر به اجرای بیوقفه آن میشود. هیچ کلیک اضافی، هیچ دیالوگ تأییدی و هیچ هشدار امنیتی جلوی این فرآیند را نمیگیرد. هر عملی که آن فایل باینری انجام دهد، دقیقاً با دسترسی کامل کاربر جاری، بههمراه سورسکدها، کلیدهای SSH و توکنهای دسترسی ابری اجرا میگردد. تا زمانی که پروژه در محیط IDE باز بماند، این اجرای خودکار تکرار میشود.
مکانیسم حملات از طریق اولویتبندی مسیرها
این آسیبپذیری در یک جمله خلاصه میشود: Cursor هنگام بارگذاری یک پروژه، مکانهای مختلفی را برای یافتن باینری Git بررسی میکند و یکی از این مکانها خود دایرکتوری فضای کاری (Workspace) است. خروجیهای مانیتورینگ فرآیندها نشان میدهد که پروسه Cursor.exe باینری موجود در ریشه مخزن را با آرگومان git rev-parse --show-toplevel فراخوانی میکند. این دقیقاً همان رفتار تست اولیه مسیر است که در مستندات VS Code مایکروسافت نیز برای بررسی ریشه مخزن استفاده میشود. فرقی نمیکند که Cursor خود این مسیرها را اسکن میکند یا سطر فرمان git را مستقیماً به ویندوز میدهد و ترتیب جستجوی سیستمعامل را فعال میکند؛ نتیجه نهایی یکسان است.
تیم امنیتی Mindgard این سناریو را با تغییر نام ماشینحساب ویندوز به git.exe و کامیت آن در ریشه مخزن آزمایش کرد. نتیجه، باز شدن همزمان و انباشته پنجرههای ماشینحساب در پسزمینه بود، صرفاً با کلون کردن و باز کردن پروژه. این نشان میدهد که مهاجم نیازی به تسلط بر سیستم شما یا تزریق پرامپت ندارد؛ فقط کافی است فایل مخرب را در مخزن عمومی قرار دهد.
حلقه خاموش پاسخگویی سازنده
Mindgard این مورد را در ۱۵ دسامبر ۲۰۲۵ به سازنده IDE گزارش داد و پس از یک سکوت هفتماهه، جزئیات فنی آن را در تاریخ ۳۰ ژوئیه ۲۰۲۶ منتشر کرد. تا این تاریخ، هیچ وصله امنیتی صادر نشده و حتی هیچ CVE یا مشاوره رسمی از سوی تیم Cursor دیده نمیشود. آخرین تأییدیه عملیاتی Mindgard مربوط به نسخه ۳.۲.۱۶ است، در حالی که نسخه فعلی بازار ۳.۱۱ محسوب میشود. بررسی تمام ۳۳ گزارش امنیتی منتشر شده در صفحه رسمی نشان داد که این نقص همچنان در لیست رفعشدگان قرار ندارد.
تجربه تیم Mindgard چرخه باگباونتی نیز عادی نبوده است. اعلام سازنده به این نکته اشاره دارد که یک خطای اتوماتیک، دعوت اولیه از این تیم برای برنامه خصوصی HackerOne را رد کرده است. گزارش مجدد پس از یک روز بهدرستی بهعنوان «خارج از محدوده» بسته شد، تا زمانی که با پیگیری تیم تحقیق و بازتولید مشکل در پلتفرم، وضعیت اصلاح شد. با این حال، درخواستهای بهروزرسانی در ماههای بعدی تا امروز بیپاسخ ماندهاند.
راهکارهای عملی برای توسعهدهندگان
در غیاب پچ رسمی، مدیریت ریسک باید بهصورت دستی انجام شود. برای سازمانهایی که از ویندوز مدیریتشده استفاده میکنند، اعمال قوانین سختگیرانه در Windows App Control یا AppLocker ضروری است. مسدودسازی اجزای اجرایی با الگوی مسیر %USERPROFILE%\source\repos\*\*.exe جلوی فراخوانی فایلهای مخرب را میگیرد. توجه کنید که قوانین مبتنی بر هش کارایی لازم را ندارند، زیرا مهاجمان باینریهای با هش متفاوت تولید میکنند. پیادهسازی واقعی امنیت والد-فرزند (Parent-aware) نیز نیازمند ابزارهای EDR پیشرفته است.
برای توسعهدهندگان انفرادی، باز کردن مخازن ناشناس در محیطهای ایزوله مانند Windows Sandbox یا ماشینهای مجازی یکبار مصرف الزامی است. بررسی اولیه محتوای مخازن پیش از باز کردن در IDE، فیلتر کردن فایلهای اجرایی مشکوک مانند npx.exe، node.exe و git.exe از پوشه ریشه، و پرهیز از کلونکردن مستقیم پروژههای غیرقابل اعتماد، لایههای دفاعی حیاتی محسوب میشوند.
الگوی تکراری در ابزارهای هوش مصنوعی
این نقص بهتنهایی رخ نداده است. بررسیهای اخیر Cymulate نشان میدهد که چندین ابزار کدنویسی مبتنی بر AI، از جمله GitHub Copilot CLI، در ویندوز همان خطای اولویتبندی مسیر را دارند. وقتی محیط سیستم فاقد مسیرهای ارجاعدهی صحیح Git است، ابزارها مسیر دایرکتوری فعلی را بهعنوان اولویت اصلی در نظر گرفته و فایلهای اجرایی موجود در پوشه را راهاندازی میکنند. این نشان میدهد که معماری جستجوی مسیر در ابزارهای توسعه، همچنان یک نقطهضعف برای حملات Social Engineering و 供应链污染 (Supply Chain Poisoning) محسوب میشود.
ادغام عمیق هوش مصنوعی در لایه زیرساخت توسعه، مسئولیت حفاظت از محیط IDE را به سطحی بالاتر برده است. سازندگان نرمافزار باید پیش از افزودن قابلیتهای جدید، چرخه حیات محلی باینریها و اولویتهای فراخوانی سیستمعامل را بازنگری کنند. تا زمانی که این حفره پچ شود، توسعهدهندگان باید فرض کنند هر مخزن ناشناس میتواند مستقیماً به حساب امنیتی آنها نفوذ کند.
