פגיעות קריטית בשער ה-AI בקוד פתוח Bifrost מאפשרת הרצת פקודות ללא אימות

חוקרי JFrog חשפו פגיעות קריטית בכלי הקוד הפתוח Bifrost — שער (gateway) המנתב בקשות אל יותר מ-20 ספקי מודלי שפה שונים — המאפשרת לתוקף ללא כל אימות להריץ פקודות מערכת על שרת השער בבקשת HTTP אחת בלבד. מכיוון שהשער מאחסן את מפתחות ה-API של כל הספקים המחוברים אליו, שליטה בתהליך שלו חושפת את כל אותם מפתחות לגניבה.

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

מזהה	CVE-2026-90898 (חמורה נוספת: CVE-2026-86242)
מוצר וגרסאות מושפעות	Bifrost HTTP transport — כל הגרסאות שקדמו ל-2.1.0, כאשר אימות ממשק הניהול כבוי (זו ברירת המחדל)
חומרה (CVSS)	9.8 מתוך 10 — קריטית
מנוצל בפועל	לא דווח על ניצול בשטח נכון למועד הפרסום
סטטוס תיקון	תוקן ב-transports/v2.1.0 ואילך

מה קרה

Bifrost תומך בפרוטוקול MCP (Model Context Protocol) ומאפשר לרשום אצלו "לקוחות" מסוג stdio — תהליך מקומי המורכב מפקודה וארגומנטים. הבעיה: בקשת POST יחידה ולא מאומתת לנקודת הקצה /api/mcp/client מספיקה כדי שהשער יתחיל להריץ את אותה פקודה, בהרשאות המשתמש שמריץ את תהליך Bifrost, עוד לפני שמתבצע כל תהליך אימות (handshake) של הפרוטוקול. כלומר, אין צורך בשום פרטי גישה כדי להריץ קוד על השרת.

לפי JFrog, שתי הפגיעויות חולקות את אותו שורש: ממשק הניהול של Bifrost מגיע כברירת מחדל ללא אימות כלל. החברה ממליצה להתייחס לכל מופע שרץ עם ממשק ניהול חשוף וללא אימות כאל מופע שנפרץ בפועל, ולבצע רוטציה למפתחות ה-API המאוחסנים בו.

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

עדכנו ל-Bifrost transports v2.1.0 ומעלה, והפעילו אימות על ממשק הניהול — אל תסתמכו על ברירת המחדל.
אם הפעלתם מופע Bifrost עם ממשק ניהול חשוף לרשת וללא אימות בכל שלב, התייחסו אליו כאל פגיע ובצעו רוטציה מיידית לכל מפתחות ה-API של ספקי מודלי השפה המחוברים אליו.
ודאו שממשק הניהול של השער אינו חשוף לאינטרנט הפתוח, והגבילו גישה גם ברמת הרשת (firewall או קבוצת אבטחה) גם לאחר העדכון, כהגנה נוספת.
בדקו יומני גישה לנקודת הקצה /api/mcp/client לאיתור בקשות רישום לקוח לא מוכרות — סימן אפשרי לניסיון ניצול.
הפגיעות ממחישה סיכון רחב יותר בתשתיות AI gateway חדשות: ממשקי ניהול שמגיעים פתוחים כברירת מחדל. בדקו כל רכיב תשתית AI שהוספתם לאחרונה מאותו היבט, לא רק את Bifrost.