Wiz: כמעט אחד מכל 10 שערי LiteLLM חשופים מקבל את מפתח האדמין לדוגמה sk-1234

ב-9 בספטמבר 2026 פרסמה Wiz Research מחקר על LiteLLM, שער ה-AI בקוד פתוח שיושב בין האפליקציות לבין ספקי המודלים שהן משלמות להם, ודיווחה כי 294 מתוך 3,074 פריסות LiteLLM שאליהן הצליחה להגיע באינטרנט הציבורי — 9.6%, כמעט אחת מכל עשר — קיבלו את sk-1234, מפתח המאסטר לדוגמה שמודפס בתיעוד ההתקנה של הפרויקט עצמו, או שלא דרשו אישור גישה כלל. המחרוזת הזו אינה מפתח API רגיל: ב-LiteLLM היא גם פרטי הגישה של המנהל וגם המתג שמפעיל את האימות, ולכן כל מי שמציג אותה יכול לקרוא כל מפתח של ספק מודל השמור בשער, לצפות בכל פרומפט ובכל השלמה שעוברים דרכו, ולהגיע לכל שרת כלים המחובר דרך Model Context Protocol. שותפי הכתיבה של Wiz, עמיתי כהן ויערה שריקי, שילבו את הגישה הזו עם הרצת קוד ברמת root ועם גניבת אישורי ה-IAM בענן של המארח. תיאור זה נשען על הדוח של Wiz, על פרסומי האבטחה של LiteLLM עצמו ועל רשימת החולשות המנוצלות הידועות של CISA שפורסמה לאחר מכן, וארכיון אירועי ה-AI מחזיק ברשומה הזו לצד שכנותיה, כאשר לכל אחת מקורות, חומרה ודירוג מהימנות משלה.

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

ה-9.6% הוא סריקה אחת, ו-Wiz אומרת שבדיקת ההמשך שלה מאוגוסט אינה ניתנת להשוואה אליה.

המדידה פשוטה, ו-Wiz מציינת את השיטה שלה בבירור: 3,074 פרוקסי LiteLLM החשופים לאינטרנט שאותרו באמצעות Shodan בפברואר 2026, כאשר כל אחד מהם נבדק אם יבצע אימות עם מפתח הדוגמה המתועד. מבין אלה, 294 אכן ביצעו אימות. בתוך אותה קבוצה, ל-191 לא היה מוגדר מפתח מאסטר כלל והם היו מקבלים כל מחרוזת שהייתה מוצעת להם; השאר השאירו את מציין המקום של מדריך ההתקנה במקומו. אף אחד משני מצבי הכשל אינו דורש באג תוכנה. שניהם זקוקים רק לכתובת השער ולערך המודפס ב-README של הפרויקט עצמו.

זה גם סריקה של ספק יחיד. הנתון של Wiz חזר על עצמו על ידי יוזמת AI Safety Initiative של Cloud Security Alliance ב-10 בספטמבר ועל ידי The Hacker News באותו יום, אך שניהם חוזרים עליו תוך ייחוס, ולא נמצא עבור מאמר זה שחזור עצמאי של הנתון 3,074. Wiz ביצעה סריקה שנייה באוגוסט 2026 ומצאה יותר מ-85,000 מופעים, פי עשרים ושבעה בקירוב מספירת פברואר. החברה אומרת שרובם נראים כ-honeypots או פריסות בדיקה, ושני המספרים אינם ניתנים להשוואה. אין נתון חשיפה עדכני, וכל מאמר שמצטט נתון כזה מצטט את פברואר.

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

מפתח האב הוא גם פרטי ההתחברות של המנהל וגם המתג שמפעיל את האימות.

העיצוב של LiteLLM נותן לסוד אחד שני תפקידים. מפתח המאסטר מאמת בקשות ניהוליות, והנוכחות שלו היא מה שמאפשר אימות בכלל: ללא מפתח מאסטר וללא תצורת JWT או OAuth2, הפרוקסי פועל פתוח ומקבל כל בקשה. Wiz ניגשה לבסיס הקוד עם Claude Code של Anthropic, בחיפוש אחר תכונות שלוקחות קלט שנשלט על ידי המשתמש ומעבירות אותו להקשר הרצה, ומטפל האימות היה אחד משלושה משטחים שהיא סימנה.

לפני v1.82.0-stable, התוצאה של אותה משימה שנייה הייתה חמורה יותר מפרוקסי פתוח. Wiz מצאה שכאשר לא הוגדר מפתח ראשי, מטפל האימות הקצה את התפקיד PROXY_ADMIN לכל בקשה נכנסת, כך שקורא לא מאומת לא רק התקבל אלא התקבל כמנהל. בקשת ה-Pull Request #22095, שצוטטה בדוח, שינתה את תפקיד ברירת המחדל ל-INTERNAL_USER והוסיפה בדיקת מנהל לנקודות הקצה של ה-guardrail.

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

