Plugin4Shell: ארבעה סוכני קידוד AI סמכו על PIN שמעולם לא בדקו

ב-17 בספטמבר 2026, AIR Security, סטארט-אפ שבונה כלי אבטחה לסוכני AI ארגוניים, פרסמה מחקר המתאר את Plugin4Shell — פגיעות הרצת קוד מרחוק ללא לחיצה בארבעה סוכני קידוד AI: Claude Code של Anthropic, Codex של OpenAI, GitHub Copilot ו-Gemini CLI של Google. הבאג אינו באף מודל. הוא נמצא בפעולת ה-checkout של git שכל סוכן מבצע כשהוא מתקין תוסף, ובכך שאף אחד מהארבעה לא וידא שהקוד שקיבל הוא הקוד שנעל. לשניים מהארבעה היה תיקון עד למועד פרסום המחקר. לשניים לא. התקרית הזו היא רשומה אחת בOrca AI Incident Archive, אשר מתעד אותה כפגיעות שרשרת אספקה בדרגת חומרה גבוהה ללא דיווח על ניצול.

מה הסוכנים בעצם עשו לא נכון

כל סוכן מושפע מתקין תוספים ממרקטפלייס, וכל מרקטפלייס מצמיד תוסף ל-commit מסוים ב-git — SHA בן 40 תווים — לאחר שהתוסף נבדק. ההצמדה הזו היא כל מודל האבטחה: מבקר מאשר גרסה בלתי משתנה אחת, והסוכן אמור להמשיך להריץ את אותה גרסה גם אם המאגר שמאחוריה משתנה מאוחר יותר. AIR מתאר את הפגם כעקיפת הצמדת SHA של תוסף. הסוכן מבצע checkout ל-commit המדויק שהמרקטפלייס הצמיד, אך לעולם אינו מאמת שעץ העבודה שאליו הוא מגיע הוא אותו commit. בלשונם של החוקרים, הסוכן "מבצע checkout ל-commit המדויק שהמרקטפלייס הצמיד, אך לעולם אינו מאמת שהוא אכן הגיע לשם, כך שתוקף ששולט במאגר של התוסף גורם לכך�ה-checkout יתמפה לקוד זדוני בעוד שההצמדה עדיין נראית כנשמרת."

Git מספק את הפער. כאשר שם הוא גם ענף חוקי וגם אובייקט קומיט, Git מעדיף את הענף ומדפיס רק אזהרת אי-בהירות. תוקף ששולט במאגר של התוסף יוצר ענף ששמו הוא בדיוק ה-SHA המקובע בן 40 התווים ההקסדצימליים, מפנה אותו לקוד זדוני, והופך אותו לענף ברירת המחדל של המאגר. שיבוט רגיל אז מוריד את הענף הזה מקומית תחת השם בצורת SHA, וה-checkout שלאחר מכן נפתר אליו. הקומיט המקובע עצמו יכול להישאר ללא שינוי, כך ששום דבר בגרסה שנבדקה לא נראה שגוי. לפי AIR, שני תנאים חייבים להתקיים: הענף ששמו כשם ה-SHA חייב להיות ענף ברירת המחדל, משום שענף שאינו ברירת מחדל נמשך רק כהפניה למעקב מרוחק וה-checkout היה נופל חזרה לקומיט האמיתי; ושמארח Git חייב לקבל שם ענף בן 40 תווים הקסדצימליים. GitHub דוחה שמות כאלה לחלוטין. Bitbucket ושרתי Git באירוח עצמי לא.

Gemini CLI נכשל בדרך אחרת. הוא משך את ה-commit המקובע, רשם אותו בקובץ FETCH_HEAD של המאגר, ואז הריץ checkout של FETCH_HEAD — checkout שלא חייב לקרוא את הקובץ הזה. מאגר שענף ברירת המחדל שלו עצמו נקרא FETCH_HEAD מפנה את ה-checkout לתוכן בשליטת תוקף ומשליך בשקט את ה-commit שנמשך. התיאור של Cybersecurity News את המנגנון תואם לזה של AIR, כולל ההבחנה בין שני הווריאנטים.

