ה-SSRF של Azure MCP Server עלול להדליף את אסימון הזהות המנוהלת שלו לכתובת URL
- OrcaחדשOrcaCyber: GLM 5.3 Abliterated / Uncensored2026-11-04$3.00 / $5.00 לכל 1M טוקנים · 66 tok/s
- OrcaחדשOrcaCyber: Hy4 Abliterated / Uncensored2026-11-04$0.80 / $1.60 לכל 1M טוקנים · 101 tok/s
- orcaחדשOrca: OrcaC2 1.02026-10-303 tok/s
- OrcaחדשOrcaCyber: MiniMax M3.1 Flash Abliterated / Uncensored2026-10-29$0.80 / $1.60 לכל 1M טוקנים · 99 tok/s
- OrcaחדשOrcaCyber: GLM 5.3 Flash Abliterated / Uncensored2026-10-27$0.80 / $1.60 לכל 1M טוקנים · 106 tok/s
- OrcaחדשOrcaCyber: Qwen3.8 Flash Next Abliterated / Uncensored2026-10-26$0.80 / $1.60 לכל 1M טוקנים · 118 tok/s
- OrcaחדשOrcaCyber: MiMo V2.6 Flash Abliterated / Uncensored2026-10-26$0.80 / $1.60 לכל 1M טוקנים · 60 tok/s
- MoonshotחדשMoonshotAI: Kimi K3.1 Pro2026-10-2446אינטליגנציה
- OrcaחדשOrcaCyber: DeepSeek V4.1 Flash Abliterated / Uncensored2026-10-23$0.80 / $1.60 לכל 1M טוקנים · 86 tok/s
- minimaxMiniMax: M3.1 Flash2026-10-1929אינטליגנציה
- OrcaOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 לכל 1M טוקנים · 105 tok/s
- deepseekDeepSeek: DeepSeek V4.1 Flash 10172026-10-1733אינטליגנציה
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-10-1740אינטליגנציה
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 לכל 1M טוקנים · 64 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955אינטליגנציה
- anthropicAnthropic: Claude Sonnet 5.52026-09-2854אינטליגנציה
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 לכל 1M טוקנים · 180 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228אינטליגנציה
- OpenAIOpenAI: GPT-6 Sol2026-09-2244אינטליגנציה
- AnthropicAnthropic: Claude Opus 5.52026-09-2258אינטליגנציה
Microsoft פרסמה את CVE-2026-26118 ב-10 במרץ 2026: פגיעת זיוף בקשה בצד השרת (SSRF) ב-Azure MCP Server Tools, החבילה שמאפשרת לסוכני AI וללקוחות MCP לבצע פעולות על משאבי Azure בשפה טבעית. תוקף שמסוגל לתקשר עם סוכן מבוסס MCP יכול היה לשלוח כתובת URL זדונית במקום מזהה משאב Azure רגיל; השרת היה שולח אז בקשה יוצאת לכתובת זו, ובמילותיה של Microsoft, ״עשוי לכלול את אסימון הזהות המנוהלת שלו״ — ובכך למסור לקורא אישור גישה שלעולם לא נועד לראות. Microsoft העניקה לפגיעות ציון CVSS 8.8 ודירגה אותה כ״חשוב״, והחבילות שמכילות את התיקון הן 1.0.2 ו-2.0.0-beta.17. בהודעה לא נרשמו ניצול ולא חשיפה ציבורית לפני התיקון, ולא נרשם נזק ממשי ממנה. תקרית זו היא ערך אחד ב-the Orca AI Incident Archive, שמחזיק את התיעוד המלא עם המקורות המצוטטים, דירוג החומרה והערכת רמת הביטחון.
מה שהודעת האזהרה למעשה אומרת
הרשומה של Microsoft Security Response Center תמציתית, וכמעט כל פרט שפורסם על פגיעות זו נגזר ממנה או מתשובות של Microsoft למספר שאלות המשך. התיאור במלואו: "זיוף בקשות בצד השרת (ssrf) ב-Azure MCP Server מאפשר לתוקף מורשה להסלים הרשאות דרך הרשת." רשומת ה-CVE שריינה את המזהה ב-11 בפברואר 2026 ופרסמה אותו לציבור ב-10 במרץ בשעה 14:00 UTC; הערת הפרסום של Microsoft והרשומה של NVD שתיהן מציינות את אותו יום. NVD ניתחה את הרשומה ופרסמה אותה בשעה 18:18 UTC באותו אחר הצהריים. הודעת הרגולטור היחידה שנמצאה עבור כתבה זו הגיעה ממרוקו: יחידת maCERT של DGSSI כללה את CVE-2026-26118 בעלון מתאריך 11 במרץ 2026, תוך פירוט Azure MCP Server Tools among המוצרים המושפעים ברמת הסיכון שלה עצמה — Important, ללא ציון נפרד והפניה חזרה לפרסום של Microsoft.
החולשה ממופה לCWE-918, זיוף בקשות בצד השרת, וסיווג ההשפעה הוא העלאת הרשאות. ציון הבסיס של Microsoft הוא 8.8 על הווקטור CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, עם ציון זמני של 7.7 על E:U/RL:O/RC:C — רכיב E:U פירושו שלא היה ידוע ל-Microsoft קוד ניצול כאשר הציון נקבע, ו-RL:O פירושו שהיה תיקון רשמי זמין. NVD מציגה את אותו ציון בסיס ומסווגת אותו כ-High; סולם שלושת השלבים של Microsoft עצמה מכנה אותו Important.
שני שדות חשובים לא פחות מהציון. הרשומה של מיקרוסופט אומרת נוצלה: לא ונחשפה בפומבי: לא. רשומת ההחלטה של SSVC של CISA על הערך ב-NVD, עם חותמת זמן של 5 במרץ 2026, מסכימה בכל הנוגע לניצול — אין — בעוד שהיא קובעת שההשפעה הטכנית היא מוחלטת ושהיא ניתנת לאוטומציה לא. מודל FIRST EPSS הציב את ההסתברות לניצול ב-30 הימים הקרובים על כ-1.0%, באחוזון ה-62.8, בנתונים שנמשכו בתאריך 3 בנובמבר 2026. זוהי פגיעות שנמצאה ותוקנה, ולא כזו שידוע שנוצלה.
כיצד מזהה משאב הופך לבקשה יוצאת
Azure MCP Server הוא המימוש של Microsoft בפרוטוקול Model Context Protocol, הממשק שבו סוכני AI משתמשים כדי לקרוא לכלים. הכלים שלו לוקחים את הפרמטרים שסוכן מספק — שם חשבון אחסון, מזהה מנוי, שם מסד נתונים — והופכים אותם לקריאות מול מישורי הניהול והנתונים של Azure. התיעוד של Microsoft מתאר את השרת כמבצע אימות דרך Entra ID באמצעות „פרטי המשתמש שלך ב-Azure או זהות מנוהלת”, כאשר הגישה מוגבלת על ידי בקרת גישה מבוססת תפקידים של Azure.
הפגם נמצא בנקודה שבה פרמטר שאמור לציין משאב Azure מתקבל במקום זאת כ-URL. ההסבר של Microsoft עצמה: תוקף „יכול לנצל את הבעיה על ידי שליחת קלט שנבנה במיוחד לכלי Azure Model Context Protocol (MCP) Server שמקבל פרמטרים שמסופקים על ידי המשתמש. אם התוקף יכול לתקשר עם הסוכן המבוסס MCP, הוא יכול לשלוח URL זדוני במקום מזהה משאב Azure רגיל.” לאחר מכן השרת שולח את הבקשה לאן שנאמר לו, ולא לאן שהכלי התכוון.
החלק שהופך מטרד להסלמת הרשאות הוא מה שנלווה אליו. Microsoft אומרת שפניית היציאה „עשויה לכלול את אסימון הזהות המנוהלת שלה”, מה שמאפשר לתוקף ללכוד את האסימון הזה „בלי לדרוש גישה ניהולית”. אסימון זהות מנוהלת הוא אישור Bearer: כל מי שמחזיק בו יכול להציג אותו לשירותי Azure שהזהות מורשית עבורם, עד שהוא פג. החצי המקל באותה פסקה חשוב לא פחות — התוקף משיג „את ההרשאות המשויכות לזהות המנוהלת של MCP Server”, ובמילותיה של Microsoft, „לא זוכה להרשאות רחבות יותר ברמת הדייר או הרשאות מנהל; רק אלו הקשורות לזהות המנוהלת שנפגעה”. רדיוס הנזק הוא כל מה שמישהו העניק לזהות הזו, ובפועל זה לעיתים קרובות יותר ממה שכלי בודד היה צריך.
Microsoft אינה מציינת את שם הכלי או הפרמטר המושפעים, וגם אף מקור שנבחן עבור מאמר זה אינו עושה זאת. ההשמטה הזו היא עצמה פרט: הייעוץ מתאר סוג של כלי — כזה שמקבל פרמטרים שסופקו על ידי המשתמש וניתן להסיתו לאחזר כתובת URL — ולא נקודת קצה בודדת.
התיקון, והחבילות שנשאו אותו
זה לא היה עדכון של Windows. Azure MCP Server Tools מופצים כחבילת NuGet עבור .NET, חבילת npm וחבילת Python ב-PyPI, והתיקון הוא העלאת גרסה באחת מהן — לפי מה שהפריסה משתמשת בו. הודעת הייעוץ של Microsoft מפרטת את הטווחים המושפעים: 1.0.0 עד 1.0.2 (לא כולל), ו-2.0.0-beta.1 עד 2.0.0-beta.17 (לא כולל), בכל ההפצות של NuGet, npm ו-PyPI.
התאריכים במרשם npm מראים שגרסאות הבנייה המתוקנות היו במרשם לפני הייעוץ. גרסה 1.0.2 של @azure/mcp פורסמה ב-6 במרץ 2026, ארבעה ימים לפני שה-CVE פורסם לציבור; 2.0.0-beta.17 פורסמה ב-6 בפברואר 2026, חמישה ימים לפני שמיקרוסופט שמרה לעצמה את מזהה ה-CVE וחודש לפני שהייעוץ הופיע. יהיה הרצף הפנימי במיקרוסופט אשר יהיה, הקוד המתוקן לא נכתב בתגובה ליום הפרסום. NVD ומסד נתוני הייעוץ של GitHub מסכימים לגבי גבולות עליונים אלה. הם נבדלים במעט בקצה התחתון של טווח PyPI — NVD אומר 2.0.0-beta.1, הייעוץ של GitHub אומר 2.0.0b14 — פער ששתי הרשומות נשאו מאז הפרסום, ושהוא משפיע רק על כמה אחורה פריסת Python צריכה לבדוק.
הודעת האבטחה עצמה עודכנה ב-20 במרץ 2026, עשרה ימים לאחר פרסומה, עם הערה ש-Microsoft “הוסיפה מוצרים לטבלת עדכוני האבטחה המתעדת את שיטות האריזה השונות ששימשו להפצת Azure MCP Server Tools”. במילים אחרות, הגרסה הראשונה של הודעת האבטחה ציינה את המוצר אך לא את כל הערוצים שבהם הופץ, מה שמשנה כאשר פעולת התיקון היא “לשדרג את החבילה” ולא “להתקין KB זה”.
מה לא מבוסס?
מי מצא את זה.לא הייעוץ של Microsoft ולא הרשומה ב-CVE.org מציינים מדווח; שדה הקרדיטים ב-CVE ריק. זה אינו מהווה הוכחה שלא ניתן קרדיט למישהו באופן פרטי, אלא רק שאין קרדיט פומבי.
ניצול כלשהו. מיקרוסופט אינה מתעדת אף מקרה, הערכת SSVC של CISA מסכימה לכך, ואף מקור שנבדק עבור מאמר זה אינו מתאר זהות שנפרצה בשטח. שדה הנזק הממשי ברשומה הוא false, בהתאם לכך. EPSS נמוך הוא תחזית, לא ממצא, והיעדר אירוע מדווח אינו הוכחה שלא התרחש אירוע כזה.
האם קיים אקספלוייט ציבורי. כאן הכיסוי המשני מתפצל. פוסט ממרץ 2026 בבלוג של Blueinfy קובע שיש "אקספלוייטים ציבוריים של הוכחת היתכנות, כמו אלה ב-GitHub" ומזהיר מפני "הפיכה מהירה לנשק", אך אינו מספק קישור, מטען או הדרכה, ואינו מדגים את הפגם. התיעוד של Microsoft קובע שהפגיעות לא נחשפה לציבור לפני התיקון. חיפוש מאגרים ב-GitHub אחר מזהה ה-CVE ב-4 בנובמבר 2026 החזיר מאגר אחד — מעבדת זיהוי של Microsoft Sentinel שפורסמה ב-17 במרץ 2026, ולא אקספלוייט — ועמוד הפגיעות של Mallory קובע ששני אקספלוייטים מועמדים נבדקו ונפסלו. הטענה לקיומו של קוד אקספלוייט ציבורי עובד אינה מבוססת, על סמך הראיות הזמינות; הטענה שאיש לא ניסה אינה מוכחת באותה מידה.
המסגור. עמוד ב-PolicyLayer, אתר לסיכומי תקלות של ספק, מציג מחדש את CVE-2026-26118 כשרשרת של הרצת קוד מרחוק ללא אימות המסתיימת בהשתלטות מלאה על הדייר, תוך מתן קרדיט לחוקר בשם ולמצגת ב-RSAC 2026. המקורות המצוטטים באותו עמוד עצמו נושאים כותרות של SSRF, התאריכים בו אינם מתיישבים עם ציר הזמן של ה-CVE, ולא ההודעה של Microsoft ולא הדיווח של SecurityWeek מ-10 במרץ מתארים הרצת קוד. מאמר זה מתייחס לתיאור ה-SSRF והטוקן כאל התיאור המבוסס ואינו חוזר על מסגור ה-RCE.
מדוע הטוקן, ולא הבקשה, הוא הממצא
זיוף בקשות בצד השרת הוא אחד מסוגי הבאגים הוותיקים ביותר בתוכנה לאינטרנט, ובפני עצמו הוא בדרך כלל אמצעי להגיע למערכות שהתוקף אינו יכול לפנות אליהן ישירות. מה שהופך את הרשומה הזו לראויה לשימור הוא אישור הגישה שמצורף לבקשה. שרת ה-MCP הוא שליח מבולבל כברירת מחדל: יש לו זהות משל עצמו כדי שסוכן יוכל לפעול בשם משתמש, וכל פרמטר שסוכן מעביר הוא, מנקודת מבטו של השרת, טקסט שנמצא בהשפעת התוקף. כאשר אחד מהפרמטרים האלה הופך ליעד ולא לשם, השליח נושא עמו את הרשאתו שלו אל היעד.
התיעוד של Microsoft מחדד היכן הסיכון הזה מתרכז. הוא מתאר את השרת המקומי כ"מיועד אך ורק לשימוש מפתחים בתוך הארגון שלך", בעודו מפרסם בנפרד מדריכי פריסה לשרתים מרוחקים באחסון עצמי ב-Microsoft Foundry וב-Copilot Studio — התצורות שבהן זהות מנוהלת, ולא ההתחברות של המפתח עצמו, היא בדרך כלל פרט הכניסה הרלוונטי. מסלול גניבת הטוקנים שבהנחיה עוסק ספציפית בזהות המנוהלת. היא אינה אומרת שכל התקנה הייתה חשופה, והיא אינה אומרת כמה היו.
הלקח הכללי הוא זה שה-AI Security Verification Standard של OWASP משתמש כעת במקרה כדי ללמד. פרק התזמור של AISVS מצטט את CVE-2026-26118 בין הדוגמאות המעובדות שלו ומסיק ש„פרמטרים של כלי MCP חייבים להיחשב כנשלטים בידי תוקף, ובקשות יוצאות משרתי MCP חייבות לעבור דרך אותן מדיניות יציאה ומקור (egress and origin) שנדרשות מכל קלט/פלט אחר המונע על ידי סוכן.” זו המלצת בקרה, לא ממצא בנוגע לאירוע הזה, אבל זו התשובה הקונקרטית ביותר שמישהו פרסם לשאלה מה צריך להשתנות.
מה השתנה אחרי
שלושה דברים, ואף אחד מהם אינו דרמטי. Microsoft פרסמה חבילות מתוקנות בכל שלושת המערכות האקולוגיות ועדכנה את ההודעה כדי לציין אותן. מערכת המודיעין על פגיעויות קלטה זאת בשקט: ציון EPSS נמוך, ורשומת NVD שעודכנה לאחרונה ב-17 ביוני 2026. והקהילת הסטנדרטים אימצה אותו כמקרה לימוד, שהוא צורת תגובה איטית יותר ועמידה יותר מאשר תיקון.
לכל מי שעדיין מריץ בילד מושפע, התיקון נותר ללא שינוי ולא זוהר: עברו ל-1.0.2 ואילך בקו היציב, או ל-2.0.0-beta.17 ואילך בקו התצוגה המקדימה, בכל מנהל חבילות שהפריסה נוגעת בו. מעבר לכך, ההיגיון של הייעוץ עצמו מרמז על שלושה אמצעי בקרה — להגביל את היעדים שהשרת רשאי לפנות אליהם החוצה, להעניק לזהות המנוהלת רק את התפקידים שהכלים שלה באמת זקוקים להם, ולהתייחס לכל פרמטר של כלי שיכול להפוך לכתובת URL כקלט עוין. אף אחד מאלה אינו נדרש כדי לשרוד את CVE-2026-26118. כל אחד מהם היה מפחית את הערך של אמצעי הבקרה הבא בעיני תוקף.
איך הארכיון מסווג את זה
הרשומה מוגשת כפגיעות — משהו שהתגלה, לא משהו שידוע כי נוצל — עם רמת ודאות A, כלומר מתועדת היטב כשמקורות ראשוניים מסכימים ביניהם, והיא אינה מסומנת כשנויה במחלוקת. שדה הנזק הממשי שלה הוא false והמעורבות של AI מאושרת, מפני שהמוצר המושפע הוא הגשר בין סוכן AI לבין מישור בקרה בענן ולא שירות כללי שמקרה נמצא בקרבת מקום. התאריך מתועד בדיוק יומי, 10 במרץ 2026, ללא תאריך סיום, מפני שזה נקודת זמן בודדת ולא קמפיין. האזור הוא גלובלי ודגל ציון הדרך הוא false.
שדה אחד מוצג אחרת מדירוג הניקוד שפורסם. חומרת הארכיון נרשמת כבינונית, בסולם משל עצמו; המספר שגם Microsoft וגם NVD מפרסמים הוא 8.8, שאותו Microsoft מכנה Important ו-NVD מסווגת כ-High. תקציר הרשומה מוביל עם ה-8.8 הזה, והפער הוא הבדל בחלוקה לדליונים ולא בעובדות.
מה שהתיעוד אינו יכול להעביר הוא עד כמה גדול חלקו של היעדר בסיפור הזה. יש פגם שמעניק זהות ענן לכל מי שמבקש אותה בצורה הלא נכונה. יש תיקון, שיצא לפני ההודעה. אין מגלה שזוכה לקרדיט, אין כלי בשם, אין ניצול מאומת, ואין דרך למי מבחוץ לדעת אם אי-פריסה מתארחת כלשהי הריצה אי-פעם גרסה פגיעה בזמן שהחזיקה זהות חזקה. ההודעה המדויקת מפרטת מה הפגם עושה ושותקת כמעט על כל דבר אחר, והשתיקה הזו היא הדבר השימושי ביותר לשים לב אליו בה.
