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

MaxKB, העוזר הארגוני לפתרונות AI בקוד פתוח שמתוחזק על ידי 1Panel-dev, מספק רשימת הרשאות לפי משתמש ולפי כלי, כך שמנהל יכול להעניק לחבר מרחב עבודה כלי אחד ולשלול כלי אחר. לפי ייעוץ האבטחה שפורסם ב-2 בספטמבר 2026, שלילה זו נשמרה בנתיבים של הכלי עצמו אך לא בנתיב שבו סוכן או תהליך עבודה משתמשים כדי לקרוא לאותו כלי. חבר מרחב עבודה בעל התפקיד הנמוך ביותר יכול היה לציין את המזהה של כלי שנשלל בעת בניית תהליך עבודה, להריץ את תהליך העבודה ולקבל לא רק את הפלט של הכלי אלא גם את פרטי הכניסה ש-MaxKB מפענח בצד השרת כדי להריץ אותו. גרסאות 2.0.0 עד 2.9.2 מושפעות, והייעוץ לא ציין גרסה מתוקנת. רשומה זו — עקיפת ההרשאה בשיגור כלים ב-MaxKB — היא ערך אחד בOrcaRouter AI Incident Archive, שמכיל את מערך הרשומות המלא ואת הרשומות הסמוכות לאירוע זה.

מה שהופך את המקרה לראוי לקריאה מדוקדקת אינו הציון. אלא העובדה שהמוצר כבר כלל את הבדיקה הנכונה, הפעיל אותה על הדלת המובנת מאליה, והשאיר דלת שנייה לאותה יכולת ללא השגחה. הייעוץ GHSA-383v-fx78-pphm נכתב על ידי החוקר שמצא אותו ופורסם דרך מערכת הייעוצים של GitHub בשעה 07:43 UTC ב-2 בספטמבר 2026, תוך ייחוס ל-Matteo Panzeri (@matte1782). רשומת ה-CVE, CVE-2026-77516, הגיעה ב-21 בספטמבר 2026.

מה שההנחיה קובעת

המודל לכל כלי של MaxKB הוא WorkspaceUserResourcePermission, המתוארת בייעוץ כרשימת היתרים עם דחייה כברירת מחדל הנפתרת בזמן הבקשה. מסלולי הכלים הייעודיים אוכפים אותה. הייעוץ מפרט את האכיפה ב-apps/tools/views/tool.py, שבו Operate.put, Operate.get, Debug.post, Export.get ו-Delete נושאים כל אחד בדיקת הרשאת צפייה מול הרשאת הכלי של סביבת העבודה של הקורא. Debug.post הוא המסלול הקרוב ביותר להרצת כלי פשוטה, והוא מוגן.

נתיב השיגור של הסוכן וזרימת העבודה אינו מחיל מחדש את הבדיקה הזו. הייעוץ מתחקה אחר שלושה מקומות נפרדים שבהם היא חסרה. בקובץ apps/application/serializers/application.py, ה-serializer של האפליקציה קושר tool_ids, skill_tool_ids ו-mcp_tool_ids ישירות מקלט הבקשה ללא הרשאה לכל כלי — והייעוץ מציין שחוסר הסימטריה ניכר באותו קובץ, משום ש-knowledge_id_list מאומת מול בסיסי הידע הנגישים למשתמש כמה שורות בהמשך, בעוד שהכלים אינם מאומתים. בקובץ apps/common/utils/shared_resource_auth.py, filter_authorized_ids מעביר כל כלי בסביבת העבודה של הקורא ללא תנאי; שער חוצה-סביבות-העבודה שהוא נשען עליו הוא hook המיועד ל-enterprise בלבד ושאינו קיים במהדורת הקהילה, והוא לעולם אינו מתייעץ עם WorkspaceUserResourcePermission. ובנקודת היעד, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py מריץ את הקוד המאוחסן של הכלי כאשר ה-init_params שלו מפוענחים באמצעות rsa_long_decrypt תחת זהות האפליקציה, ללא בדיקת הרשאה לכל כלי.