למה אף אחד לא היה צריך ללחוץ על שום דבר

אותו checkout רץ שוב במהלך עדכון אוטומטי של תוספים ברקע, וזהו ברירת המחדל ב-Claude Code וב-Codex. זה מה שהופך את המתקפה לאפס-קליק ולא רק לשקטה: כשמרקטפלייס מעלה SHA מוצמד לגרסה חדרה שגרתית, כל סוכן שכבר מותקן אצלו התוסף מריץ שוב את ה-checkout בלי שום בקשה ובלי שום פעולה של המשתמש. הנקודה של AIR היא שהקורבן לא צריך להתקין משהו ברשלנות. הוא צריך להתקין תוסף אחד, ממרקטפלייס שהוא סומך עליו, שנבדק והוצמד בדיוק כפי שהתכנון מתכוון.

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

המספרים שמאחורי שני המסלולים האלה מגיעים מעבודתה הקודמת של AIR, ולא מ-Plugin4Shell. בקמפיין שהחברה מכנה The Story of Skills, היא אומרת שתוסף שהיא בנתה התפשט ליותר מ-26,000 סוכנים לפני שהוסר. ב-SkillJacking, היא דיווחה ש-925 כישורים שכבר היו בשימוש פעיל הושתלטו מידי המתחזקים המקוריים שלהם, והגיעו ל-134,000 סוכנים. הכותרת של AIR לפוסט על Plugin4Shell טוענת ש"מיליוני סוכנים נפגעו"; המחקר לא נותן מספר של התקנות חשופות, ואף צד שלישי לא פרסם כזה.

לוח הזמנים, והיכן נחתו התיקונים

AIR אומרת שהיא מצאה את הפגם במאי 2026 עם ניצולי הוכחת היתכנות פעילים נגד כל ארבעת הסוכנים, וחשפה אותו בפני כל ספק בחודש שלאחר מכן במסגרת חשיפה מתואמת. Anthropic אישרה את התיקון שלה ב-Claude Code 2.1.179 ב-17 ביוני. Google אמרה ל-AIR ב-4 באוגוסט שלא יופץ תיקון, משום ש-Gemini CLI מוצאת משימוש. Codex 0.146.0 אומת כמתוקן ב-12 באוגוסט. Microsoft לא הפיצה תיקון עבור GitHub Copilot.

גרסאות התיקון הן האישור הפומבי היחיד לכך שהפגם היה אמיתי בשני המוצרים שתיקנו אותו. הרשומה שפרסמה Anthropic ביומן השינויים עבור 2.1.179 מפרטת טיפול בניתוקי חיבורים, גלילה ב-WSL2, ותיקוני glob וממשק ב-sandbox, ואינה מזכירה נעיצת גרסאות, אימות תוספים או תיקון אבטחה מכל סוג שהוא. The Hacker News הגיע לאותה תצפית, לפי הדיווח של The Next Web. נכון למועד פרסום המחקר, לא הוקצה מזהה CVE, והערת המחקר של Cloud Security Alliance על הפגם חוזרת על כך שלא היה מזהה שלושה חודשים לאחר שהספקים קיבלו הודעה.

ארבעה ספקים, שלוש תשובות שונות

גוגל הלכה רחוק יותר מאשר לסרב לתקן. היא הוציאה מכלל שימוש את Gemini CLI, מה שאומר שהתקנות קיימות יישארו חשופות כל עוד אנשים ימשיכו להריץ אותן. העצה שלה היא לעבור ל-Antigravity, סביבת הפיתוח האג'נטית החדשה יותר, שלדברי AIR המתקפה אינה מגיעה אליה משום שאין בה מנגנון SHA pinning לתוספי מרקטפלייס שניתן לעקוף.