Wiz גם הדגימה נתיב מעמדת הניהול הזו לזהות הענן של המארח. LiteLLM מאפשרת למנהל לרשום נתיב העברה לכל כתובת URL של יעד, והיעד אינו נבדק מול טווחי כתובות פרטיות, localhost או כתובת המטא-נתונים של הענן. הפניית נתיב אל שירות המטא-נתונים של המופע מחזירה את פרטי הכניסה של IAM שתחתם פועל העומס. מעבר של שירות המטא-נתונים ל-IMDSv2, שבדרך כלל מביס סוג זה של זיוף בקשות בכך שהוא דורש אסימון הפעלה שמתקבל בנפרד, אינו מועיל: LiteLLM מעבירה כל כותרת שמתחילה ב-x-pass- אל היעד, כאשר הקידומת מוסרת, כך שניתן להבריח את כותרת האסימון פנימה. Wiz אומרת שניתן לטעון שהתכונה פועלת כמתוכנן תחת מודל איומים שנותן אמון במנהלים, ולכן אין לה CVE ואין לה תיקון.

הפסקה האחרונה היא הדגמה, לא תקיפה שנצפתה. Hacker News, שדיווח על המחקר ב-10 בספטמבר, מציין כי אין מקור שמדווח שמישהו עשה זאת נגד פריסה אמיתית, וכי הדבר מחייב קודם גישת מנהל. הניסוח של Wiz זהה: ה-pass-through הוא מאפיין תכנוני שהופך לפגיעות רק כאשר פרטי ההתחברות של המנהל הם מחרוזת מתוך התיעוד.

8.8 ו-2.1 מדרגים את אותה שרשרת מנקודות מוצא שונות

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

CVE-2026-59822 הוא עקיפת האימות ב-MCP, וההתראה של LiteLLM מדרגת אותה כגבוהה, 8.8 לפי CVSS 4.0, ללא צורך בהרשאות, ללא אינטראקציית משתמש וללא דרישות תקיפה. לנקודת הקצה של MCP יש מטפל אימות משלה, שנבנה כדי לקבל מפתח LiteLLM או אסימון OAuth2 המיועד לשרת כלי במעלה הזרם. כאשר אסימון נכשל באימות של LiteLLM, המטפל תפס את ה-401 והחליף אותו באובייקט אימות ריק במקום לדחות את הבקשה. לפיכך כל אסימון Bearer יצר סשן MCP תקין, כולל תו בודד: הוכחת ההיתכנות של Wiz שולחת אסימון Bearer בן אות אחת ומקבלת בחזרה מזהה סשן. הפגם תוקן בגרסה 1.84.0.

CVE-2026-59821 הוא פגם ה-guardrail, והייעוץ של אותו פרויקט מדרג אותו כנמוך, 2.1, עם דרישת הרשאות גבוהות ודרישות תקיפה נוכחות. תכונת ה-guardrail של קוד מותאם מאפשרת למנהל לשלוח Python שהשרת מהדר ומריץ. נקודת הקצה לבדיקה של ממשק המשתמש באינטרנט (Web UI) אימתה את הקוד מול רשימת דפוסים אסורים והסירה את ה-builtins לפני הרצתו; נקודות הקצה ליצירה ולעדכון בסביבת הייצור לא עשו אף אחד מהם. Python מאכלסת מחדש את ה-builtins כשהם חסרים, כך שהקוד שנשלח הגיע לספרייה הסטנדרטית. הוכחת ההיתכנות של Wiz רושמת guardrail שמריץ פקודת shell בזמן הרישום — לפני כל בקשת מודל — ומחזירה את הפלט של הפקודה כסיבת החסימה, אשר בבדיקה שלה חזר כ-root. הפגם תוקן ב-v1.82.0-stable.

שני התיאורים תואמים, והמשפט המגשר נמצא בייעוץ עצמו: LiteLLM מציינת שבפריסות ללא מפתח מאסטר מוגדר, קוראים עלולים להיחשב למנהלי פרוקסי, וזה מה שהעמיד את נקודות הקצה של ה-guardrail בהישג יד. A 2.1 מניח משתמש בעל הרשאות. השרשרת של Wiz היא מה שקורה כאשר מפתח ברירת המחדל הופך כל קורא לבעל הרשאות. אף אחד מהציונים אינו שגוי לגבי נקודת המוצא שלו; הם חלוקים לגבי התדירות שבה נקודת מוצא זו פנויה.

