כיצד פועלת המתקפה

החוקרים תיארו דפוס עבודה פגיע ב-GitHub Agentic Workflow כדלהלן:

• מופעל בעת אירועי issues.assigned
• קורא את כותרת ה-Issue וגופו
• מפרסם תגובה באמצעות כלי סוכן, כגון add-comment
• פועל עם הרשאות קריאה למאגרים אחרים בארגון, לרבות מאגרים פרטיים

המתקפה מתבצעת בארבעה שלבים:

1. התוקף פותח GitHub Issue תמים לכאורה במאגר ציבורי השייך לארגון המשתמש בדפוס העבודה הפגיע.
2. בתוך גוף ה-Issue מוסתרות הוראות בשפה פשוטה המורות לסוכן הבינה המלאכותית לשלוף קבצים ממאגרים פרטיים.
3. כאשר האוטומציה של GitHub מקצה את ה-Issue, הזרימה המופעלת על ידי האירוע גורמת לסוכן להביא נתונים ממאגרים שאליהם יש לו גישה – כולל מאגרים פרטיים.
4. הסוכן מפרסם את הנתונים שנשלפו כתגובה ציבורית על ה-Issue, וחושף את המידע לכל מי שיכול לצפות בו.

החולשה הארכיטקטונית הבסיסית

הפגם המרכזי הוא כשל בשמירה על גבול אמון קפדני בין הוראות מערכת לנתוני משתמש לא מהימנים בחלון ההקשר (context window) של סוכן הבינה המלאכותית. כפי שאמר סאסי לוי מ-Noma: "חלון ההקשר של הסוכן הוא גם משטח ההתקפה שלו. כל תוכן שהסוכן קורא – בין אם זה Issues, Pull Requests, תגובות או קבצים – יכול להפוך לנשק אם הסוכן מתייחס לתוכן הזה כאל קלט הוראה."

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

החוקרים סיווגו סוג זה של פגם באופן רשמי כ-Agentic Workflow Injection (AWI), וזיהו שני דפוסים מרכזיים: Prompt-to-Agent (P2A), שבו תוכן לא מהימן מגיע לגבול ההנחיה של הסוכן, ו-Prompt-to-Script (P2S), שבו השפעת התוקף מתפשטת דרך פלטים שמקורם במודל אל סקריפטים מאוחרים יותר.

טכניקת עקיפת ההגנה: מילת המפתח "Additionally"

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

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

המלצות הגנה לארגונים

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

• אימוץ אפס אמון (Zero Trust) לתשומות סוכן – לעולם אל תתייחסו לתוכן הנשלט על ידי המשתמש כקלט הוראה מהימן, ובודדו נתוני משתמש לא מהימנים מהנחיות המערכת הליבה.
• החלת הרשאות עקרון ההרשאה המצומצמת (Least Privilege) – הסירו גישה מיותרת בין-מאגרית, והגבילו את יכולתם של סוכנים לחשוף נתונים דרך פלטים ציבוריים.
• שימוש ברשימות היתר (Allowlists) לכלים במקום ברשימות חסימה, ודרשו שערי אישור אנושיים לפני שסוכנים מבצעים פעולות רגישות, כגון פרסום תגובות חיצוניות או גישה למאגרים רגישים.
• ביקורת על אינטגרציות של סוכני AI בזרימות CI/CD ובאוטומציה של מאגרים, במיוחד כאשר הקשר אירועי GitHub לא מהימן משולב בהנחיות או בתשומות הסוכן.
• בידוד לוגי של קלט משתמש לא מהימן מהוראות מערכת, תוך התייחסות לטקסט שנוצר על ידי משתמשים כנתון לא מהימן ולא כהוראה סמכותית.

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

תגובת GitHub (נכון ל-7 ביולי)

על פי Dark Reading ולוח הזמנים של Noma Security:

• Noma דיווחה על הפגם ל-GitHub במסגרת חשיפה אחראית.
• GitHub מסרה ל-Noma כי עדכנה את התיעוד הקשור לדפוס העבודה הפגיע, והחוקרים דיווחו שהתצורה הפגיעה אינה קיימת עוד בבדיקתם האחרונה.
• נכון ל-7 ביולי, GitHub לא פרסמה הודעה רשמית או CVE עבור GitLost.
• נראה שהפגיעות טופלה חלקית באמצעות הסרה או עדכון של התיעוד ותבנית העבודה שאפשרו זאת, ולא באמצעות תיקון אבטחה ברור ברמת הפלטפורמה.

התמונה הרחבה: סיכון מערכתי

GitLost אינה אירוע מבודד. היא מייצגת סוג הולך וגדל של פגיעויות שבהן סוכני AI בעלי גישה לנתונים רגישים נחשפים לתוכן משתמש לא מהימן. בעיות דומות השפיעו על אינטגרציות GitHub MCP, זרימות העבודה של Gemini CLI של גוגל (פגיעות TrustIssues) ושל Claude Code GitHub Actions. המכנה המשותף הוא שסוכנים מבוססי LLM חסרים יכולת טבועה להבחין בין נתונים להוראות כאשר שניהם מופיעים באותו חלון הקשר – אתגר ארכיטקטוני יסודי שאף תיקון פלטפורמה יחיד לא יכול לפתור לחלוטין.

