כשסוכן ה-AI פונה פנימה: Loom ו-ToFu מראים שהשרת שלך הוא היעד המסוכן ביותר

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

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

מה פורסם

שלוש פגיעויות ב-Loom. ב-2 באוקטובר 2026 פרסמה AWS את הודעת האבטחה 2026-124-AWS על Loom, פלטפורמת קוד פתוח של AWS Labs לתזמור סוכני AI. AWS ממליצה לשדרג לגרסה 1.7.0 ולוודא שגם forks וקוד נגזר כוללים את התיקונים. לפי ההודעה:

• CVE-2026-103956 (עקיפת אימות זהות, CWE-306 ו-CWE-1188): בגרסאות שלפני 1.6.1, בפריסה ללא ספק זהויות מוגדר, כל לקוח ברשת יכול היה לקבל הרשאות ניהול מלאות על ה-control plane של הסוכנים. הרשאות אלה אפשרו לרשום שרתי כלים, לקרוא אישורי גישה שמורים של אינטגרציות ולשכתב מדיניות IAM המשויכת לתפקידי הסוכנים. הפגיעות תוקנה בגרסה 1.6.1, שפורסמה ב-4 באוגוסט 2026.
• CVE-2026-103957 (CWE-918 ו-CWE-201): בגרסאות שלפני 1.7.0, משתמש מאומת עם הרשאת mcp:write או a2a:write יכול היה להגדיר כתובת discovery של OAuth2. המסמך בכתובת הזו הורה לשרת לשלוח סודות לקוח של OAuth2, או טוקן גישה של משתמש אחר, לנקודת קצה בשליטת צד שלישי. לפי AWS, גרסה 1.6.1 חסמה במסלול הזה גישה לכתובות פנימיות, אך לא טיפלה במלואה בדליפת הטוקנים. התיקון המלא נכלל ב-1.7.0.
• CVE-2026-103958 (CWE-918): בגרסאות שלפני 1.7.0, משתמש עם אותן הרשאות יכול היה להפנות את החיבורים לשרתי כלים (MCP) ולסוכנים מרוחקים (A2A) לכל יעד ברשת הפנימית ולקרוא את התשובות. היעדים כללו גם את נקודת הקצה שמספקת אישורי גישה לקונטיינר.

מחקר על 273 שרתי MCP. ב-9 באוקטובר 2026 פרסמו חוקרים מ-Pennsylvania State University, מ-Université Montpellier ומ-Dartmouth College את המאמר על ToFu. הם בנו כלי fuzzing שמפיק בדיקות אבטחה מהתיאורים שהכלים עצמם מספקים למודל. הם הריצו אותו על 273 שרתי MCP בקוד פתוח, שכללו 3,405 כלים. לפי המאמר, נמצאו 253 באגים מאומתים ב-343 כלים ב-118 שרתים. בין הממצאים: 64 מקרים של path traversal, 7 של SSRF, 5 של הוצאת מידע ו-3 של הזרקת פקודות מערכת. הקבוצה הגדולה ביותר כללה 115 מקרים של פלט שמוחזר ללא escaping.

המאמר מתאר גם התקפה שהחוקרים מכנים Repeat-After-Me: המודל מתבקש לחזור על טקסט שנראה כמו קריאה לכלי. שכבת התזמור מפרשת את הפלט כקריאה אמיתית ומריצה אותה. לפי המאמר, ההתנהגות שוחזרה בשש שכבות תזמור: LangGraph,‏ MAF,‏ ADK 2.0,‏ AutoGen,‏ Strands ו-CrewAI. מסקנת החוקרים היא שאין לראות בארגומנט שהמודל יצר קלט מהימן, גם אם הוא תואם לסכמה של הכלי.

אותו מנגנון בשתי שכבות

ב-Loom, קוד התשתית של האורקסטרטור עצמו פתח חיבורים לכל כתובת שמסר המשתמש. זהו הקוד שמטפל ב-discovery של OAuth2 ובחיבור לשרתי כלים ולסוכנים מרוחקים. ב-ToFu אותו דפוס מופיע שכבה אחת למטה, בתוך הכלים. בניתוח המקרה שבמאמר, כלי לצילום מסך של דפי אינטרנט בודק רק שהקלט הוא URL תקין. לפי החוקרים, סוכן שהושפע מתוכן מוזרק יכול להשתמש בכלי הזה כדי לקרוא קבצים מהשרת ולצלם שירותים שמאזינים על loopback וברשת הפרטית. בשרת MCP אחר, המיועד ל-WordPress, הכלי פנה ללא הגבלה ל-URL של אתר שמסר הפונה. לפי המאמר, הבאג הזה נמצא בריצה שבה הופעלו כל הבדיקות. יומן הריצה מראה חיבור לכתובת ב-127.0.0.1.

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