ישנה הסתייגות אחת מטענתה של Wiz שלפיה לאחר 1.82.0 תוקף המחזיק במפתח ברירת המחדל יכול היה לבצע קוד רק בתוך ארגז חול. Hacker News מפנה לייעוץ נפרד ממאי 2026, CVE-2026-40217, המתאר בריחה מארגז החול הזה באמצעות טכניקות bytecode בגרסאות מ-1.81.8 ועד, אך לא כולל, 1.83.10, בתוך תהליך proxy שהייעוץ אומר שרץ כ-root בתמונת מכולת ברירת המחדל. הגעה לנקודת קצה זו דורשת אישורי מנהל proxy, וזה בדיוק מה שמפתח המאסטר הוא.

גם ה-8.8 אינו אוניברסלי. הערת המחקר של Cloud Security Alliance מציינת כי ההודעה של GitLab מפרטת ציון בסיס של 8.2 עבור אותה פגיעות, ונמנעת מלהכריע בין שתי המתודולוגיות, תוך שהיא מציינת רק ששתיהן נמצאות בטווח הגבוה. חומרת "גבוהה" של הרשומה אינה תלויה בכך איזה מספר משתמשים.

CVE אחד נוצל בפועל; לחשיפת מפתח ברירת המחדל אין קורבן מזוהה.

CISA הוסיפה את CVE-2026-59822 לקטלוג החולשות המנוצלות הידועות ב-2 בספטמבר 2026 וקבעה מועד יעד לתיקון של 16 בספטמבר 2026 עבור סוכנויות אזרחיות פדרליות; הערך בקטלוג כולל CWE-287 ו-CWE-306, אימות לקוי והיעדר אימות. ההערה של Cloud Security Alliance מדווחת כי עוקבים בתעשייה תיארו אותו כפגם הראשון הספציפי ל-MCP ברשימה הזו. Wiz פרסמה את הניצול שנצפה על ידה: מ-7 ביולי 2026 ה-honeypots שלה תיעדו בקשות שנשאו אסימוני bearer בני תו בודד שבדקו נקודות קצה לרישום מודלים, ו-Wiz לא מתארת שימוש אחר בפגם.

דבר דומה אינו קיים עבור מפתח ברירת המחדל. לא נקב בשמו של קורבן, לא זוהה שער שהושתלט עליו באמצעות sk-1234, ואין טלמטריה שמראה ש-294 המארחים נמצאים בשימוש. רשומת הארכיון אינה מתעדת נזק ממשי, וזו אמירה על ראיות ולא על המנגנון: החשיפה נמדדה, ולא נצפתה בשימוש.

שני פריטים נוספים מתויקים לעתים קרובות לצד אלה ואינם אותו הדבר. CVE-2026-42271, הרצת פקודות דרך שני נקודות קצה לבדיקה של MCP, הוא הפגם ב-LiteLLM שתוקפים השתמשו בו בפועל כדי להריץ קוד; ה-honeypots של Wiz תיעדו אותו מתקין כורה מטבעות קריפטוגרפיים. המקרה מאוגוסט 2026 שפרסמה מיקרוסופט, שבו קרא פורץ את משתני הסביבה של קונטיינר השער, שחזר את המפתח הראשי, את מפתחות הספקים ואת מחרוזת החיבור למסד הנתונים, ולאחר מכן העתיק רשומות מטבלאות המודלים והמפתחות הווירטואליים של LiteLLM, ממחיש מה שווה שער שנפרץ ולא דרך חדשה להיכנס; The Hacker News מדווח שמיקרוסופט מעריכה שנקודת הכניסה היא שרשרת CVE-2026-42271.

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

מדיניות האבטחה של LiteLLM מפורשת. היא מפרטת בין הנושאים שאינם בתחום הטיפול "התקפות הדורשות תצורה שגויה בשלב ההתקנה (למשל אי-הגדרה של master_key בתצורת הפרוקסי)", וקובעת שאלה במפורש מחוץ לתחום ואינם נחשבים לפגיעים. Wiz מגיעה למסקנה תואמת מהכיוון ההפוך כשהיא מכנה את התנהגות ה-pass-through ככזו שלכאורה פועלת כמתוכנן.

העמדה הזו נבחנה בפומבי. ב-15 באוגוסט 2026 חוקר פתח ב-GitHub את issue #37054, ודיווח כי פרוקסי שבו LITELLM_MASTER_KEY אינו מוגדר מאמת כל ערך מפתח, וכי קובץ ה-docker-compose שמסופק אינו מגדיר אחד כזה. הגיליון נסגר 30 דקות לאחר מכן, והתגובה היחידה בו היא מאותו חשבון: היא מציינת את הוראת מדיניות האבטחה שלפיה דיווחים מועברים דרך דיווחי פגיעות פרטיים ולא דרך גיליונות ציבוריים, מתנצלת על ההגשה בפומבי, ואומרת שהדוח המלא מוגש במקום זאת במסלול הייעוץ. לא מופיעה תגובת מתחזק בשרשור, ולכן הרשומה מראה שהמדווח הסיג את הדיווח הציבורי ולא תגובת פרויקט אליו. שום דבר פומבי אינו מתעד מה עלה בגורל ההגשה הפרטית.

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

