ב-LiteLLM, שרת proxy שארגונים מציבים לפני מודלי שפה כדי לנתב אליהם קריאות, נמצאה חולשה שמאפשרת למשתמש מאומת רגיל להריץ פקודות על השרת עצמו. לא נדרשות הרשאות ניהול, ומספיק מפתח API תקף מהסוג הבסיסי ביותר. הציון הוא 8.7 מתוך 10, הגרסה המתוקנת היא 1.83.7, ומאז 8 ביוני 2026 החולשה נמצאת בקטלוג החולשות המנוצלות של CISA.

מה החולשה?

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

לפני ששומרים הגדרה של שרת MCP חדש, הממשק מאפשר לבדוק אותה: לוחצים בדיקה, והמערכת מנסה להתחבר ולראות אילו כלים השרת מציע. שתי הבקשות שמבצעות את הבדיקה הזאת, POST אל mcp-rest/test/connection ו-POST אל mcp-rest/test/tools/list, קיבלו בגוף הבקשה את ההגדרה המלאה של השרת שרוצים לבדוק. וההגדרה המלאה כוללת, עבור אחד מסוגי החיבור, שלושה שדות: command, args ו-env.

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

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

מי מושפע?

LiteLLM עצמו, מגרסה 1.74.2 ועד 1.83.7, שבה החולשה תוקנה.

הרשומה מונה גם את Red Hat OpenShift AI, שמשלב את LiteLLM בתוכו: הגרסאות המושפעות שם הן 2.25 עד 2.25.8, 3.3 עד 3.3.4, וכן 3.4. זו נקודה שקל לפספס, כי ארגון שמריץ OpenShift AI אינו בהכרח יודע שיש בתוכו LiteLLM.

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

האם מנוצלת בפועל?

כן. ב-8 ביוני 2026 הכניסה CISA את החולשה לקטלוג ה-KEV, רשימת החולשות שהסוכנות האמריקאית מאשרת שתוקפים משתמשים בהן בשטח, עם מועד תיקון לגופים פדרליים ב-22 ביוני 2026.

שווה לשים לב לפער בין התאריכים כאן, כי הוא דווקא מעודד. הרשומה ב-NVD פורסמה ב-8 במאי 2026, חודש שלם לפני הכניסה לקטלוג. מי שעדכן כשהתיקון יצא היה מוגן הרבה לפני שהחולשה הפכה לחולשה מנוצלת.

מה עושים?

עדכנו את LiteLLM ל-1.83.7 או לגרסה חדשה יותר. זו הגרסה שבה שתי הבקשות תוקנו, לפי ההודעה של הפרויקט.

אם אתם מריצים Red Hat OpenShift AI, הרשומה מונה שלושה מצבים: ענף 2.25 מתוקן ב-2.25.8, ענף 3.3 מתוקן ב-3.3.4, וגרסה 3.4 מופיעה כמושפעת בלי שמספר מתוקן מצוין לצדה. במקרה השלישי קחו את הגרסה המדויקת מעדכוני האבטחה של Red Hat.

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

ואחרי העדכון, החליפו מפתחות. החולשה איפשרה לכל בעל מפתח להריץ פקודות, ולכן מפתח שהיה קיים בתקופה החשופה הוא מפתח שאינכם יכולים לדעת מה נעשה בו. עברו במקביל על התהליכים שרצו על המכונה של ה-proxy וחפשו תהליכי בן שאינכם מזהים.