تصور کنید تنها با باز کردن یک پوشه پروژه که از گیت‌هاب دانلود کرده‌اید، تمام دسترسی‌های سیستم شما به دست یک غریبه بیفتد. یک فایل ساده به نام git.exe می‌تواند کل ماشین یک برنامه‌نویس را در اختیار مهاجم قرار دهد.
Mindgard فاش کرد که ویرایشگر کد Cursor فایل‌های اجرایی موجود در ریشه پروژه را بدون هیچ هشدار یا تأییدی اجرا می‌کند. این یک آسیب‌پذیری «روز-صفر» (Zero-day) است که تمام استانداردهای امنیتی یک محیط توسعه حرفه‌ای را به کلی نادیده می‌گیرد و اجازه می‌دهد مهاجمان کنترل کامل سیستم کاربر را به دست بگیرند.
این نقص در زمانی رخ می‌دهد که IDEهای متکی به هوش مصنوعی در حال تبدیل شدن به رابط اصلی مهندسی نرم‌افزار هستند. ابعاد اثر این باگ بسیار گسترده است؛ چرا که Cursor بیش از ۷ میلیون کاربر فعال دارد که شامل ۱ میلیون کاربر روزانه و ۱ میلیون کاربر پرداخت‌کننده است. همچنین ۵۰ هزار شرکت از این ابزار در محیط کاری خود استفاده می‌کنند. طبق گزارش‌ها، ارزش بازار Cursor به ۶۰ میلیارد دلار رسیده است؛ اما نبودِ اصلاح فوری، نشان از شکافی عمیق میان ارزش شرکتی و عملکردهای امنیتی این ابزار دارد.
برنامه‌نویسان حساس‌ترین دارایی‌های خود شامل کد منبع، کلیدهای API، مالکیت‌های معنوی اختصاصی و اعتبارنامه‌های محیط عملیاتی (Production Credentials) را به این ابزار می‌سپارند. آن‌ها نرم‌افزاری را در محیط عملیاتی خود اجرا می‌کنند که دسترسی مستقیم به ترمینال دارد و دارای قابلیت‌های به‌طور فزاینده‌ای خودمختار است؛ قابلیت‌هایی که مرز بین «پیشنهاد کد» و «اجرای دستور» را از بین برده است. این ریسک دسترسی‌های غیرمجاز به مخازن، یادآور آسیب‌پذیری GitLost است که منجر به افشای داده‌های مخازن خصوصی گیت‌هاب شد و نشان می‌دهد که ابزارهای مدرن توسعه چگونه می‌توانند به نقطه ضعف تبدیل شوند.
وقتی یک مخزن کد (Repository) را کلون می‌کنید، انتظار دارید IDE فقط فایل‌ها را فهرست و ایندکس کند. اما منطق شناسایی مسیر در Cursor با یک فایل جعلی git.exe برخورد می‌کند و آن را به‌عنوان ابزار رسمی شناسایی و به‌طور خودکار اجرا می‌کند. نکته مهم این است که این اتفاق هیچ ارتباطی به «تزریق پرامپت» (Prompt Injection)، دست‌کاری مدل، جیل‌بریک (Jailbreak) یا مسائل مربوط به فساد حافظه (Memory Corruption) ندارد. این حمله نیازی به مهارت‌های پیچیده مهاجم ندارد؛ بلکه یک شکست بنیادین در نحوه مدیریت فایل‌های اجرایی در محیط کاری است.
سازوکار فنی حمله
به نقل از گزارش Mindgard، این آسیب‌پذیری از نحوه مکان‌یابی باینری‌های Git در زمان بارگذاری پروژه نشأت می‌گیرد. IDE تلاش می‌کند فایل‌های اجرایی git را در مکان‌های مختلف جستجو کند و یکی از این مکان‌ها دقیقاً ریشه فضای کاری فعلی (Workspace Root) است.
اگر مهاجمی یک فایل git.exe مخرب را در ریشه مخزن قرار دهد، Cursor آن را به‌طور خودکار به‌عنوان بخشی از منطق شناسایی مسیر خود اجرا می‌کند. این فرآیند بدون هیچ تعاملی با کاربر، بدون هیچ کلیکی، بدون پنجره‌های تأیید و بدون هیچ هشداری مبنی بر اینکه محتوای اجرایی از مخزن در حال اجرا است، رخ می‌دهد.
- محرک (Trigger): صرفاً باز کردن پوشه پروژه‌ای که باینری مخرب در ریشه آن قرار دارد.
- تعامل (Interaction): صفر؛ هیچ پرامپت یا تأییدیه‌ای لازم نیست.
- اجرا (Execution): باینری به عنوان یک «اجرای کد دلخواه» (Arbitrary Code Execution) با سطح دسترسی و امتیازات کاربر فعلی اجرا می‌شود.
- تداوم (Persistence): این یک اتفاق یک‌باره نیست؛ Cursor در بازه‌های زمانی منظم و در حین باز بودن پروژه، این باینری را چندین بار فراخوانی می‌کند.
برای اثبات این ریسک به صورت ایمن، محققان از یک نمونه اثبات مفهوم (PoC) بی‌خطر استفاده کردند: آن‌ها برنامه ماشین‌حساب ویندوز (Windows Calculator) را به git.exe تغییر نام دادند و در ریشه پروژه قرار دادند. به محض باز کردن آن پروژه در Cursor، چندین پنجره ماشین‌حساب به‌طور خودکار باز شدند.
این آزمایش ثابت کرد که IDE در حین عملیات عادی و تکرارشونده، مدام آن فایل تغییر نام یافته را اجرا می‌کند و باعث می‌شود نمونه‌های بیشتری از برنامه در طول زمان ظاهر شوند. در یک سناریوی حمله واقعی، ماشین‌حساب جای خود را به کدهای تحت کنترل مهاجم می‌دهد تا دسترسی کامل به سیستم به دست آید.
شواهد این اجرا در لاگ‌های Sysinternals Process Monitor ثبت شده است. گزارشی که در ۳۰ آوریل ۲۰۲۶ روی نسخه ۳.۲.۱۶ Cursor در ویندوز تأیید شد، دقیقاً لحظه ایجاد پردازش را ثبت کرده است: 4:25:12.6209706 PM Cursor.exe 54880 Process Create c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe SUCCESS PID: 48972.
شکست در فرآیند افشای امنیتی
باعث نگرانی بیشتر، خط زمانی این ماجرا و نبود پاسخ از سوی شرکت است. Mindgard این نقص را در ۱۵ دسامبر ۲۰۲۵ شناسایی و دقیقاً در همان روز گزارش کرد. در هفت ماه بعد، محققان از تمام کانال‌های موجود برای برقراری ارتباط تلاش کردند.
گزارش اولیه به ایمیل گزارش امنیتی که در فایل security.txt منتشر شده بود ارسال شد. پس از اینکه هیچ تأییدیه‌ای نرسید، پیام‌های پیگیری ارسال شد و در نهایت Mindgard برای یافتن یک رابط امنیتی مناسب، اقدام به اطلاع‌رسانی عمومی در لینکدین کرد.
در نهایت، مدیر ارشد امنیت (CISO) شرکت Cursor پاسخ داد و اذعان کرد که یک نقص در اتوماسیون داخلی باعث شده جریان کاری مورد انتظار در پلتفرم HackerOne فعال نشود. پس از این اتفاق، Mindgard به برنامه خصوصی پاداش باگ (Bug Bounty) دعوت شد و گزارش را در ۱۵ ژانویه ۲۰۲۶ دوباره ارسال کرد.
در ابتدا، گزارش به عنوان «اطلاعاتی» (Informative) و «خارج از محدوده» (Out of Scope) بسته شد. پس از اینکه Mindgard به این تصمیم اعتراض کرد، HackerOne گزارش را باز کرد، مشکل را بازتولید نمود و در ۲۰ ژانویه ۲۰۲۶ تحویل Cursor داد. اما پس از این تاریخ، تمام ارتباطات قطع شد.
درخواست‌های به‌روزرسانی در فوریه، مارس و آوریل ۲۰۲۶ بی‌پاسخ ماند. ارتباط مستقیم با مدیران Cursor و ارجاع موضوع از طریق HackerOne هیچ تعامل معناداری به همراه نداشت. ماه به ماه می‌گذشت بدون اینکه شواهدی از بررسی تیم‌های مهندسی یا اطلاع‌رسانی به کاربران درباره این ریسک وجود داشته باشد.
در همین حال، Cursor به عرضه نسخه‌های جدید ادامه داد. بیش از ۷۰ نسخه — و در مجموع بیش از ۱۹۷ نسخه جدید — از زمان گزارش اولیه منتشر و حذف شدند. ویژگی‌های جدید معرفی شدند و اطلاعیه‌های مختلف منتشر شد، اما این آسیب‌پذیری در جدیدترین نسخه‌های تست‌شده همچنان باقی بود.
راهکارهای جایگزین برای کاربران
به دلیل نبود وصله (Patch) رسمی تا جولای ۲۰۲۶، کاربران باید کنترل‌های جبرانی خود را برای ارزیابی میزان مواجهه و کاهش ریسک اعمال کنند.
سیستم‌های مدیریت‌شده سازمانی در ویندوز:
- مدیران سیستم باید از AppLocker یا Windows App Control برای جلوگیری از اجرای فایل‌های اجرایی با نام‌های تأثرپذیر در دایرکتوری‌های فضای کاری توسعه‌دهندگان استفاده کنند.
- روش پیشنهادی: استفاده از قوانین منعِ مبتنی بر مسیر (Path-based deny rules) که روی ریشه مخازن متمرکز است (مثلاً
%USERPROFILE%\source\repos\*\filename.exe). - هشدار: به قوانین مبتنی بر هش (Hash) اعتماد نکنید، زیرا باینری‌های ارسالی توسط مهاجمان از نظر هش متفاوت خواهند بود.
- نکته: از آنجایی که ویندوز فاقد قانونی داخلی برای مسدود کردن فایل‌های اجرایی فرزند (Child Executables) که توسط یک پردازش والد خاص اجرا می‌شوند است، اجرای این سیاست نیازمند یک محصول امنیتی پیشرفته در نقاط انتهایی (Endpoint Security) یا EDR است.
سیستم‌های شخصی:
- تا زمانی که IDE اصلاح شود، مخازن غیرمعتبر را فقط در ماشین مجازی (VM)، Windows Sandbox یا سایر محیط‌های یک‌بار مصرف باز کنید.
- برای این مشکل خاص، از تکیه بر لیست‌های سیاه هش فایل خودداری کنید.
شکاف اعتماد در ابزارهای هوش مصنوعی
این حادثه تنش فزاینده‌ای را در صنعت هوش مصنوعی برجسته می‌کند. شرکت‌ها دسترسی بی‌سابقه‌ای به کدهای خصوصی و ترمینال‌ها می‌خواهند، اما در رعایت بهداشت امنیتی ابتدایی شکست می‌خورند. وقتی ارزش بازار شرکتی به ۶۰ میلیارد دلار می‌رسد، بی‌توجهی به یک باگ اجرای کد از راه دور (RCE)، نشان‌دهنده اولویت دادن خطرناک به رشد سریع بر ایمنی است.
این موضوع پرسشی را ایجاد می‌کند که آیا برنامه‌های پاداش باگ بیش از حد overloaded شده‌اند؟ محققان می‌پرسند آیا ابزارهایی مثل Mythos حجم یافته‌ها را به حدی رسانده‌اند که فراتر از ظرفیت تریاژ (Triage) فروشنده است؟ این چالش در حالی رخ می‌دهد که سرعت تحلیل خودکار AI در برابر پروتکل‌های سنتی افشای آسیب‌پذیری در حال تغییر است و باعث ایجاد حجم عظیمی از گزارش‌ها برای تیم‌های امنیتی می‌شود. یا شاید سؤال ناخوشایند این است: آیا ایمنی کاربر به دلیل رشد سریع یا مشغله‌های مربوط به تصاحب SpaceX کنار گذاشته شده است؟
اعتماد به ابزارهای هوش مصنوعی نمی‌تواند فقط بر اساس کاربردی بودن باشد؛ اعتماد باید با رفتار به دست آید. این رفتار در نحوه پاسخ شرکت به گزارش‌های امنیتی و اولویت‌بندی اصلاحات منعکس می‌شود. وقتی آسیب‌پذیری‌های ساده برای ماه‌ها حل‌نشده می‌ماند، کاربران مجبورند در این اعتماد بازنگری کنند.
چرا Mindgard افشای کامل را انتخاب کرد؟
Mindgard ترجیح می‌دهد از «افشای هماهنگ» (Coordinated Disclosure) استفاده کند؛ جایی که ابتدا نقص گزارش شده، شدت آن بحث می‌شود و اصلاحیه ساخته می‌شود و سپس خبر عمومی می‌گردد. اما هماهنگی تنها زمانی ممکن است که طرف مقابل نیز در این هماهنگی شرکت کند.
پس از هفت ماه و نبود هرگونه تعامل از سوی فروشنده، محققان تشخیص دادند که پنهان کردن اطلاعات دیگر به نفع کاربران نیست، بلکه تنها به نفع «سکوت» شرکت است. افشاگری کامل به عنوان «گزینه هسته‌ای» در نظر گرفته می‌شود؛ راهی که تنها زمانی طی می‌شود که تمام مسیرهای دیگر شکست خورده باشند.
با انتشار این جزئیات، سازمان‌ها می‌توانند تصمیمات ریسکی آگاهانه بگیرند. ایمنی کاربر باید اولویت باشد، به‌خصوص زمانی که فروشنده در حالی که نرم‌افزار آسیب‌دیده را همچنان توزیع می‌کند، ارتباط را قطع کرده است.
خط زمانی رویدادها
- ۱۵ دسامبر ۲۰۲۵: کشف آسیب‌پذیری و گزارش به
[email protected]. - ۱۸ دسامبر ۲۰۲۵: ارسال پیگیری برای تأیید دریافت گزارش.
- ۱۳ ژانویه ۲۰۲۶: انتشار پست در لینکدین برای یافتن رابط؛ شناسایی CISO در کامنت‌ها.
- ۱۵ ژانویه ۲۰۲۶: پاسخ CISO درباره نقص اتوماسیون؛ دعوت به HackerOne و ارسال گزارش.
- ۱۶ ژانویه ۲۰۲۶: بسته شدن گزارش به عنوان «اطلاعاتی»، اعتراض Mindgard و سپس بازگشایی پس از بازتولید مشکل.
- ۲۰ ژانویه ۲۰۲۶: تأیید تحویل گزارش به Cursor توسط HackerOne.
- ۱۶ فوریه تا ۱ آوریل ۲۰۲۶: درخواست‌های متعدد به‌روزرسانی؛ عدم دریافت پاسخ از Cursor.
- ۱۷ مارس ۲۰۲۶: ارتباط مستقیم با CISO Cursor برای دریافت به‌روزرسانی.
- ۱۸ مارس ۲۰۲۶: اعلام HackerOne مبنی بر اینکه با Cursor تماس گرفته شده است.
- ۱ ژوئن ۲۰۲۶: اطلاع Mindgard به HackerOne درباره قصد افشای عمومی.
- ۳ ژوئن ۲۰۲۶: ارائه راهنمای افشا توسط HackerOne.
- ۱۴ جولای ۲۰۲۶: انتشار عمومی گزارش.
گام بعدی شما
- اگر از Cursor استفاده می‌کنید، هرگز مخازن ناشناخته را بدون استفاده از محیط‌های ایزوله مثل Sandbox باز نکنید.
- مدیران سیستم‌های ویندوزی باید سریعاً قوانین AppLocker را برای مسیرهای کدنویسی فعال کنند.
- نتایج بررسی‌های امنیتی سایر IDEهای هوش مصنوعی را دنبال کنید تا متوجه شوید آیا این یک نقص ساختاری در این دسته از ابزارهاست یا خیر.
اما داستان سخت‌افزاری این تحولات حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو