כלי עריכת הקוד של Cursor עדיין מפעיל קובץ git.exe זדוני הממוקם בתיקיית פרויקט, פרצת zero-day קריטית שלא תוקנה במשך שבעה חודשים. הבאג מאפשר לכל קובץ הרצה המתחזה ל-Git לרוץ באופן אוטומטי עם הרשאות המשתמש, ובכך חושף מפתחים להרצת קוד מרחוק (remote code execution) ללא צורך בלחיצה או התראה.

הפגיעות התגלתה על ידי חוקר האבטחה Mindgard ב-15 בדצמבר 2025, דווחה באותו יום, ונותרה קיימת גם בגרסת יולי 2026 למרות יותר מ-197 עדכונים מצטברים ושווי חברה של 60 מיליארד דולר.

איך הבאג עובד

Cursor סורק את ספריית הפרויקט בחיפוש אחר קבצים בינאריים של Git במספר מיקומים, כולל שורש המאגר (repository root). כאשר הוא מוצא קובץ בשם git.exe, הוא מפעיל את התוכנה כדי לספק תכונות בקרת גרסאות. ההפעלה מתבצעת בשקט, ללא התראה בממשק המשתמש (UI), ויורשת את הרשאות המשתמש הנוכחי.

תוקף שיכול להוסיף קובץ למאגר יכול להחליף את קובץ ה-Git הבינארי הצפוי בכל קובץ הרצה אחר. Mindgard הדגימו את ההשפעה על ידי שינוי השם של המחשבון של Windows ל-git.exe, השלכתו לתוך מאגר ופתיחת התיקייה ב-Cursor. חלונות המחשבון קפצו שוב ושוב כל עוד הפרויקט נשאר פתוח — המחשה לאופן שבו נוזקה אמיתית יכולה להתבצע באותו אופן.

ציר זמן של החשיפה

  • 15 בדצמבר 2025 – Mindgard שולח דוא"ל לכתובת האבטחה של Cursor עם דוח מלא.
  • 15 בינואר 2026 – מנהל אבטחת המידע (CISO) של Cursor משיב, חודש לאחר מכן.
  • 16 בינואר 2026 – HackerOne, פלטפורמת ה-bug-bounty שבה משתמשת Cursor, מסווגת את הדוח כ"מחוץ לטווח" (out of scope).
  • 16 בינואר 2026 – Mindgard מספק הוכחת יכולת (proof-of-concept), מה שגורם ל-HackerOne לפתוח מחדש את הפנייה.
  • 20 בינואר 2026 – HackerOne מאשרת ש-Cursor קיבלה רשמית את הדוח.

לאחר ה-20 בינואר, הודעות המשך מ-Mindgard לא זכו למענה. Cursor המשיכה לשחרר תכונות חדשות ולגייס מימון נוסף, אך הפגיעות נותרה בתוך קוד המקור (codebase).

מדוע העיכוב מדאיג

הבעיה היא סיכון קלאסי בשרשרת האספקה: כל תורם שיכול לדחוף (push) קובץ למאגר משותף יכול להחדיר קוד זדוני שרץ על המחשב של כל מפתח.

צעדי מניעה שניתן לנקוט כעת

סביבות Windows ארגוניות

  • הפעלת מדיניות AppLocker או Windows App Control שחוסמת הפעלה של כל קובץ הרצה בשם git.exe בתוך ספריות סביבת העבודה (workspace).
  • הימנעו מרשימות מותרות (allowlists) מבוססות hash; תוקפים יכולים פשוט לשנות את ה-hash של הקובץ תוך שמירה על השם.

מפתחים בודדים

  • פתחו מאגרים ממקורות לא מהימנים רק בתוך מכונה וירטואלית או Windows Sandbox.
  • אל תסתמכו על רשימות חסימה (blocklists) מבוססות hash של קבצים; הן מעניקות תחושת ביטחון כוזבת.

פרקטיקה מומלצת כללית

  • התייחסו לכל מאגר חדש כאל וקטור פוטנציאלי בשרשרת האספקה. ודאו את המקור (provenance) של כל הקבצים הבינאריים לפני הפעלתם.

האירוע מדגיש לקח רחב יותר: כלי פיתוח מבוססי AI דורשים גישה עמוקה למערכת, וגישה זו חייבת להיות מוגנת באותה קפדנות כמו כל תוכנה בעלת הרשאות גבוהות אחרת. כאשר פגיעות בעלת השפעה גבוהה נותרת במשך חודשים בחברה בשווי מיליארדי דולרים, למפתחים יש סימן ברור להעריך מחדש את האמון שהם מניחים בפלטפורמה.