باگ اجرای کد در Cursor؛ هفت ماه بدون پاسخ
هوش مصنوعیخلاصهٔ کاملتر
آرون پورتنوی از شرکت امنیتی Mindgard تو یه پست، جزئیات یه آسیبپذیری اجرای کد دلخواه در Cursor رو بهشکل «افشای کامل» منتشر کرده. تأکید نویسنده اینه که این یکی از اون باگهای پیچیدهای نیست که چند صفحه توضیح بخواد؛ ماجرا بهشکل ناراحتکنندهای سادهست.
مکانیزم باگ اینه: Cursor موقع لود کردن یه پروژه، برای پیدا کردن باینری گیت چند مسیر رو میگرده و یکی از اون مسیرها خود ورکاسپیسه. اگه مهاجم یه فایل اجرایی به اسم گیت تو ریشهٔ مخزن گذاشته باشه، Cursor روی ویندوز همون رو بهعنوان بخشی از منطق تشخیص مسیر اجرا میکنه — بدون کلیک، بدون دیالوگ تأیید، بدون هشدار. نتیجه اجرای کد دلخواه با دسترسی کاربر جاریه.
نکتهٔ بدتر اینه که اجرا یکباره نیست. Mindgard برای نمایش بیخطر ماجرا ماشینحساب ویندوز رو با اسم باینری گیت تو ریشهٔ ریپو گذاشته و دیده که تا وقتی پروژه بازه، Cursor مدام دوباره اجراش میکنه و پنجرههای تازه باز میشن. یعنی این یه رویداد تکباره یا وابسته به کار کاربر نیست، بخشی از کار عادی برنامهست.
به گفتهٔ نویسنده، بهرهبرداری هیچ زنجیرهٔ پیچیدهای لازم نداره: نه تزریق پرامپت، نه دستکاری مدل، نه جیلبریک، نه خرابی حافظه. فقط کافیه یه توسعهدهنده پروژهای رو باز کنه که چنین فایلی داخلش باشه. با توجه به مقیاس Cursor — به روایت مقاله بیش از ۷ میلیون کاربر فعال، بیش از یک میلیون کاربر روزانه و بیش از ۵۰ هزار شرکت — سطح تأثیر کم نیست.
بخش عجیب ماجرا واکنش سازندهست. Mindgard میگه گزارش رو همون روز کشف، ۱۵ دسامبر ۲۰۲۵، فرستاده و چند بار پیگیری کرده. در نهایت CISO شرکت گفته یه خرابی تو اتوماسیون مانع دعوت به باگبانتی خصوصی شده؛ گزارش از HackerOne ثبت شد، اول «اطلاعاتی و خارج از دامنه» بسته شد، بعد از اعتراض دوباره باز و بازتولید شد و بعد همهچیز متوقف شد. به گفتهٔ نویسنده، بیش از شش ماه و ۱۹۷ نسخه بعد، باگ هنوز تو آخرین نسخهٔ تستشده هست.
همینجاست که استدلال اصلی مقاله شکل میگیره: افشای هماهنگ فقط وقتی کار میکنه که هماهنگیای در کار باشه. نویسنده میگه وقتی ماهها بدون پاسخ میگذره و شرکت همزمان به انتشار نسخههای جدید ادامه میده، پژوهشگر بین دو گزینه گیر میکنه: سکوت و رها کردن کاربرها تو تصور اشتباهِ امنیت، یا انتشار عمومی تا سازمانها بتونن ریسک خودشون رو بسنجن. Mindgard گزینهٔ دوم رو انتخاب کرده و افشای کامل رو «گزینهٔ هستهای» میدونه که فقط وقتی همهٔ راههای دیگه شکست خورده بهکار میاد.
برای کاربرها هم راهکار موقت پیشنهاد داده. تو سیستمهای ویندوزی مدیریتشده، مدیرها میتونن با AppLocker یا Windows App Control اجرای اون نام فایل رو از مسیر ورکاسپیسهای توسعه ممنوع کنن؛ توصیهش قواعد مبتنی بر مسیره نه هش، چون هش باینری مهاجم هر بار فرق میکنه. ویندوز راه داخلی عمومی برای بلاککردن یه فرزند اجرایی بر اساس پروسهٔ والد نداره، پس اعمال دقیقتر به EDR نیاز داره. کاربر عادی هم بهتره مخزن نامطمئن رو فقط تو ماشین مجازی یا Windows Sandbox باز کنه.
مقاله آخرش از یه مسئلهٔ بزرگتر حرف میزنه: شرکتهای هوش مصنوعی از کاربر میخوان سطح بیسابقهای از دسترسی به کد، ترمینال، اعتبارنامهها و مالکیت فکریش رو بده. نویسنده میگه اعتماد رو نباید بهخاطر مفید بودن یه ابزار داد؛ اعتماد از رفتار بهدست میاد — از اینکه شرکت به گزارش امنیتی چطور جواب میده و چقدر با کاربر آسیبدیده شفافه.
نکات کلیدی:
- باز کردن مخزنی که باینری کاشتهشده داره، روی ویندوز به اجرای کد دلخواه ختم میشه
- علت: ورکاسپیس هم جزو مسیرهای جستجوی Cursor برای پیدا کردن گیته
- اجرا بدون کلیک و تأیید انجام میشه و تا باز بودن پروژه تکرار میشه
- گزارش از ۱۵ دسامبر ۲۰۲۵ ثبت شده و به گفتهٔ Mindgard هنوز رفع نشده
- راهکار سازمانی: قواعد مسیرمحور AppLocker یا Windows App Control، نه بلاکلیست هش
- راهکار کاربر عادی: باز کردن مخزن نامطمئن فقط تو ماشین مجازی یا Windows Sandbox
