פגיעות עקיפת אימות ב-LiteLLM AI Gateway מנוצלת בפועל; נוספה לקטלוג KEV

פגיעות עקיפת אימות בשער ה-AI בקוד פתוח LiteLLM מאפשרת לתוקף ללא כל אישורי גישה תקפים להגיע לכלים המחוברים דרך פרוטוקול MCP. CISA הוסיפה את הפגיעות לקטלוג הפגיעויות המנוצלות שלה ב-2 בספטמבר 2026, יחד עם פגיעות קריטית נפרדת בפלטפורמת האוטומציה Kestra — סימן לכך שתוקפים מפנים תשומת לב הולכת וגוברת לתשתיות AI ופיתוח שנחשפות לרשת.

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

מזהה	CVE-2026-59822
מוצר וגרסאות מושפעות	LiteLLM, גרסאות שקדמו ל-1.84.0
חומרה	CVSS 8.2 (חמורה)
מנוצל בפועל	כן — אושר על ידי CISA ונוסף לקטלוג KEV ב-2 בספטמבר 2026
סטטוס תיקון	תוקן בגרסה 1.84.0

מה קרה

LiteLLM הוא שרת פרוקסי פופולרי המשמש ארגונים רבים כ"שער" מרכזי לקריאה למודלי שפה שונים דרך ממשק אחיד. נקודת הקצה שלו לפרוטוקול MCP (Model Context Protocol) תמכה במסלול גיבוי מסוג OAuth2 passthrough לשרתי MCP חיצוניים. כאשר אימות המפתח של LiteLLM נכשל, מסלול הגיבוי החליף את הכישלון באובייקט הרשאה ריק במקום לחסום את הבקשה — כך שתוקף שממציא כותרת Authorization יכול להקים "הפעלה מאומתת" מזויפת ולהגיע לכלי ה-MCP המוגנים בלי מפתח API תקף כלל.

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

נקודות לשים לב

עדכנו מיידית ל-LiteLLM 1.84.0 ומעלה — במיוחד אם השער חשוף לרשת או משמש כנקודת גישה לכלי MCP פנימיים.
אם אינכם משתמשים בפועל באינטגרציית MCP OAuth2 passthrough, בדקו שהיא מושבתת בהגדרות עד לעדכון.
חפשו ביומני הרישום (logs) בקשות ל-MCP Streamable HTTP endpoint עם כותרות Authorization חריגות או לא מוכרות שהתקבלו בכל זאת כתקפות.
סקרו אילו כלים וכמה מקורות נתונים חשופים דרך שרת ה-MCP שמאחורי ה-Gateway — ככל שהחשיפה רחבה יותר, כך הסיכון מהניצול גבוה יותר.
ארגונים שמאמצים כלי AI בקצב מהיר נוטים להטמיע שערי גישה כאלה מהר יותר משהם סוקרים את האבטחה שלהם — כדאי לכלול רכיבי AI Gateway במחזורי סריקת פגיעויות הרגילים.