פרויקט הגיע בקובץ zip, והקוד רץ לפני שהקלדתם מילה: שמונה חולשות בשבעה סוכני קוד של AI
קולגה שולח לכם פרויקט בקובץ zip. אתם פותחים אותו, נכנסים לתיקייה, ומריצים שם סוכן קוד של AI כדי להבין מה בעצם יש בפנים. עוד לפני שהקלדתם מילה, ולפני שהסוכן הספיק לשאול אתכם אם אתם סומכים על התיקייה הזאת, פקודה שהתוקף בחר כבר רצה על המחשב שלכם, בהרשאות שלכם, בלי שום סימן על המסך.
חוקרי Manifold Security פרסמו ב-1 בספטמבר מחקר שמתאר שמונה ממצאים כאלה בשבעה סוכני קוד שרצים בשורת הפקודה, ביניהם Claude Code, Codex של OpenAI, Cursor, Grok Build ו-Qwen Code. ארבעה מהם עדיין לא היו מתוקנים ביום הפרסום. פרנסיסקו רוסאלס, שחתום על המחקר, קרא לזה GitSpawn, והנקודה שהוא מדגיש היא שהחולשה לא יושבת במודל ולא בשום דבר חדש. היא יושבת באינסטלציה הרגילה שמתחת, בתת-תהליך שהסוכן מייצר ברגע שהוא עולה כדי להבין איפה הוא נמצא.
בהמשך נראה מה רץ שם בדיוק, למה שכפול רגיל של מאגר אינו מסוכן וקובץ zip כן, ולמה אותה טעות עצמה חוזרת אצל יצרן אחרי יצרן.
מה רץ לפני שהקלדתם משהו
כשסוכן קוד נפתח בתיקייה, הדבר הראשון שהוא עושה הוא לאסוף הקשר. באיזה ענף אנחנו נמצאים, אילו קבצים שונו, מה המאגר מכיל בכלל. את התשובות הוא לא ממציא לבד, הוא שואל את git. שתי דוגמאות מתוך רבות שהחוקרים ראו במוצרים שונים הן git status עם דגלי porcelain ו-branch, ו-git diff עם name-only מול HEAD. פקודות רגילות לגמרי, מהסוג שכל מפתח כותב בעצמו.
הבעיה מתחילה בשלב שקודם להן. כמעט כל פקודת git שנוגעת בעץ העבודה מרעננת קודם את האינדקס, אותה רשימה פנימית שבה git מחזיק את מצב הקבצים. במאגרים גדולים הריענון הזה איטי, ולכן git תומך בקיצור דרך: במקום לעבור על כל קובץ בדיסק, הוא מריץ תוכנית עזר חיצונית ושואל אותה מה השתנה מאז. את שם התוכנית הזאת git קורא מקובץ ההגדרות של המאגר עצמו, .git/config. להגדרה קוראים core.fsmonitor, וההתנהגות הזאת מתועדת ומכוונת לחלוטין.
וכאן נכנס לתמונה התוקף. מאגר יכול לרשום בקובץ ההגדרות שלו שתוכנית העזר היא בעצם פקודה שהוא בחר, וכל פקודת git שמרעננת את האינדקס תריץ אותה. git status תריץ אותה. git diff תריץ אותה. באיזו פקודה הסוכן בחר להשתמש כבר לא משנה, כי כולן עוברות דרך אותו ריענון.
הפרט שהופך את זה לחמור דווקא אצל סוכני AI, ולא סתם אצל git, הוא איפה הפקודה רצה. הסוכן עצמו הוא זה שמייצר את תת-התהליך, ולכן הפקודה יוצאת אל מחוץ ל-sandbox שלו ולא עוברת בשום שלב דרך מנגנון אישור הפעולות של הסוכן. מודל ההרשאות פשוט לא רואה אותה. מה שהתוקף מקבל בסוף הוא הרצת קוד בהרשאות המפתח: מפתחות ה-SSH שלו, פרטי האימות לענן שיושבים במשתני הסביבה, ה-token-ים שבקובץ ההגדרות של ה-shell, וכל מאגר אחר ששוכב על אותו דיסק.
למה שכפול אינו מסוכן וקובץ zip כן
שווה לדייק כאן, כי הפרט הזה קובע כמה אתם בכלל חשופים. git עצמו לא מעביר את ההגדרה הזאת הלאה. שכפול של מאגר עוין מכתובת כלשהי לא עושה כלום, וגם fetch או pull לא. ההגדרות המקומיות של מאגר פשוט לא נוסעות יחד עם הקוד. כדי שהתקיפה תעבוד, המאגר צריך להגיע אליכם כקבצים, עם תיקיית ה-git שלו שלמה בפנים.
אז מה מעביר תיקייה במקום לשכפל אותה? קובץ zip ששלחו לכם, כונן משותף, תיקיית סנכרון, דיסק-און-קי. בדיוק הדרכים שבהן קולגות מעבירים אחד לשני פרויקטים, ושבהן יועצים מוסרים קוד ללקוח. Manifold כותבים שבכל הוכחות ההיתכנות שלהם הם השתמשו בקובץ zip.
זה מצמצם את קהל הקורבנות ומחדד אותו באותה נשימה. מי שרק מושך פרויקטים מ-GitHub לא ייפגע מהמסלול הזה. מי שמקבל קוד מבחוץ, וזה כמעט כל מי שעובד מול לקוח, ספק או קבלן משנה, כן.
אותה טעות, סוכן אחרי סוכן
הרשימה של Manifold בנויה סביב שתי שאלות קבועות לכל מוצר: איפה הסוכן קורא ל-git, ומה מפעיל את הקריאה.
ב-goose, הפקודה goose review בונה את ה-diff לביקורת הקוד. היא מעבירה ל-git דגל הגדרה אחד בלבד ולא מנקה שום דבר מעבר לזה, כך שהאינדקס מתרענן והפקודה של המאגר רצה עוד לפני ש-goose פנה למודל בכלל. זה הממצא היחיד בקבוצה שקיבל ציון: CVE-2026-72718, עם ציון CVSS 4.0 של 7.0, בכל הגרסאות שלפני 1.44.0. התיקון יצא ב-1.44.0.
ב-Claude Code נמצאו שני מסלולים נפרדים. הראשון הוא core.fsmonitor הקלאסי: הסוכן מריץ git status באתחול כדי לאסוף הקשר, לא מסנן דבר, והפקודה של המאגר רצה לפני שאישרתם את שאלת האמון. Manifold אישרו אותו בגרסה 2.1.193, והוא נסגר בגרסה 2.1.196. המסלול השני הוא claude ultrareview, ושם מדובר בהגדרת git אחרת לגמרי מאותה משפחה. את שם ההגדרה הזאת החוקרים בחרו לא לפרסם כל עוד היא פתוחה, והם אישרו שהיא עדיין עובדת בגרסה 2.1.252 בבדיקה חוזרת ב-1 בספטמבר.
Hermes Agent, Qwen Code ו-Grok Build נפלו שלושתם על אותה קריאת git status לא מסוננת, ונבדלים רק ברגע שבו הפקודה יוצאת לדרך. ב-Hermes היא רצה כשהמשתמש שולח את ההודעה הראשונה שלו. ב-Qwen Code היא רצה כבר באתחול, עוד לפני שהמשתמש התחבר לחשבון. וב-Grok Build היא רצה על ההקשה הראשונה על המקלדת, לפני שנשלחה הודעה כלשהי. שלושתם עדיין לא תוקנו לפי הבדיקה החוזרת של Manifold ב-1 בספטמבר, בגרסאות 0.21.0, 0.22.3 ו-1.0.13 בהתאמה. ל-Hermes הוקצה מזהה חולשה, CVE-2026-71963, ולפי Manifold ההקצאה נעשתה דרך VulnCheck ולא דרך היצרן. הרשומה עצמה עדיין לא פורסמה במאגר של MITRE.
Codex של OpenAI קיבל טיפול נפרד, ורשמי. רשומת CVE-2026-19592, שהחברה פרסמה בעצמה באותו 1 בספטמבר, מתארת את אותה חולשה במילים שלה: Codex אסף מטא-דאטה של מאגר בלי לנטרל את הגדרת core.fsmonitor המקומית. תוכנית העזר, כתבו שם, "רצה מחוץ ל-sandbox של Codex ובלי בקשת אישור מהמשתמש, ומאפשרת לקוד בשליטת התוקף לרוץ בהרשאות המשתמש". הגרסאות המושפעות ב-Codex CLI הן 0.102.0 עד 0.130.0, והתיקון הוא 0.131.0.
ומה קרה כשדיווחו
החלק שמעניין אולי יותר מהחולשות עצמן הוא מה שקרה אחרי הדיווח, והוא מסופר כאן מנקודת המבט של Manifold בלבד. מתוך שמונת הממצאים, חמישה דיווחים חזרו אליהם בתור כפילות של ממצא שחוקר אחר כבר הגיש באופן עצמאי, ואחד מהם הוגש באותו יום ממש. זאת אינדיקציה טובה לכך שהדפוס מתגלה כרגע מכמה כיוונים במקביל, לא רק על ידם.
הדיווח על Grok Build נסגר ככפילות של דיווח מוקדם יותר מ-1 ביולי, שאותו xAI סגרה עוד קודם בתור מידע בלבד ולא כחולשה. על Hermes, Manifold מתארים שישה ניסיונות יצירת קשר בחמישה ערוצים שונים, שאף אחד מהם לא הוביל לטיפול. הדיווח על Qwen Code התקבל דווקא, במרכז התגובה של עליבאבא ב-7 ביולי, והחולשה עדיין פתוחה כמעט חודשיים אחר כך. החוקרים מדגישים שכל ממצא דווח בערוץ פרטי, ושכל אחד מאלה שנשארו פתוחים נבדק שוב מול גרסה עדכנית ממש לפני הפרסום.
הם גם בחרו מה לא לפרסם: אין שם מאגר מוכן שאפשר להפנות לעמית לעבודה, ואת מפתח ההגדרה של המסלול השני ב-Claude Code הם השאירו בלי שם כל עוד הוא לא תוקן.
הבאג הזה כבר היה כאן ב-2021
core.fsmonitor לא התגלה השבוע, וגם לא ההבנה שאפשר לנצל אותו. יניב ניזרי מ-Sonar פרסם ב-30 באפריל תיאור של אותה חולשה בדיוק ב-Claude Code, שאנת'רופיק סגרה בגרסה 2.0.71 עוד ב-16 בדצמבר 2025. ניזרי מצביע בפוסט על כך שאותו טריק שימש כבר כדי לעקוף את דיאלוג האמון של Visual Studio Code בגרסאות שלפני 1.63.1, ורושם לו את CVE-2021-43891.
מה שקרה אחר כך מסביר למה המשפחה הזאת שורדת תיקונים. אנת'רופיק סגרה את המקרה הספציפי בגרסה 2.0.34, פשוט בכך שהפסיקה להריץ git status לפני אישור האמון. Sonar חזרו לבדוק, גילו שהסוכן עדיין מריץ בלי אישור שורה של פקודות git אחרות, והתחילו לחפש הגדרה אחרת שמצביעה על תוכנית. אחרי כמה ניסיונות שלא עבדו הם מצאו אחת: הגדרה שגורמת ל-git log לאמת חתימות של commit-ים, ובדרך להריץ את gpg, בשילוב עם הגדרה שנייה שקובעת איזו תוכנית תרוץ במקום gpg עצמו.
וזה הלקח האמיתי. כשסוגרים מפתח הגדרה אחד נשארת מאחוריו משפחה שלמה של הגדרות git שמצביעות על תוכניות חיצוניות: hooks, מסננים, כלי diff חיצוניים. לכן ההמלצה של Manifold ליצרנים אינה לרדוף אחרי המפתחות אחד אחרי השני, אלא לנטרל אותם במפורש בכל קריאת git שהמוצר עושה ברקע.
מה זה אומר בפועל
אם הגיע אליכם מאגר כקבצים ולא בשכפול, הציצו בקובץ ההגדרות שבתיקיית ה-git שלו לפני שאתם פותחים את התיקייה עם סוכן. כל הגדרה שמצביעה על תוכנית עלולה להריץ אותה. זה נשמע טרחני, אבל מדובר בבדיקה של חצי דקה מול הרצת קוד בהרשאות שלכם.
מי שמריץ אחד מהכלים שכבר תוקנו פשוט יעדכן: goose ל-1.44.0 ומעלה, Claude Code ל-2.1.196 ומעלה, Codex CLI ל-0.131.0. מי שעובד עם Hermes Agent, Qwen Code או Grok Build צריך להניח בינתיים שהמסלול פתוח, ולהימנע מלפתוח איתם תיקיות שהגיעו מבחוץ עד שיצא תיקון. ולמי שבונה כלים כאלה בעצמו יש כאן משפט אחד לזכור: קריאה ל-git ברקע היא קוד שרץ על המכונה של המשתמש, גם כשהיא נראית כמו שורה תמימה של איסוף הקשר.
תגובות