שערי בינה מלאכותית הופכים למשטח התקיפה — רישום ה-KEV של LiteLLM והנתיב דרך מפתחות, MCP והענן
עקיפת האימות של MCP ב-BerriAI LiteLLM (CVE-2026-59822) נחתה בקטלוג ה-KEV של CISA, ו-Microsoft מדווחת על תוקפים שמשתמשים בשערי LiteLLM כדי להפיץ XMRig. מחקר של Wiz מצא שבערך 1 מתוך 10 מבין ~3,000 מופעים פומביים קיבלו את מפתח ברירת המחדל sk-1234 או רצו בלי אימות. אנו בוחנים מה המשמעות של כך שתשתית בינה מלאכותית היא כספת של אישורים.
מאמר זה תורגם במכונה.
בספטמבר 2026 הוסיפה CISA את עקיפת האימות של MCP ב-BerriAI LiteLLM, CVE-2026-59822, לקטלוג Known Exploited Vulnerabilities (KEV) שלה (2 בספטמבר, לפי ציר הזמן של Wiz). החולשה מאפשרת לאסימון Bearer שרירותי לכונן מושב מאומת תקף על נקודת הקצה MCP Streamable HTTP של LiteLLM, והיא הופיעה לצד שש חולשות מנוצלות נוספות — כולל SonicWall SMA 1000 ו-Sangoma Switchvox — בעדכון ה-KEV של תחילת ספטמבר (לפי The Hacker News). LiteLLM הוא שער בינה מלאכותית בקוד פתוח שמחזיק את מפתחות ה-API של כל ספק LLM שמוגדר; לפי האומדן של Wiz הוא נוכח בערך בשליש מסביבות הענן.
העובדות: (1) המחקר של Wiz (פורסם ב-9 בספטמבר) מצא שמבין בערך 3,000 מופעי LiteLLM שפונים לאינטרנט, בערך 9.6% קיבלו את מפתח המאסטר של ברירת המחדל sk-1234 או לא דרשו אימות כלל. במופעים בלי אימות מוגדר, כל משתמש קיבל PROXY_ADMIN כברירת מחדל, והגיע לפונקציונליות ניהול בלי אישורים (תוקן מאז). (2) עם הרשאות ניהול, תוקף יכול להשתמש בתכונת נקודת הקצה המעבירה כדי לתווך בקשות אל כתובות פנימיות שרירותיות — כולל שירות המטא-נתונים של AWS — ומנגנון העברת הכותרות x-pass- מביס את דרישת אסימון המושב של IMDSv2, ומאפשר גניבת אישורי IAM בענן. (3) בספטמבר דיווחה Microsoft על תוקפים ששרשרו את CVE-2026-42271 ואת CVE-2026-48710 (עקיפת האימות BadHost של Starlette) כדי לפרוץ לשערי LiteLLM ולהפיץ כורה XMRig דרך קובץ בינארי ELF (לפי The Hacker News). תקיפות על מופעי RAGFlow חשופים, לעומת זאת, הניבו מפתחות ספק LLM גנובים ומטא-נתונים ולא כופר.
ניתוח (מופרד מהעובדות): מה שהסיפורים האלה מראים הוא ששערי בינה מלאכותית עברו את שלב ה-LLMjacking — הוצאת תקציב ה-API של מישהו אחר — והפכו לנתיב חדירה של ממש לענן. LiteLLM מריץ Python בצד השרת על כל בקשת הסקה, יכול לתווך בקשות אל כתובות פנימיות שרירותיות, ומתחבר לכלים חיצוניים דרך MCP. הוא אינו רק כספת של מפתחות; הוא גשר אל הרשת הפנימית עם יכולת הרצה. נכסים שמגנים מעדיפים להצניע תחת עקרון תכנון של «זו בינה מלאכותית, השאירו אותה פנימית» הופכים, עבור תוקפים, לנתיב רב-שלבי אל מפתחות, IAM ו-API פנימיים מאחורי עקיפת אימות אחת. הפער המבני בין ברירות מחדל שתוכננו לחוויית מפתח (sk-1234, PROXY_ADMIN כשאינו מוגדר) לבין פריסת ייצור ראוי שייקרא כך.
השלכות הגנתיות: (1) אם מריצים LiteLLM, תחילה יש לעדכן ל-v1.84.0 או מאוחר יותר (תיקון CVE-2026-59822) ול-v1.83.7 או מאוחר יותר (תיקון CVE-2026-42271), וגם ל-Starlette 1.0.1 או מאוחר יותר; יש לאשר שמפתח המאסטר של ברירת המחדל הוחלף ושהמופע אינו חשוף לאינטרנט. (2) יש לסובב את כל מפתחות ה-API של הספקים השמורים כאילו נפרצו ברגע שהחשיפה מאושרת, ולקבוע תקרות הוצאה כדי לחסום נזק כשמפתח אכן יוצא. (3) יש להתייחס לתכונות שנושאות הרצת קוד שרירותית או תיווך כתובות שרירותי — MCP, נקודות קצה מעבירות — כהרשאות ברמת סוכן שיש לערוך להן מצאי בנפרד ולהשבית כברירת מחדל. (4) יש לבקר שערי בינה מלאכותית ומתזמרי LLM אחרים באותה עדשה: אישורי ברירת מחדל, פונקציונליות ניהול חשופה, תיווך כתובות פנימיות. אלה הניתוח שלנו, לא הנחיית יצרן.
העובדות במאמר זה נשאבות בעיקר מן המחקר של Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), מהדורת התיקון של BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable), וקטלוג ה-KEV של CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), עם הדיווח של The Hacker News כמשני (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html ו-https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); תאריך ה-KEV של 2 בספטמבר הולך אחר ציר הזמן של Wiz. קטעי הניתוח נשמרים בנפרד מן הדיווח העובדתי. יש לשים לב שספירות המופעים וחלק סביבות הענן הם אומדנים שתלויים בזמן ובשיטת המדידה.