עמדת GitHub שונה שוב. דובר GitHub אמר ל-The Register שהפלטפורמה אינה מאפשרת למשתמשים ליצור שמות של ענפים או תגים שדומים ל-SHA-ים של קומיטים, ושה"מיטיגציה הזו מבטיחה שלא ניתן לנצל ב-GitHub את הפגיעות שדווחה". AIR חולקת על היקף המיטיגציה הזו ולא על קיומה: לדברי החוקרים, ניתן לארח מרקטפלייסים בפלטפורמות אחרות כגון Bitbucket, ו-GitHub Copilot עדיין תומך במרקטפלייסים מאותן פלטפורמות, ולכן הווריאנט של שם הענף נותר נגיש למשתמשי Copilot. AIR אומרת גם שהתיעוד של Anthropic עצמה מפרט את Bitbucket ו-git באירוח עצמי כבקאנדים תקפים למרקטפלייס; התיעוד הנוכחי של Anthropic בנושא מרקטפלייסים מתאר הוספת מרקטפלייס מכתובת URL של מאגר git, ולא רק מ-GitHub. Microsoft לא הגיבה לבקשת התגובה של The Register, ו-AIR אמרה שלא קיבלה תגובה מ-Microsoft מאז שדיווחה על הבעיה ביוני, בנימוק של היקף החשיפות שהחברה מטפלת בהן.

זו מחלוקת לגבי רוחב החשיפה, לא לגבי השאלה אם הבאג קיים. ההקלה של GitHub היא הגבלה ברמת המארח; הממצא של AIR הוא שהבדיקה חייבת להתבצע בתוך הסוכן, משום שה-pin נפתר בצד הלקוח.

מה מבוסס, ומה לא

• נקבע: המנגנון. המאמר של AIR מפרט את פקודות ה-git המדויקות, את כלל ההכרעה בין ref לאובייקט, את שני התנאים שהטריק של הענף מצריך, ואת וריאנט ה-FETCH_HEAD הנפרד עבור Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld ו-The Next Web מדווחים על כך באותו אופן.

• נקבע: שתי גרסאות מתוקנות. Anthropic אישרה את Claude Code 2.1.179 ב-17 ביוני 2026, ו-Codex 0.146.0 של OpenAI אומת כמתוקן ב-12 באוגוסט 2026, לפי ציר הזמן לחשיפת AIR.

• נקבע: שני מוצרים לא היו מתוקנים בעת החשיפה. Google לא תתקן את Gemini CLI ומוציאה אותו לגמלאות; Microsoft טרם שחררה תיקון ל-Copilot.

• לא הוכח: שחזור עצמאי. כל תיאור שפורסם מתחקה אחרי פוסט הבלוג של AIR עצמה, והערת המחקר של Cloud Security Alliance אינה מתארת במפורש אימות טכני של צד שלישי או שחזור עצמאי של הניצול. הארכיון מדרג את רמת הביטחון של רשומה זו ב-B מסיבה זו.

• לא נקבע: כמה התקנות היו חשופות בפועל. "מיליונים" הוא תיאור של AIR בכותרת, לא נתון מדוד.

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

• לא הוכח: כל שימוש בעולם האמיתי. אף מקור בתיעוד אינו מדווח על ניצול, בדיקה או תשתית תוקפים, והארכיון רושם נזק אמיתי כאי־אמת. זהו היעדר דיווח, לא ראיה לכך שדבר לא קרה.

בדיקת צד שלישי אחת אכן מצמצמת את התמונה המעשית. The Next Web, בסיכום בדיקות של The Hacker News, מדווח שתוספים בקטלוג הקהילתי של Anthropic ובקטלוגים המוגדרים כברירת מחדל של Claude Code ו-Copilot מפנים למאגרי GitHub, ושעדכון אוטומטי מופעל כברירת מחדל בעיקר עבור אותם מרקטפלייסים מובנים. מכיוון ש-GitHub מסרב לשמות ענפים בצורת SHA, הווריאנט של שם הענף קשה יותר להשגה עבור משתמשים שנשארים בקטלוגי ברירת המחדל. ההיגיון הזה אינו מכסה את וריאנט ה-FETCH_HEAD של Gemini CLI, שאינו תלוי באופן שבו המארח נותן שמות לענפים.