הודעת הייעוץ מכנה את התוצאה הרצת סגן מבולבל: שיגור תהליך העבודה מפעיל כלי, ואת הסודות השמורים שלו, שמבקש זהה נדחה מלגשת אליהם בנתיבים של הכלי עצמו. חשיפת פרטי הגישה היא החלק שעולה על שימוש לא מורשה רגיל בכלי.init_params של כלי מוצפנים במנוחה באמצעות RSA ומפוענחים בצד השרת רק בזמן ההרצה, כך שמבקש שמפעיל את ההרצה הזו מקבל ערכים שמעולם לא היו ברשותו ולא היה יכול לספק.

ההדגמה, במספרים של החוקר עצמו

הייעוץ מדווח על אימות דינמי ב-v2.9.2, שהורץ מהתמונה הרשמית all-in-one, 1panel/maxkb:v2.9.2. ההגדרה כללה סביבת עבודה אחת, מנהל, וחבר שני בעל תפקיד USER. המנהל יצר את Tool A ואת Tool B, שם סוד אקראי חדש בשדה init_params של Tool B, וכתב את גוף Tool B כך שיחזיר את הסוד הזה בעת הפעלה. לאחר מכן הוענקה לחבר הרשאה לפי כלי עבור Tool A בלבד, והייעוץ אומר שמצב אפס-ההרשאות של Tool B נבדק מחדש במסד הנתונים לאחר ההרצה.

המחצית הנדחית של הבדיקה החזירה את מה שהמוצר מבטיח. כחבר, נתיב הניפוי של Tool B החזיר 403, נתיב העדכון החזיר 403, נתיב הייצוא החזיר 403, ו-Tool A שהוענקה לו הרשאה החזיר 200 כבדיקת שפיות. מחצית העקיפה קישרה לאחר מכן את Tool B אל תוך יישום זרימת עבודה דרך צומת ספריית כלים — הקשירה התקבלה עם HTTP 200 וללא בדיקה לכל כלי — והרצת זרימת העבודה החזירה HTTP 200 עם גוף שהכיל את שם הכלי, את סוד הסנטינל, ואת רשימת המפתחות ["api_key"].

בהודעת הייעוץ נאמר שהסוד נחשף בשלוש שכבות: בתגובת ה-API של זרימת העבודה, ברשומת ביצוע של כלי עם מצב SUCCESS, ובשורת מסד הנתונים שבה מופיע השדה של Tool B, init_params, כטקסט צופן RSA באורך 344 בתים — וזו הדרך שבה החוקר טוען שהערך פוענח בצד השרת תחת זהות האפליקציה ולא סופק על ידי הקורא. אותו חבר שנדחה במסלול ההרצה של הכלי השיג את הסוד המפוענח של הכלי על ידי כריכתו לזרימת עבודה.

ציון אחד פורסם, וציון גבוה יותר שנוי במחלוקת

הציון המשויך ל-CVE-2026-77516 הוא CVSS 3.1 5.4, בינוני, עם הווקטור AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. הרשומה של NVD מראה שציון זה מקורו בפיד הייעוץ של GitHub ולא בניתוח של NVD עצמו, והרשומה נושאת את הסטטוס Deferred, כלומר NVD לא העשיר אותה. הסיווג של הארכיון עצמו עוקב אחר הציון שפורסם: חומרה בינונית, ללא נזק מתועד בעולם האמיתי.

סעיף ההשפעה של הייעוץ עצמו טוען ליותר. הוא מציין חומרה של 7.1, גבוהה, על וקטור שמעלה את השפעת הסודיות לגבוהה, ואומר שהנתון עולה ל-8.1 כאשר הכלי שנשלח מבצע כתיבות מורשות תחת זהות האפליקציה. זו מחלוקת על אופן ספירת חשיפת פרטי הכניסה, ולא על האם העקיפה קיימת — אותו מסמך גם מדגים את הפגם וגם טוען שמשקלו מופחת מדי. אין דבר ברשומה הציבורית שמכריע איזה מהנתונים נכון, והדירוג הבינוני של הארכיון עוקב אחר ציון ה-CVE שפורסם ולא אחר הטיעון של הייעוץ.

