מכת המוות לשערי AI: פגיעות שרשרת CVSS 10.0 ב-LiteLLM

שתי נקודות הקצה מקבלות במסגרת בקשת ה-JSON תצורת שרת MCP מלאה, הכוללת את השדות Cmd, args ו-env, שמנגנון ה-stdio transport משתמש בהם כדי להריץ תהליכי שרת . כאשר משתמש מאומת קורא לאחת מנקודות הקצה עם תצורה זו, LiteLLM לוקח את ערך ה-Cmd שסופק ומריץ אותו כתת-תהליך על המכונה המארחת, עם אותן הרשאות מערכת הפעלה שיש לתהליך פרוקסי ה-LiteLLM עצמו .

במקור, BerriAI חשפה זאת כבאג ביצוע קוד מרחוק מאומת – תוקף נזקק למפתח API תקף כדי להגיע לנקודות הקצה, ולא הייתה בקרת הרשאות מבוססת תפקידים (role) שהגבילה מי יכול לקרוא להן. אפילו משתמש פנימי עם הרשאות נמוכות, המחזיק בכל מפתח API תקף לפרוקסי, יכול היה להריץ פקודות שרירותיות על המארח . אבל הסיפור לא נגמר כאן.

מעקף ה-BadHost ב-Starlette שמסיר את דרישת האימות

הפגיעות השנייה היא CVE-2026-48710, שזכתה לכינוי "BadHost" על ידי חוקרים. זוהי חולשת אימות של כותרת Host (Host Header) ב-Starlette, מסגרת העבודה הקלה ASGI שעליה מבוססים FastAPI, vLLM, ועוד אלפי יישומי ווב בפייתון – כולל LiteLLM . כל גרסאות Starlette מ-0.8.3 ועד 1.0.0 מושפעות .

שורש הבעיה הוא אי-הסכמה בפענוח (parser disagreement) בין האופן שבו Starlette מנתבת בקשות נכנסות לבין האופן שבו היא משחזרת את ה-URL עבור לוגיקת היישום . שכבת ניתוב ה-ASGI משתמשת בנתיב ה-HTTP הגולמי מהבקשה כדי להחליט איזו נקודת קצה מטפלת בה. אך request.url – ה-URL שמידלוור ודקורטורי האפליקציה רואים – נבנה מחדש על ידי שרשור ערך כותרת ה-Host הגולמי עם נתיב הבקשה, וזאת ללא ולידציה נאותה .

על ידי הזרקת תווי הפרדה בין סמכות ה-URI לנתיב (URI authority-to-path delimiters), כגון ? או #, לתוך כותרת ה-Host, תוקף יכול לגרום לכך ש-request.url.path ייראה שונה לחלוטין מנתיב הבקשה המנותב בפועל . מידלוור האימות רואה נתיב תמים כמו /, בעוד מאחורי הקלעים, הנתב מעביר את הבקשה לנקודת הקצה האמיתית שהיא היעד. כל מידלוור אימות מבוסס-נתיב שסומך על request.url.path ניתן לעקיפה באופן טריוויאלי .

הרכבת השרשרת: מ-8.7 ל-10.0

דקורטור האימות של LiteLLM בודק את request.url.path כדי לקבוע האם בקשה זקוקה למפתח API תקף. מעקף ה-BadHost מאפשר לתוקף לתמרן את ה-URL הזה כך שמידלוור האימות יראה נתיב שאינו דורש אימות, בעוד נתב ה-ASGI שולח את הבקשה במקביל לאחת מנקודות הקצה הפגיעות להזרקת הפקודות ב-MCP .

פעולה זו מסירה את שער בקרת הגישה היחיד שעמד בין האינטרנט לבין הרצת פקודות שרירותית. תוקף ללא אישורי גישה וללא שום גישה קודמת לרשת יכול לשלוח בקשת HTTP יחידה ומתוכננת בקפידה, שעוקפת לחלוטין את האימות ומריצה פקודות מערכת הפעלה על מארח פרוקסי ה-LiteLLM . Horizon3.ai אישרו ששרשרת הניצול המלאה עובדת, והעניקו לה ציון CVSS משולב של 10.0 – רמת החומרה המקסימלית – מכיוון שהיא משיגה ביצוע קוד מרחוק ללא אימות כלל .

מה יכולים תוקפים לעשות עם גישה כזו?

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

