AI Safety Incidents

CISA מוסיפה את עקיפת האימות של MCP של LiteLLM ל-KEV: כל טוקן Bearer הספיק

מחבר

Rowan Sterling

תאריך פרסום

Oct 28, 2026

מודלים אחרונים · 20צפו בכל המודלים →

בנצ'מרקים: Artificial Analysis · מתעדכן יומית

חזרה לכל הפוסטים

ב-2 בספטמבר 2026 הוסיפה הסוכנות לאבטחת סייבר ותשתיות של ארה"ב את CVE-2026-59822 לקטלוג ה-Known Exploited Vulnerabilities שלה כ"פגיעות אימות לא תקין ב-BerriAI LiteLLM", אחד משבעה פגמים באצווה של אותו יום. הבאג נמצא בנקודת הקצה MCP Streamable HTTP של LiteLLM: כאשר אימות של מפתח LiteLLM נכשל, מנגנון הגיבוי להעברת OAuth2 החליף אובייקט UserAPIKeyAuth() ריק במקום לדחות את הבקשה, כך שכל כותרת Authorization Bearer מזויפת פתחה סשן MCP מאומת. תוקף שהגיע לנקודת הקצה הזו יכול היה לפרט ולקרוא לכל כלי MCP שאיתם הוגדר השער, ודרך הכלים הללו להגיע לשירותים שמאחוריהם. כל גרסה לפני 1.84.0 מושפעת, ולסוכנויות האזרחיות הפדרליות ניתן עד 16 בספטמבר לתקן. רשומה זו — הרישום ב-KEV של עקיפת האימות ב-MCP של LiteLLM — היא ערך אחד בארכיון אירועי ה-AI של OrcaRouter, המכיל את מלוא מערך הרשומות ואת הרשומות השכנות לאירוע זה.

הסיבה שבאג בפרוקסי חשוב יותר ממה שציון ה-CVSS שלו מרמז היא מה שנמצא מאחורי הפרוקסי. צוות מחקר האיומים של Wiz מנסח זאת ישירות: "פרוקסי של LiteLLM יכול להחזיק מפתחות עבור כל ספק מודלים שאליו הוא מנתב, כולל OpenAI, Anthropic, Azure ו-Gemini. ייתכן שהוא גם פועל עם הרשאות IAM בענן ומתחבר לשירותים פנימיים דרך שרתי כלים של MCP. פגיעה אחת יכולה להעניק לתוקף גישה לאישורים ולשירותים במורד הזרם מהפרוקסי, ולא רק לפרוקסי עצמו." Wiz Research אומרת שהיא גילתה את הפגם, וכוורות הדבש של Wiz תיעדו מאוחר יותר ניסיונות להשתמש בו.

המנגנון: בדיקה שנכשלה שהחזירה סשן תקין

הודעת הייעוץ של BerriAI עצמה, GHSA-7488-6r32-c95q, מתארת את הפגם בשתי משפטים: "מטפל האימות של MCP תמך בהעברת OAuth2 ישירה עבור שרתי MCP במעלה הזרם, אך מסלול הגיבוי יכול היה להחליף אימות מפתח LiteLLM שנכשל באובייקט UserAPIKeyAuth() ריק. הדבר איפשר לבקשות עם כותרת Authorization מזויפת להגיע לכלי MCP ללא מפתח LiteLLM תקין." המילה החשובה היא מסלול גיבוי. בקוד היה ענף עבור פריסות שמעבירות ישירות את אסימון ה-OAuth של שרת MCP במעלה הזרם, וכאשר מפתח LiteLLM נכשל באימות, הענף הזה החזיר אובייקט אימות ריק במקום שגיאה.

Screenshot of the GitHub security advisory GHSA-7488-6r32-c95q, titled 'MCP Authentication Bypass via OAuth2 Passthrough Fallback' and marked High with a CVSS v4 score of 8.8 out of 10. The package table shows litellm on pip, affected versions below 1.84.0, patched versions at or above 1.84.0. The Impact section states that LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token, that the MCP auth handler's OAuth2 passthrough fallback could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object, and that an attacker could list and call configured MCP tools and access connected services exposed through MCP. A Patches section says the issue is fixed in 1.84.0. A Workarounds section says that if upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at the reverse proxy or API gateway. The severity panel lists Attack Vector Network, Complexity Low, Requirements None, Privileges Required None; the CVE ID field reads CVE-2026-59822.

