LiteLLM הוא שרת proxy שארגונים מעמידים לפני מודלי שפה, כדי שכל הפניות אליהם יעברו דרך נקודה אחת שמנהלת מפתחות, מכסות ותיעוד. חולשה שקיבלה 9.3 מתוך 10 מאפשרת לפונה שאינו מזוהה כלל לקרוא מתוך מסד הנתונים של אותו שרת, ואולי גם לשנות אותו. מאז 8 במאי 2026 היא מסומנת כמנוצלת בפועל, והגרסה שסוגרת אותה היא 1.83.7.

מה החולשה?

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

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

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

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

מי מושפע?

גרסאות LiteLLM מ-1.81.16 ועד 1.83.7 שאינה כלולה. מי שרץ על 1.83.7 ומעלה מוגן, ומי שרץ על גרסה שקדמה ל-1.81.16 אינו מושפע מהחולשה הזאת.

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

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

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

חלון של שלושה ימים הוא מהקצרים שהקטלוג נותן.

מה עושים?

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

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

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

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