• הרצת פקודות שרירותית: תוקפים יכולים להתקין דלתות אחוריות, נוזקות, כורי מטבעות קריפטוגרפיים, או כל תוכנה אחרת שהרשאות תהליך המארח מאפשרות .
• גניבת אישורי גישה בקנה מידה רחב: פרוקסי ה-LiteLLM יושב בין יישומים לעשרות ספקי LLM. הוא מאחסן מפתחות API עבור OpenAI, Anthropic, Azure, AWS Bedrock, גוגל ושירותים מחוברים אחרים בבסיס הנתונים או במשתני הסביבה שלו . ניצול הפגיעות מאפשר לתוקפים לחלץ (exfiltrate) כל אישור גישה שמור בפעולה אחת.
• תנועה צידית דרך תשתיות AI: עם מפתחות API ענן גנובים וגישת מעטפת (shell) למארח הפרוקסי, תוקפים יכולים לנוע לשירותים מחוברים, שרתי MCP פנימיים, מסדי נתונים וקטוריים (Vector Databases) וסביבות עבודה של סוכני AI במורד הזרם .
• השלכות רחבות יותר על המערכת האקולוגית: חולשת ה-BadHost ב-Starlette משפיעה על למעלה מ-400,000 פרויקטים תלויים, כולל יישומי FastAPI, שרתי vLLM, פריסות שרת MCP ותשתיות סוכני AI. כל אחד מאלה המשתמש במידלוור אימות מבוסס-נתיב על גרסאות Starlette מתחת ל-1.0.1 חשוף באופן דומה לעקיפת אימות .

מדוע הצעד של CISA מעלה את רמת הדחיפות

הוספת CVE-2026-42271 לקטלוג KEV של CISA ב-8 ביוני 2026 מאשרת שהפגיעות אינה תיאורטית – תוקפים מחמשים אותה בפועל ממש עכשיו . תחת 'הנחיית התפעול המחייבת 22-01', כל הסוכנויות הפדרליות האמריקאיות בזרוע המבצעת האזרחית חייבות להתקין טלאים לפגיעויות הרשומות ב-KEV בתוך לוח זמנים מוגדר לתיקון. CISA גם ממליצה בחום לכל הארגונים, ציבוריים ופרטיים, להתייחס לתוספות ל-KEV כאל סדרי עדיפויות חירום לתיקון .

צעדי תיקון מיידיים

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

1. שדרגו את LiteLLM לגרסה 1.83.7 ומעלה. שחרור זה מסיר את היכולת של נקודות הקצה לבדיקת MCP להריץ פקודות שסופקו על ידי המשתמש ישירות, וסוגר את וקטור הזרקת הפקודות לחלוטין .
2. שדרגו את Starlette לגרסה 1.0.1 ומעלה. הטלאי מבצע ולידציה לכותרות Host נכנסות מול מפרט ה-URL ומתעלם מכותרות המכילות תווים לא חוקיים, ובכך מונע את טריק בלבול הנתיבים שמאפשר את עקיפת האימות .
3. החליפו כל אישור גישה שמור מיידית. הניחו שכל מפתח API, אסימון גישה (Access Token), או אישור גישה למסד נתונים שפרוקסי ה-LiteLLM אי פעם אחסן – נחשף. החליפו (Rotate) את כל מפתחות OpenAI, Anthropic, Azure, AWS וספקים אחרים, ובדקו לוחות מחוונים לחיובים על שימוש לא מורשה .
4. חסמו את נקודות הקצה בפרוקסי ההפוך (Reverse Proxy) או ב-WAF. כאמצעי הגנה לעומק בזמן שהטלאים מופצים, הגדירו את החומה או הפרוקסי ההפוך שלכם לחסום כל בקשה ל-

   POST /mcp-rest/test/connection

   ול-

   POST /mcp-rest/test/tools/list

   לפני שהן מגיעות ליישום .
5. בצעו ביקורת רטרוספקטיבית לגישה לא מורשית. בדקו יומני פרוקסי LiteLLM לאיתור פעילות חריגה בנקודות הקצה של בדיקת MCP, במיוחד בקשות מכתובות IP לא צפויות או כאלו עם כותרות Host שעברו מניפולציה .

דירוג החומרה CVSS 10.0 המשולב, הניצול הפעיל בשטח, והתיוג של CISA בקטלוג KEV – כל אלה מחייבים ארגונים המפעילים שירותים מבוססי LiteLLM או Starlette להתייחס לאירוע זה כאירוע חירום של "תיקון-והחלפה". חלון ההזדמנויות שבין ניצול פעיל לבין חילוץ אישורי גישה כבר פתוח.