لا تزال أداة تحرير الأكواد Cursor تقوم بتشغيل ملف git.exe خبيث يتم وضعه في مجلد المشروع، وهي ثغرة "يوم الصفر" (zero-day) حرجة ظلت دون إصلاح لمدة سبعة أشهر. تسمح هذه الثغرة لأي ملف تنفيذي يتخفى في هيئة Git بالعمل تلقائياً بصلاحيات المستخدم، مما يعرض المطورين لخطر تنفيذ التعليمات البرمجية عن بُعد دون الحاجة إلى نقرة أو تحذير.

اكتشف الباحث الأمني Mindgard هذه الثغرة في 15 ديسمبر 2025، وتم الإبلاغ عنها في اليوم نفسه، ولا تزال موجودة في إصدار يوليو 2026 على الرغم من أكثر من 197 تحديثاً تدريجياً وتقييم الشركة البالغ 60 مليار دولار.

كيف تعمل الثغرة

تقوم Cursor بفحص دليل المشروع بحثاً عن ملفات Git الثنائية (binaries) في عدة مواقع، بما في ذلك جذر المستودع (repository root). عندما تجد ملفاً باسم git.exe، فإنها تقوم بتشغيل البرنامج لتوفير ميزات التحكم في الإصدار. يتم التشغيل بصمت، دون أي تنبيه في واجهة المستخدم، ويرث صلاحيات المستخدم الحالي.

يمكن للمهاجم الذي يستطيع إضافة ملف إلى المستودع استبدال ملف Git الثنائي المتوقع بأي ملف تنفيذي آخر. وقد أظهر Mindgard تأثير ذلك عن طريق إعادة تسمية حاسبة Windows إلى git.exe، ووضعها في مستودع، ثم فتح المجلد في Cursor. ظهرت نوافذ الحاسبة بشكل متكرر طالما ظل المشروع مفتوحاً — وهو توضيح لكيفية تنفيذ البرامج الضارة الحقيقية بنفس الطريقة.

الجدول الزمني للكشف عن الثغرة

  • 15 ديسمبر 2025 – Mindgard يرسل بريداً إلكترونياً إلى عنوان الأمن الخاص بـ Cursor مع تقرير كامل.
  • 15 يناير 2026 – يرد رئيس أمن المعلومات (CISO) في Cursor بعد شهر واحد.
  • 16 يناير 2026 – HackerOne، منصة مكافآت اكتشاف الثغرات التي تستخدمها Cursor، تصنف التقرير على أنه خارج النطاق (out of scope).
  • 16 يناير 2026 – يقدم Mindgard إثبات مفهوم (proof-of-concept)، مما يدفع HackerOne إلى إعادة فتح التذكرة.
  • 20 يناير 2026 – تؤكد HackerOne أن Cursor قد استلمت التقرير رسمياً.

بعد 20 يناير، لم تتلقَّ رسائل المتابعة من Mindgard أي رد. استمرت Cursor في طرح ميزات جديدة وجمع تمويل إضافي، لكن الثغرة ظلت موجودة في قاعدة الكود.

لماذا يعد هذا التأخير مقلقاً

تعد هذه المشكلة خطراً كلاسيكياً في سلاسل التوريد: أي مساهم يمكنه دفع ملف إلى مستودع مشترك يمكنه حقن كود خبيث يعمل على أجهزة كل مطور.

خطوات التخفيف التي يمكنك اتخاذها الآن

بيئات Windows للمؤسسات

  • نشر سياسات AppLocker أو Windows App Control التي تمنع تشغيل أي ملف تنفيذي باسم git.exe داخل مجلدات مساحة العمل.
  • تجنب الاعتماد على القوائم البيضاء القائمة على الهاش (hash)؛ إذ يمكن للمهاجمين ببساطة تغيير هاش الملف مع الاحتفاظ بنفس الاسم.

المطورون الأفراد

  • افتح المستودعات من المصادر غير الموثوقة فقط داخل آلة افتراضية (virtual machine) أو Windows Sandbox.
  • لا تعتمد على قوائم الحظر القائمة على هاش الملف؛ فهي تعطي شعوراً زائفاً بالأمان.

أفضل الممارسات العامة

  • تعامل مع كل مستودع جديد كمتجه محتمل لهجمات سلاسل التوريد. تحقق من مصدر جميع الملفات الثنائية قبل تنفيذها.

تؤكد هذه الواقعة على درس أوسع: تتطلب أدوات التطوير المدعومة بالذكاء الاصطناعي وصولاً عميقاً إلى النظام، ويجب حماية هذا الوصول بنفس الصرامة التي تُحمى بها أي برمجيات ذات صلاحيات أخرى. عندما تظل ثغرة عالية التأثير قائمة لشهور في شركة تقدر بمليارات الدولارات، فإن ذلك يعطي المطورين إشارة واضحة لإعادة تقييم الثقة التي يضعونها في المنصة.