מי שולט ב-URL

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

למה דווקא פנימה

מבחוץ, יעד פנימי נראה בטוח יותר מיעד באינטרנט. מנקודת המבט של התוקף, המצב הפוך. ביעדים הפנימיים עשויים להימצא שירותים שלא הוקשחו כי ״הם רק על localhost״, ה-control plane של הסוכנים עצמם ונקודות קצה שמספקות אישורי גישה. ב-CVE-2026-103958 התוקף לא רק מגיע לנקודת הקצה שמספקת אישורי גישה לקונטיינר, אלא גם קורא את התשובה. לכן, אם אישורי התפקיד של הקונטיינר נקראו, AWS ממליצה להחליף את אישורי ה-session של תפקיד ה-IAM ולבדוק ב-CloudTrail אם נעשה בהם שימוש לא צפוי. כך הנזק עובר מהשרת אל חשבון הענן.

גם בדיקות ה-SSRF שבנו החוקרים ל-ToFu מגדירות את היעדים האסורים באותה דרך: loopback, טווחי RFC 1918, כתובות link-local וכתובות metadata של הענן. לפי טבלת ההשפעה במאמר, באג SSRF הוא מצב שבו השרת מתחבר לכתובת שקבע התוקף, לרבות כתובות מהסוגים האלה. חיבור כזה מפר את הדרישה שבקשות השרת יגיעו רק ליעדים המיועדים להן.

למה תיקון ברמת הרכיב לא מספיק

יש לכך שלוש סיבות. הראשונה: התיקונים מגיעים בחלקים. ב-Loom, גרסה 1.6.1 חסמה כתובות פנימיות במסלול ה-discovery. בכל זאת נדרשה גרסה נוספת כדי לטפל במלואה בדליפת הטוקנים. השנייה: ToFu מצא 7 באגי SSRF בכלים שנבדקו. לפי המאמר, כלי סריקה שמחפשים בקוד רשימה קבועה של פעולות מסוכנות מחמיצים מאפיין כמו ״היעד מוגבל לרשימת היתר״. אין בקוד נקודה מסוימת שאפשר לחפש כדי לבדוק את המאפיין הזה. השלישית: לפי המאמר, רק 273 מתוך 1,404 מאגרים שחושפים כלים היו ניתנים להרצה בבדיקה. השאר לא נבנו, לא עלו או דרשו אישורי גישה. המספרים מתארים את מה שאפשר היה לבדוק, ולא את כלל המאגרים.

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

loopback אינו גבול מול תהליך מקומי

הצעד הזמני שעליו AWS ממליצה ל-CVE-2026-103956 הוא לוודא שספק זהויות מוגדר לפני שה-backend נגיש מעבר ל-loopback. קשירה ל-loopback מגינה מפני לקוחות ברשת, וזו בדיוק הבעיה בפגיעות הזו. אבל היא אינה מגינה מפני SSRF: סוכן שרץ על אותו מארח מגיע ל-127.0.0.1 בלי קושי. לכן צריך לטפל בשני הצדדים. ה-control planes צריכים להיות קשורים ל-loopback, ותהליכי הסוכנים צריכים להיות מוגבלים ליעדים שאישרת במפורש, ללא גישה אחרת ל-loopback של המארח.

צעדים מעשיים בשרת

אם אתה מריץ Loom:

• שדרג ל-1.7.0 ובדוק שגם ה-forks שלך כוללים את התיקונים.
• עד השדרוג: ודא שמאגר משתמשים של Cognito או ספק זהויות חיצוני מוגדר במלואו לפני שה-backend נגיש מעבר ל-loopback. ודא גם שהמשתנה LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV אינו מוגדר בשום סביבה פרוסה שאינה סביבת פיתוח מקומית. זו ההנחיה של AWS. בניגוד למה שנכתב בסיקור של GBHackers, היא אינה מוגבלת ל-production. נוסף על כך, הגבל את mcp:write ו-a2a:write למנהלים מהימנים. לפי AWS, הצעד הזה מקטין את הסיכון, אך אינו מבטל אותו ללא התיקון.
• אחרי השדרוג: החלף את סודות הלקוח של OAuth2 באינטגרציות MCP ו-A2A. בטל והנפק מחדש טוקנים שהיו פעילים בתקופה שבה המערכת הייתה פגיעה. אם אישורי התפקיד של הקונטיינר נקראו, החלף את אישורי ה-session ובדוק את CloudTrail.