אובייקט אימות ריק אינו זהה להיעדר אובייקט אימות. קוד במורד הזרם ראה UserAPIKeyAuth שנבנה בהצלחה והמשיך, בלי דייר, בלי משתמש ובלי היקף הרשאה שמצורפים אליו. הכתיבה של Wiz בוטה יותר לגבי ההשלכה המעשית: "כאשר אימות הטוקן נכשל, במקום לדחות את הבקשה, השרת מחזיר אובייקט UserAPIKeyAuth() ריק ללא הגבלות. כל טוקן Bearer (אפילו תו בודד, למשל x) מעניק גישה מלאה ל-MCP."

OrcaRouter card titled 'What the fallback path did', subtitled that the failure happened after validation rather than before it, in every version before LiteLLM 1.84.0. Four stages run left to right. Stage 1, Request arrives: the attacker holds no LiteLLM key, and a code block shows GET /mcp/ with the header Authorization: Bearer x. Stage 2, Key validation: the supplied token is checked and does not resolve to a key, marked FAIL, with a red tag reading NO REJECTION. Stage 3, OAuth2 passthrough fallback: intended for upstream OAuth tokens, it returned an object rather than an error, showing UserAPIKeyAuth(), with an amber tag reading EMPTY, NO SCOPE. Stage 4, MCP tooling: tools can be listed and called and connected services reached, showing tools/list followed by tools/call, with a green tag reading SESSION AUTHENTICATED. A lower band headed 'Why it held' explains that the branch returned a constructed authentication object rather than a boolean, so downstream code had a valid-looking UserAPIKeyAuth to read and no reason to ask whether the key behind it existed. A footer credits BerriAI advisory GHSA-7488-6r32-c95q and Wiz Research's 27 August 2026 write-up.

מה שזה נותן לתוקף הוא תפריט. פרוטוקול MCP חושף רשימת כלים, כך שסשן שמבצע אימות מחזיר את השמות והסכמות של כל כלי שהשער הוגדר להגיע אליו — מסדי נתונים, מאגרי קוד, ממשקי API פנימיים, בדוגמאות של Wiz. בהודעת היועץ של הספק נאמר הדבר בפשטות: "תוקף יכול להשתמש בזה כדי לרשום ולקרוא לכלי MCP מוגדרים ולגשת לשירותים מחוברים החשופים דרך MCP." לאחר מכן קריאות הכלים מתבצעות בכל סמכות שהפרוקסי עצמו מחזיק כלפי אותם שירותי backend, וזו בעיית ריכוז ההרשאות שתיארה Wiz.

תיקון במאי, CVE ביולי, מועד אחרון פדרלי בספטמבר

התאריכים אינם מתיישבים כפי שקורא עשוי להניח, והפערים הם החלק המעניין. LiteLLM 1.84.0 — הגרסה הראשונה שהייעוץ מציין כממתוקנת — הועלתה ל-PyPI ב-14 במאי 2026, לפי מטא-נתוני השחרור של אינדקס החבילות עצמו. מזהה ה-CVE הוקצה במסגרת תוכנית CVE ב-7 ביולי 2026 והרשומה פורסמה למחרת, 8 ביולי; רשומת ה-OSV PYSEC-2026-3479 הגיעה ב-23 ביולי. הרישום ב-KEV הגיע ב-2 בספטמבר, עם מועד אחרון לתיקון של 16 בספטמבר.

OrcaRouter timeline card titled 'From patch to federal deadline', subtitled that the fixed build shipped sixteen weeks before the KEV listing and that the patch was never the bottleneck. Five dated rows, each with the source that records it: 14 May 2026, LiteLLM 1.84.0 published, per PyPI release metadata; 7 July 2026, CVE identifier reserved with the CVE Program, per the CVE.org record; 8 July 2026, CVE-2026-59822 published, assigned by GitHub as CNA, with the OSV record PYSEC-2026-3479 following on 23 July; 2 September 2026, added to CISA KEV as one of seven entries that day, added on evidence of active exploitation; 16 September 2026, federal remediation deadline, due date set for federal civilian agencies under BOD 26-04. A footer reads that dates are as recorded by each source named in the right-hand column.

שני דברים נובעים מכך. ראשית, הבנייה המתוקנת הייתה זמינה לציבור יותר משלושה חודשים לפני ש-CISA רשמה את הפגם כמנוצל — כך שלארגונים שהיו כפופים לדדליין הייתה גרסת שדרוג עובדת זמינה כל הזמן, והוספה ל-KEV לא הייתה הרגע שבו הופיע תיקון. שנית, פער הגרסאות התרחב מאז: הגרסה הנוכחית של LiteLLM ב-PyPI היא 1.106.5, שהועלתה ב-27 באוקטובר 2026. פריסה שעדיין נמצאת על גרסה נמוכה מ-1.84.0 נמצאת כעת יותר מעשרים מהדורות משנה מאחור, ולא רק חסרה תיקון אחד.

