ابزار ویرایش کد Cursor همچنان یک فایل مخرب git.exe را که در پوشه پروژه قرار گرفته، اجرا می‌کند؛ یک آسیب‌پذیری بحرانی روز صفر (zero-day) که به مدت هفت ماه بدون وصله (patch) باقی مانده است. این باگ اجازه می‌دهد هر فایل اجرایی که خود را به جای Git جا می‌زند، به‌صورت خودکار با سطح دسترسی کاربر اجرا شود و توسعه‌دهندگان را بدون نیاز به کلیک یا هشدار، در معرض اجرای از راه دور کد (remote code execution) قرار دهد.

این نقص توسط محقق امنیتی Mindgard در ۱۵ دسامبر ۲۰۲۵ کشف شد، در همان روز گزارش گردید و با وجود بیش از ۱۹۷ به‌روزرسانی تدریجی و ارزش ۶۰ میلیارد دلاری شرکت، همچنان در نسخه جولای ۲۰۲۶ نیز وجود دارد.

نحوه عملکرد این باگ

Cursor دایرکتوری پروژه را برای یافتن باینری‌های Git در چندین مکان، از جمله ریشه مخزن (repository root)، اسکن می‌کند. هنگامی که فایلی با نام git.exe پیدا می‌کند، آن برنامه را برای ارائه قابلیت‌های کنترل نسخه اجرا می‌کند. این اجرا به‌صورت بی‌صدا و بدون هیچ اعلان در رابط کاربری (UI) انجام می‌شود و مجوزهای کاربر فعلی را به ارث می‌برد.

مهاجم اگر بتواند فایلی را به مخزن اضافه کند، می‌تواند باینری مورد انتظار Git را با هر فایل اجرایی دیگری جایگزین کند. Mindgard این اثر را با تغییر نام ماشین‌حساب ویندوز (Windows Calculator) به git.exe نشان داد؛ او این فایل را در یک مخزن قرار داد و پوشه را در Cursor باز کرد. تا زمانی که پروژه باز بود، پنجره‌های ماشین‌حساب مکرراً ظاهر می‌شدند—نمونه‌ای از اینکه چگونه یک بدافزار واقعی می‌تواند به همین شیوه اجرا شود.

جدول زمانی افشا

  • ۱۵ دسامبر ۲۰۲۵ – Mindgard یک گزارش کامل را به آدرس امنیتی Cursor ایمیل کرد.
  • ۱۵ ژانویه ۲۰۲۶ – مدیر ارشد امنیت اطلاعات (CISO) شرکت Cursor، یک ماه بعد پاسخ داد.
  • ۱۶ ژانویه ۲۰۲۶ – HackerOne، پلتفرم پاداش باگ (bug-bounty) که توسط Cursor استفاده می‌شود، این گزارش را خارج از محدوده (out of scope) طبقه‌بندی کرد.
  • ۱۶ ژانویه ۲۰۲۶ – Mindgard یک اثبات مفهوم (proof-of-concept) ارائه داد که باعث شد HackerOne تیکت را مجدداً باز کند.
  • ۲۰ ژانویه ۲۰۲۶ – HackerOne تأیید کرد که Cursor رسماً گزارش را دریافت کرده است.

پس از ۲۰ ژانویه، پیام‌های پیگیری Mindgard هیچ پاسخی دریافت نکرد. Cursor به عرضه ویژگی‌های جدید و جذب سرمایه‌های بیشتر ادامه داد، اما این آسیب‌پذیری در کد باقی ماند.

چرا این تأخیر نگران‌کننده است

این مسئله یک ریسک کلاسیک در زنجیره تأمین (supply-chain risk) است: هر مشارکت‌کننده‌ای که بتواند فایلی را به یک مخزن مشترک ارسال کند، می‌تواند کد مخربی را تزریق کند که روی ماشین هر توسعه‌دهنده‌ای اجرا می‌شود.

اقدامات اصلاحی که می‌توانید اکنون انجام دهید

محیط‌های سازمانی ویندوز (Enterprise Windows environments)

  • سیاست‌های AppLocker یا Windows App Control را پیاده‌سازی کنید که از اجرای هر فایل اجرایی با نام git.exe در داخل دایرکتوری‌های فضای کاری (workspace) جلوگیری کند.
  • از لیست‌های سفید مبتنی بر هش (hash-based allowlists) صرف‌نظر کنید؛ مهاجمان می‌توانند به‌سادگی هش فایل را تغییر دهند در حالی که نام آن را ثابت نگه می‌دارند.

توسعه‌دهندگان انفرادی

  • مخازن دریافتی از منابع غیرقابل اعتماد را فقط در داخل یک ماشین مجازی یا Windows Sandbox باز کنید.
  • به لیست‌های سیاه هش فایل (file-hash blocklists) اتکا نکنید؛ آن‌ها احساس امنیت کاذبی ایجاد می‌کنند.

بهترین روش‌های عمومی

  • با هر مخزن جدید به عنوان یک بردار احتمالی در زنجیره تأمین برخورد کنید. اصالت تمام باینری‌ها را قبل از اجرا تأیید کنید.

این ماجرا درس گسترده‌تری را گوشزد می‌کند: ابزارهای توسعه مبتنی بر هوش مصنوعی به دسترسی عمیق به سیستم نیاز دارند و این دسترسی باید با همان دقت و سخت‌گیریِ هر نرم‌افزار سطح‌بالای دیگری محافظت شود. وقتی یک آسیب‌پذیری با تأثیر بالا برای ماه‌ها در یک شرکت چند میلیارد دلاری باقی می‌ماند، توسعه‌دهندگان سیگنال واضحی برای بازنگری در اعتمادی که به این پلتفرم دارند، دریافت می‌کنند.