שתי הערכות נוספות מתועדות. נקודות ההחלטה של SSVC מטעם CISA, שנוספו לרשומת NVD ב-28 בספטמבר 2026, מתעדות ניצול כ"poc", יכולת אוטומציה כ"no", והשפעה טכנית כ"partial" — הערך "poc" משקף שקיימת הוכחת היתכנות, וזה אכן המצב, בהודעה הייעוצית עצמה; הוא אינו ממצא של ניצול בשטח. מודל EPSS של FIRST העמיד את ההסתברות לניצול ב-30 הימים הבאים על 0.242%, באחוזון ה-15.2, בהערכה מתאריך 27 באוקטובר 2026.

תיקון שקדם לייעוץ, ואף לא אחד בטווח המושפע

טבלת הגרסאות של ייעוץ האבטחה קובעת שהגרסאות המושפעות הן 2.0.0 עד 2.9.2, ושגרסאות מתוקנות אין; הטקסט שלו אומר שלא קיימת גרסה מתוקנת נכון למועד הסקירה, ומוסיף שתיקון במהדורה מתויגת יאפשר ל-CVE להתעגן בה. המאגר של הספק מספר סיפור מעט שונה, וההבדל הזה חשוב לכל מי שמחליט מה להריץ.

במאגר MaxKB, הפונקציות שסוגרות את מסלול השיגור — validate_bound_tool_permissions ו-get_authorized_tool_ids ב-apps/application/serializers/application.py — חסרות בתג v2.9.2 וב-v2.10.2-lts, v2.10.3-lts ו-v2.10.4-lts, וקיימות מ-v2.10.5-lts ואילך. מהדורה זו פורסמה ב-6 באוגוסט 2026, ארבעה שבועות לפני הייעוץ. אותו תג מוסיף בדיקת כלים לפי משתמש ל-base_tool_lib_node.py, בהסתמך על WorkspaceUserResourcePermission, ומוסיף מסנן מודע-משתמש ל-shared_resource_auth.py — כלומר, הוא מיישם, בקווים כלליים, את שלושת שלבי התיקון שהייעוץ ממליץ עליהם בהמשך.

איש לא הצהיר על הקשר הזה בפומבי. הערות השחרור של v2.10.5-lts אינן מזכירות תיקון להרשאות כלים; הן מפרטות ארבעה פריטי אבטחה לא קשורים ומקבץ של עבודת פיצ'רים ותיקוני באגים. הייעוץ האבטחתי אינו מזכיר את 2.10.5 בשמו, וטווח המושפעים שלו פשוט מסתיים ב-2.9.2, המהדורה האחרונה של סדרת 2.9. היסטוריית המהדורות מראה שאין תיקון 2.9.x לאחר הייעוץ, כך שפריסה על 2.9.2 אינה כוללת בילד מתוקן בתוך הסדרה שלה. המהדורה הנוכחית היא v2.10.8-lts, שפורסמה ב-22 באוקטובר 2026, וההערות שלה מתארות תיקוני X-Pack באישור כלים משותפים ולא משהו בנתיב ה-dispatch של המהדורה הקהילתית.

מה לא מבוסס?