איך צריך להיראות תיקון

התיקון המומלץ של AIR הוא בדיקה אחת: לאחר ה-checkout, לזהות את ה-commit שנמצא בפועל ב-working tree ולבטל אלא אם הוא שווה ל-SHA הנעוץ. החוקרים מדגישים שעליה לבדוק את ה-HEAD שנפתר ולא את ה-ref שהתבקש, משום שההבחנה הזו היא בדיוק מה שמאפשר לווריאנט של Gemini CLI לחמוק, ושעליה לרוץ בתוך הסוכן, כי ה-pin נפתר בצד הלקוח ואף marketplace לא יכול לאכוף את ההבטחה שהוא מפרסם.

עצות מעשיות לצוותים שמפעילים את הסוכנים הללו, מתוך AIR, Cybersecurity News והפרשנות האנליטית ב-InfoWorld:

• עדכנו את Claude Code לגרסה 2.1.179 או מאוחר יותר ואת Codex לגרסה 0.146.0 או מאוחר יותר. עדכון הוא ההקלה השלמה היחידה במקום שבו קיים תיקון.

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

• עברו מ-Gemini CLI במקום להמתין לתיקון שגוגל הצהירה שלא יגיע.

• בדוק את מלאי התוספים והגבל מקורות מרקטפלייס ככל האפשר. AIR מציין שמרקטפלייס יכול להקהות את וריאנט שם הענף בכך שהוא מאפשר רק מארחים שדוחים שמות בצורת SHA — למעשה רק GitHub — אך שהדבר חוסם מארחים שהסוכנים תומכים בהם רשמית ואינו עושה דבר עבור וריאנט Gemini.

• התייחסו לתחנת העבודה כאל גבול החשיפה. תוספים יורשים את ההרשאות של הסוכן, ולכן ניצול מוצלח מגיע לקוד מקור, למפתחות SSH, לאישורי ענן, לאסימוני CI/CD ולמאגרים פנימיים בסמכותו של המפתח עצמו. פאריכ ג'יין, אנליסט ראשי ב-Pareekh Consulting, אמר ל-InfoWorld שצוותי אבטחה צריכים לבחון יומני EDR, git, CI/CD, cloud IAM ואימות לאיתור תהליכים חריגים, קובצי תוספים בלתי צפויים, מאגרים ששונו ופעילות git חשודה — והוסיף שצעדים אלה מפחיתים את הסיכון בלי לתקן את הפגם הבסיסי, שאותו הוא מייחס לקוד הספק. "ארגונים יכולים להטיל בקרות על השימוש בתוספים," אמר ל-InfoWorld, "אבל הם לא יכולים לתקן פגם באופן שבו סוכן הקידוד מאמת את הקוד שהוא בודק."

מדוע באג נעיצה הוא זה שהיה חשוב

נעיצת SHA הייתה התשובה של התעשייה בדיוק לסוג ההשתלטות ש-AIR כבר הדגימה: אם מאגר ציבורי נפרץ, הסוכן ממשיך להריץ את ה-hash שנבדק במקום למשוך כל מה שהתוקף דחף. Plugin4Shell לא שובר את ה-hash. הוא מראה שהסוכנים פענחו את הנעיצה לשם ענף שרק נראה כמו ה-hash, ומעולם לא השוו את התוצאה. כל מה שבמורד הזרם של ההנחה הזו — תהליכי סקירה, רשימות היתר פנימיות, הביטחון שמפתחים נותנים בגרסה נעוצה — יורש את הכשל.

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