מה שהמודעה קובעת, ומה שהיא אינה קובעת

ההתראה של CISA לגבי האצווה אומרת שהתוספות נעשות "על בסיס ראיות לניצול פעיל", והרשומה הניתנת לקריאה מכונה של הקטלוג עבור CVE-2026-59822 כוללת תאריך הוספה 2 בספטמבר 2026, תאריך יעד 16 בספטמבר 2026, ערך שימוש בקמפיין כופר ידוע של "Unknown", ושתי חולשות: CWE-287 (אימות לא תקין) ו-CWE-306 (חסר אימות לפונקציה קריטית).

• נקבע: CISA העריכה שהפגם מנוצל באופן פעיל והכניסה אותו לרשימה הפדרלית לתיקון. רשומת ה-SSVC של NVD, המיוחסת לרכז CISA ובעלת חותמת זמן של 2 בספטמבר 2026, מתעדת ניצול כ"פעיל", יכולת אוטומציה כ"כן" והשפעה טכנית כ"חלקית".

• מבוסס:נצפה ניצול בסביבה מבוקרת. Wiz פרסמה תעבורת honeypot שהציגה בקשות עם טוקנים בני תו בודד שבודקות נקודת קצה למניית מודלים: בקשת GET אל /v1/models הנושאת "Authorization: Bearer x". The Hacker News, שדיווח על מקבץ ה-KEV ב-3 בספטמבר, תיאר את אותה פעילות ככזו שבה Wiz צפתה ב"מאמצי ניצול הכוללים את CVE-2026-59822 נגד ה-honeypots שלה כדי לבדוק נקודות קצה למניית מודלים."

• נקבע: שני ציוני החומרה קיימים, והם שונים בהתאם למסגרת. הייעוץ של BerriAI מדרג את הפגם לפי CVSS 4.0 בציון 8.8, גבוה, כאשר סודיות גבוהה, שלמות נמוכה וזמינות ללא; הערכת CVSS 3.1 של NIST עצמו, שהיא ראשיתית ב-NVD, מעמידה אותו על 8.2. שני המספרים מתארים את אותו פגם תחת מערכות ניקוד שונות, ואין להשוות ביניהם כאילו האחד החליף את האחר.

• לא נקבע: קורבן מזוהה בשם. לא ההתראה של CISA, לא הייעוץ של BerriAI, לא הדוח של Wiz ולא הסיקור של The Hacker News מזהים ארגון שכלי ה-MCP שלו היו נגישים דרך פגם זה, או מדווחים על פרטי התחברות או נתונים שנלקחו ממנו. התיעוד הציבורי של הניצול הוא טלמטריית honeypot וקביעה פדרלית, ולא פרצה שנחשפה.

• לא נקבע:ששום קבוצת כופרה אינה משתמשת בו. השדה KEV מציין "Unknown", שהוא ערך ש-CISA מקצה, ולא ממצא של היעדרות לכאן או לכאן.

התקדים של יוני, וזה לא שרשרת ביצוע קוד מרחוק.

זו הפרצה השנייה של LiteLLM שמגיעה לקטלוג KEV ב-2026, וקל להתבלבל בינה לבין הקודמת. {{1}}CVE-2026-42271{{/1}}, שנוספה ב-8 ביוני 2026 עם מועד אחרון ל-22 ביוני, היא הזרקת פקודה בנקודות הקצה לבדיקת שרת MCP של LiteLLM: Wiz מתארת נקודות קצה שמאפשרות למשתמש לבדוק תצורת שרת MCP לפני שמירתה, כאשר שדה ה-command מועבר להרצת תת-תהליך ללא אימות. תוקפים שלחו תצורת שרת stdio מזויפת שפקודתה הורידה והריצה כורה קריפטו, והחזירו לחיצת יד MCP שנראית תקינה כך שהבדיקה נראתה כמצליחה. הרשומה של CISA עבורה מפרטת {{2}}CWE-78{{/2}} ו-CWE-77 — הזרקת פקודה וארגומנטים, לא אימות.