יש שלושה דברים שכדאי להפריד מהדגמה. ראשית, אין דיווח ציבורי על כך שהעקיפה שימשה נגד מישהו. הרשומה היא פגיעות שנמצאה, לא חדירה שנחקרה; אין בה קורבן, אין שחקן מיוחס ואין נזק, והוכחת ההיתכנות של ההודעה הורצה על ידי החוקר בסביבת עבודה מבוקרת. שנית, נראה שאף ארגון חדשות, רגולטור או צוות מחקר שני לא ניתחו את הפגם: הסיקור הקיים מוגבל למאגרי פגיעויות ולאגרגטורים — ובהם VulDB, מסד הנתונים של Rapid7, Armis, SOCRadar ו-openCVE — שמפרטים את ה-CVE ונושאים את תיאור ההודעה, ואף אחד מהם אינו מציע הערכה עצמאית של הקוד. לכן המנגנון כפי שתואר כאן נשען על הודעה אחת ועל קוד המקור של הספק עצמו. שלישית, אין נתון לגבי כמה פריסות MaxKB נמצאות בטווח המושפע, וגם לא הספק ולא החוקר פרסמו נתון כזה.

אוכלוסיית הסיכון צרה אך לא טריוויאלית לספירה: התקנות קהילתיות (community edition) של MaxKB באירוח עצמי בגרסאות 2.0.0 עד 2.9.2 שיש בהן יותר מחבר מרחב עבודה אחד, ושבהן מנהל השתמש בהרשאות ברמת כלי כדי למנוע שימוש בכלי הנושא בתוך פרטי גישה. הפגם אינו הרצת קוד מרחוק ודורש חשבון תקף בעל הרשאות נמוכות, וזו הסיבה שהשפעה על סודיות היא שמניעה את הציון ולא נתיב התקיפה. מה שתוקף מרוויח מוגבל למה שמחזיקים הכלים שנחסמו — מפתחות API, אסימונים, וכל מה שאלה פותחים — וזו גם הסיבה שמחברי ההתראה טוענים שההשפעה גדולה ממה שמשתמע מדירוג סודיות נמוך.

מה מפעיל יכול לעשות

התיקון שבהמלצה מופנה למתחזקים ולא למפעילים, ושלושת שלביו ממופים לקוד שהופיע ב-v2.10.5-lts: להחיל את ההרשאה לכל כלי לפני הרצת כלי במימושי ספריית הכלים וצומת הכלי, ולאמת כל ערך מקושר של tool_ids, skill_tool_ids ו-mcp_tool_ids בזמן הקישור כפי שknowledge_id_list כבר מאומת, ולגרום לfilter_authorized_ids לבדוק את ההרשאה לכל כלי ולא רק את החברות ב-workspace.

עבור צוות שמריץ build מושפע, השלבים המעשיים הנובעים מתיאורו של הייעוץ עצמו הם אלה.

• התייחסו לכל סוד המאוחסן ב־init_params של כלי בפריסה מושפעת כנגיש לכל חבר מרחב עבודה, כולל בעל התפקיד הנמוך ביותר, והחליפו את אישורי הגישה האלה במקום להניח שדחיית הגישה ברמת הכלי הגנה עליהם.

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

• בדוק אילו זרימות עבודה וסוכנים קושרים כלים הנושאים פרטי התחברות, מכיוון שקשירה זו היא השלב שהייעוץ אומר שמתקבל ללא בדיקה לכל כלי.

• אם משדרגים, יש לציין שבדיקת ה-per-user מופיעה במאגר החל מ-v2.10.5-lts ואילך, ושאף מהדורה אינה מסומנת על ידי ה-advisory כמתקן — מפעיל שמסתמך על השדרוג מסתמך על קוד המקור המתויג, ולא על הצהרת תיקון של הספק.

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

הלקח של הרשומה הוא מבני ולא מספרי. הרשאה לכל משאב חזקה רק כמו נקודת הכניסה הפחות מוגנת שלה, ופלטפורמת סוכנים צוברת נקודות כניסה במהירות: נתיב ניפוי באגים, נתיב ייצוא, צומת תזרים עבודה, טריגר צ'אט. ל-MaxKB היו רשימת ההענקות והבדיקה; מה שהיה חסר לה, עבור סדרת 2.0 עד 2.9, היה ההרגל לשאול את אותה שאלה בכל דלת.