לכל מערך סוכנים:

1. מפה אילו אורקסטרטורים, סוכנים ושרתי MCP רצים בשרת, ואילו מהם מקבלים URL, שם מארח או כתובת כקלט. לדוגמה: כלים לשליפת דפים ולצילום מסך, webhooks ו-discovery.
2. קשור control planes, ממשקי ניהול ומסדי נתונים ל-127.0.0.1. בדוק את המצב בפועל, ולא רק את קובץ ההגדרות.
3. הרץ כל סוכן תחת משתמש משלו, ב-network namespace נפרד או בקונטיינר נפרד, כך שה-loopback שלו אינו ה-loopback של המארח, וכללי חומת האש יוכלו לזהות את התעבורה שלו.
4. עבור התהליכים האלה, חסום כברירת מחדל את ה-loopback של המארח, כתובות link-local (‏169.254.0.0/16 ו-fe80::/10), טווחי RFC 1918 (‏10.0.0.0/8, ‏172.16.0.0/12 ו-192.168.0.0/16) וכתובות IPv6 פרטיות (fc00::/7). אפשר גישה רק ליעדים פנימיים שהסוכן אכן צריך, כל יעד בנפרד.
5. אל תסתפק בחסימה ללא רישום: רשום ביומן כל ניסיון של תהליך סוכן להגיע לכתובת metadata או לנקודת קצה שמספקת אישורי גישה. ניסיון כזה הוא ממצא שמצדיק בדיקה.
6. צמצם את ההרשאות של תפקיד הענן שמשויך לסוכן. אם אישורי גישה ידלפו, ההרשאות האלה יקבעו את היקף הנזק.
7. בדוק שרתי MCP חדשים בסביבה מבודדת. לפי המאמר, ארבעה שרתים השפיעו על המארח במהלך הבדיקות: הם מחקו קבצים מחוץ לסביבת העבודה, ניגשו לנתיב מחוץ לתיקייה המיועדת, סגרו סשנים של טרמינל שלא היו שלהם והפעילו תהליכים ללא הגבלה. החוקרים מציינים שהמקרים האלה הם סיבה נוספת להריץ בדיקות כאלה בארגז חול.

איך nuDefend עוזר

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

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

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

הפקודה nudefend expose מציגה כל שירות שמאזין בשרת ומי יכול להגיע אליו, מנקודת המבט של השרת עצמו. שירות שקשור ל-127.0.0.1 או ל-::1 מסומן כ-local-only. אם שירות שהיה פנימי בלבד נעשה נגיש מבחוץ, nuDefend מזהה את השינוי ומתריע עליו. אם שירות חשוף שלא במכוון, אפשר לחסום את הפורט שלו מלוח הבקרה או משורת הפקודה, לאחר תצוגה מקדימה שמראה בדיוק מה ייחסם. פרטים נוספים נמצאים בעמוד על התעבורה היוצאת ובעמוד על החשיפה.

השורה התחתונה

הפגיעויות ב-Loom והממצאים של ToFu מתארים אותה בעיה בשתי שכבות: רכיב במערך הסוכנים מקבל כתובת ממי שאינו המנהל ופותח אליה חיבור מתוך השרת. לעיתים קרובות היעד הוא השרת עצמו, הרשת הפרטית או נקודת קצה שמספקת אישורי גישה. שדרג את Loom ל-1.7.0 וטפל באישורי הגישה לפי הנחיות AWS. מעבר לכך, אל תחכה שכל מחבר כלי יתקן את הטיפול ב-URL. קשור control planes ל-loopback, הפרד כל סוכן ברמת הרשת וחסום כברירת מחדל גישה של תהליכי הסוכנים ליעדים פנימיים. התייחס לכל פנייה שלהם לכתובת metadata כאל אירוע שמצריך בדיקה.