הפגם הזה הוא זה שמתחבר לשרשרת. Wiz אומרת ש-CVE-2026-42271 „יכול להשתרשר עם עקיפת אימות כותרת Host של Starlette (CVE-2026-48710) כדי להשיג RCE ללא אימות כלל”, ושחוקרים חיצוניים קישרו את קבוצת הכופר Qilin לניצול פעיל של השרשרת הזו. CVE-2026-48710 נוסף לקטלוג KEV באותו מקבץ של 2 בספטמבר שבו נוסף מעקף LiteLLM, עם אותו מועד אחרון של 16 בספטמבר, וההערה של CISA עצמה בקטלוג על פגם Starlette אומרת שניתן לשרשר אותו עם CVE-2026-42271. הקישור ל-Qilin שייך לזיווג הזה. זה אינו ממצא לגבי CVE-2026-59822, ושום דבר במקורות שנסקרו אינו מקשר את קבוצת הכופר לעקיפת האימות.

פרט מנהלי אחד מפריד בין שתי הרשומות של LiteLLM: הפעולה הנדרשת ברשומת יוני מציינת את BOD 22-01, ההוראה התפעולית המחייבת הישנה יותר, בעוד רשומת ספטמבר מציינת את BOD 26-04, "תעדוף עדכוני אבטחה על בסיס סיכון". ההתראה של CISA אינה מסבירה את השינוי, והקטלוג אינו מוסיף לו הערה.

מה השתנה אחרי

מסלול התיקון קצר. ההמלצה של BerriAI היא לשדרג לגרסה 1.84.0 ואילך, והיא מציעה פתרון עקיף לצוותים שאינם יכולים לעבור מיד: "להשבית נתיבי MCP או לחסום גישה ל-/mcp/ ולנקודות קצה קשורות של MCP בפרוקסי ההפוך או בשער ה-API שלכם." פתרון עקיף זה הוא כלי גס — הוא מסיר את היכולת במקום להגביל אותה בשער — אך זוהי ההקלה היחידה שהספק נוקב בשמה עבור פריסות שאינן מתוקנות.

נוסח הפעולה הנדרשת של CISA עבור נקודות הכניסה מציב סוכנויות פדרליות בפני אותה דילמה: ליישם צעדי מיתון לפי הוראות הספק ובהתאם ל-BOD 26-04, "או להפסיק להשתמש במוצר אם צעדי מיתון אינם זמינים", כאשר האחריות מוטלת על כל סוכנות להעריך את חשיפת הנכס לאינטרנט. ההנחיה מחייבת רק סוכנויות של הרשות המבצעת האזרחית הפדרלית; CISA מעודדת ארגונים אחרים לאמץ את אותו תעדוף מבוסס סיכון בלי לחייב זאת.

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

מה נשאר פתוח

שלושה פערים ראויים לציון ולא לטשטוש. אין דוח תקרית ציבורי המקשר את CVE-2026-59822 לחדירה ספציפית, ולכן הרישום ב-KEV נשען על ראיות הניצול של CISA ועל תצפיות כוורת הדבש של Wiz, ולא על קורבן מתועד. אין הצהרת ספק כיצד נתיב הגיבוי נכתב כך, או כמה זמן היה קיים לפני 1.84.0 — ההודעה מתארת את הפגם ואת תיקונו, לא את ההיסטוריה שלו. ומועדי היעד של האצווה לא היו אחידים: חמישה משבעת הערכים שנוספו ב-2 בספטמבר נשאו מועד יעד של 5 בספטמבר, בעוד שהערכים של LiteLLM ו-Starlette נשאו 16 בספטמבר. CISA אינה מציינת מדוע.

מה שנקבע הוא צר יותר ושימושי יותר מהציון. תו בודד בכותרת Authorization היה, בגרסאות המושפעות, בלתי ניתן להבחנה ממפתח תקף לנקודת הקצה של MCP — והגרסאות שהתנהגו כך הפסיקו להיות עדכניות במאי 2026.

CISA מוסיפה את עקיפת האימות של MCP של LiteLLM ל-KEV: כל טוקן Bearer הספיק

המנגנון: בדיקה שנכשלה שהחזירה סשן תקין

תיקון במאי, CVE ביולי, מועד אחרון פדרלי בספטמבר

מה שהמודעה קובעת, ומה שהיא אינה קובעת

התקדים של יוני, וזה לא שרשרת ביצוע קוד מרחוק.

מה השתנה אחרי

מה נשאר פתוח

מוצר

משאבים

לספקים

הצטרפו לקהילה שלנו

מהבלוג

ספקי מודלים