כיצד פועלת המתקפה

החוקרים תיארו דפוס עבודה פגיע ב-GitHub Agentic Workflow כדלהלן:

• מופעל בעת אירועי issues.assigned
• קורא את כותרת ה-Issue וגופו
• מפרסם תגובה באמצעות כלי סוכן, כגון add-comment
• פועל עם הרשאות קריאה למאגרים אחרים בארגון, לרבות מאגרים פרטיים

המתקפה מתבצעת בארבעה שלבים:

1. התוקף פותח GitHub Issue תמים לכאורה במאגר ציבורי השייך לארגון המשתמש בדפוס העבודה הפגיע.
2. בתוך גוף ה-Issue מוסתרות הוראות בשפה פשוטה המורות לסוכן הבינה המלאכותית לשלוף קבצים ממאגרים פרטיים.
3. כאשר האוטומציה של GitHub מקצה את ה-Issue, הזרימה המופעלת על ידי האירוע גורמת לסוכן להביא נתונים ממאגרים שאליהם יש לו גישה – כולל מאגרים פרטיים.
4. הסוכן מפרסם את הנתונים שנשלפו כתגובה ציבורית על ה-Issue, וחושף את המידע לכל מי שיכול לצפות בו.

החולשה הארכיטקטונית הבסיסית

הפגם המרכזי הוא כשל בשמירה על גבול אמון קפדני בין הוראות מערכת לנתוני משתמש לא מהימנים בחלון ההקשר (context window) של סוכן הבינה המלאכותית. כפי שאמר סאסי לוי מ-Noma: "חלון ההקשר של הסוכן הוא גם משטח ההתקפה שלו. כל תוכן שהסוכן קורא – בין אם זה Issues, Pull Requests, תגובות או קבצים – יכול להפוך לנשק אם הסוכן מתייחס לתוכן הזה כאל קלט הוראה."

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

החוקרים סיווגו סוג זה של פגם באופן רשמי כ-Agentic Workflow Injection (AWI), וזיהו שני דפוסים מרכזיים: Prompt-to-Agent (P2A), שבו תוכן לא מהימן מגיע לגבול ההנחיה של הסוכן, ו-Prompt-to-Script (P2S), שבו השפעת התוקף מתפשטת דרך פלטים שמקורם במודל אל סקריפטים מאוחרים יותר.

טכניקת עקיפת ההגנה: מילת המפתח "Additionally"

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

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

המלצות הגנה לארגונים

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

• אימוץ אפס אמון (Zero Trust) לתשומות סוכן – לעולם אל תתייחסו לתוכן הנשלט על ידי המשתמש כקלט הוראה מהימן, ובודדו נתוני משתמש לא מהימנים מהנחיות המערכת הליבה.
• החלת הרשאות עקרון ההרשאה המצומצמת (Least Privilege) – הסירו גישה מיותרת בין-מאגרית, והגבילו את יכולתם של סוכנים לחשוף נתונים דרך פלטים ציבוריים.
• שימוש ברשימות היתר (Allowlists) לכלים במקום ברשימות חסימה, ודרשו שערי אישור אנושיים לפני שסוכנים מבצעים פעולות רגישות, כגון פרסום תגובות חיצוניות או גישה למאגרים רגישים.
• ביקורת על אינטגרציות של סוכני AI בזרימות CI/CD ובאוטומציה של מאגרים, במיוחד כאשר הקשר אירועי GitHub לא מהימן משולב בהנחיות או בתשומות הסוכן.
• בידוד לוגי של קלט משתמש לא מהימן מהוראות מערכת, תוך התייחסות לטקסט שנוצר על ידי משתמשים כנתון לא מהימן ולא כהוראה סמכותית.

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

תגובת GitHub (נכון ל-7 ביולי)

על פי Dark Reading ולוח הזמנים של Noma Security:

• Noma דיווחה על הפגם ל-GitHub במסגרת חשיפה אחראית.
• GitHub מסרה ל-Noma כי עדכנה את התיעוד הקשור לדפוס העבודה הפגיע, והחוקרים דיווחו שהתצורה הפגיעה אינה קיימת עוד בבדיקתם האחרונה.
• נכון ל-7 ביולי, GitHub לא פרסמה הודעה רשמית או CVE עבור GitLost.
• נראה שהפגיעות טופלה חלקית באמצעות הסרה או עדכון של התיעוד ותבנית העבודה שאפשרו זאת, ולא באמצעות תיקון אבטחה ברור ברמת הפלטפורמה.

התמונה הרחבה: סיכון מערכתי

GitLost אינה אירוע מבודד. היא מייצגת סוג הולך וגדל של פגיעויות שבהן סוכני AI בעלי גישה לנתונים רגישים נחשפים לתוכן משתמש לא מהימן. בעיות דומות השפיעו על אינטגרציות GitHub MCP, זרימות העבודה של Gemini CLI של גוגל (פגיעות TrustIssues) ושל Claude Code GitHub Actions. המכנה המשותף הוא שסוכנים מבוססי LLM חסרים יכולת טבועה להבחין בין נתונים להוראות כאשר שניהם מופיעים באותו חלון הקשר – אתגר ארכיטקטוני יסודי שאף תיקון פלטפורמה יחיד לא יכול לפתור לחלוטין.