האכיפה הגיעה ב-3 באוקטובר, עשרים וארבעה ימים לאחר הדיווח

שני פגמי הקוד תוקנו זמן רב לפני הדוח. ציר הזמן של החשיפה של Wiz מתעד הרצת קוד guardrail שדווחה ב-18 בפברואר 2026 ותוקנה ב-25 בפברואר ב-v1.82.0, עקיפת MCP שתוקנה ב-25 באפריל ב-v1.84.0, ניצול שנצפה ב-7 ביולי, מזהי CVE שפורסמו ב-8 ביולי ורישום בקטלוג ב-2 בספטמבר. ארטיפקטי ההפצה נושאים תאריכים מאוחרים יותר מאלה של התיקונים: אינדקס החבילות מציג את v1.82.0 ב-1 במרץ 2026 ואת v1.84.0 ב-14 במאי, והם מציינים מתי כל תיקון הפך לזמין להתקנה ולא מתי נכנס לקוד. שני רשומות שחרור של הצד הראשון מתארכות את אותם תיקונים מאוחר יותר מציר הזמן הזה. השחרור v1.82.0-stable ב-GitHub נושא 11 במרץ 2026 והחבילה 1.82.0 ב-PyPI נושאת 1 במרץ; v1.84.0 מתוארך ל-14 במאי 2026 בשניהם. שום דבר שפורסם לא מסביר את הפער, וזה לא משנה לטיעון, מכיוון שכל אחד מהתאריכים האלה נופל חודשים לפני דוח ספטמבר. שני פרסומי הייעוץ ב-GitHub מוסיפים תאריך שלישי בכלל: הם פורסמו ב-30 ביוני 2026, שלושה שבועות לפני מזהי ה-CVE שלדברי Wiz יצאו ב-8 ביולי.

מה שאף אחד מהמהדורות האלה לא תיקן היה ברירת המחדל. Wiz דיווחה כי נכון ל-9 בספטמבר מפתח המאסטר עדיין היה מוגדר ל-sk-1234 בעת התקנת LiteLLM דרך Docker Compose או pip install, ו-The Hacker News אישר כי מדריך ההגדרה עדיין השתמש בערך באותו יום. השינוי הגיע עם v1.104.0, שהועלה ל-Python Package Index ב-3 באוקטובר 2026, ובהערות השחרור שלו הוא מופיע כשינוי שובר תאימות: הפרוקסי כעת מסרב לעלות עם מפתח מאסטר לא מוגדר, ריק או ידוע לציבור, תוך ציון מקור הערך הפגום בשגיאת האתחול והדפסת פקודה שמייצרת מפתח מאובטח. רשומה נלווית מתעדת שינוי שמפסיק לפרסם ערך חלש וידוע לציבור של מפתח מאסטר בקונפיגורציות ובדוגמאות המופצות, וקובץ ה-docker-compose בענף הראשי של הפרויקט כבר אינו מגדיר מפתח כלל.

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

מה שלא השתנה הוא נתיב ה-pass-through אל שירות המטא-נתונים של המופע. הוא עדיין אינו נושא CVE ואין לו תיקון, מפני שהפרויקט מתייחס למנהלים כאל מהימנים. רשימת התיקונים של Wiz היא לפיכך בעיקר עבודת מפעיל: מפתח מאסטר חזק וייחודי, סקירה של guardrails רשומים ולאחריה הפעלה מחדש של התהליך כדי לנקות קוד המוחזק בזיכרון, ביקורת של נקודות קצה pass-through עם יציאת קונטיינר מוגבלת, ותפקידי IAM עם הרשאה מינימלית. אף אחד מארבעת אלה אינו מגיע באמצעות שדרוג בלבד.

מה שהתיעוד אינו מבסס

• לא נמצא שחזור עצמאי של סריקת 3,074 המארחים. ה־9.6% הוא מדידה של Wiz, וכל דיווח אחר עליו חוזר על הנתון תוך ייחוס.

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

• אין קורבן. דבר ברשומה אינו נוקב בשמו של שער, מפעיל או חשבון ענן שנפרץ באמצעות מפתח ברירת המחדל, והניצול שתיעדה Wiz הוא של עקיפת ה-MCP ולא של sk-1234.

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

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

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

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