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

MaxKB צירפה כלי Shell לכל עוזר עם כלים ומעולם לא הגבילה אותו

מחבר

Alistair Wren

תאריך פרסום

מודלים אחרונים · 20צפו בכל המודלים →
בנצ'מרקים: Artificial Analysis · מתעדכן יומית
חזרה לכל הפוסטים

MaxKB, פלטפורמת עוזר ארגונית בקוד פתוח שמפורסמת תחת ארגון ה-GitHub 1Panel-dev, בנתה את סוכני הצ'אט שלה על מסגרת עבודה שמוסיפה בשקט כלי shell בכל פעם שמועבר אליה backend בעל יכולת shell — ו-MaxKB מעולם לא הסירה את הכלי ולא ביקשה מאף אחד לאשר את השימוש בו. הפגיעות היא CVE-2026-77521, שפורסמה כייעוץ GitHub GHSA-f36j-f34j-h3rx ב-2 בספטמבר 2026 וקיבלה ציון 10.0 מתוך 10 תחת CVSS 3.1 במקרה של עוזר ציבורי או מוטמע. Lasso Security, אשר גילתה ודיווחה עליה, הדגימה שהודעת צ'אט — או טקסט שהעוזר רק קולט דרך אחזור או מסמך שהועלה — עלולים להוביל את המודל להריץ פקודות: בפריסת bare-metal ישירות על המארח, ובקונטיינר הרשמי דרך מעטפת שהחוקרים אומרים שניתן לעקוף עם נקודה-פסיק. אף מקור מצוטט אינו מתעד את הפגיעות כמנוצלת בשטח. דירוג החומרה של הרשומה עצמה, הערכת המהימנות ורשימת המקורות נמצאים ב-ארכיון אירועי ה-AI, לצד הרשומות השכנות של MaxKB ושל כלי סוכנים מאותו מקבץ גילויים.

MaxKB הוא מוצר באחסון עצמי לבניית עוזרים מתוגברים באחזור: מפעיל יוצר עוזר, מצרף לו יכולות — כלים, שרתי Model Context Protocol, מיומנויות, תתי-יישומים — מחבר בסיס ידע שנבנה ממסמכים שהועלו או מאתרים שנסרקו, ולאחר מכן חושף את העוזר או דרך קונסולה מאומתת או כוידג'ט צ'אט ציבורי הניתן להטמעה. הגמישות הזו היא נקודת החשיפה. תנאי הטריגר של ההתראה אינו תצורה לא שגרתית אלא הרגילה: כל עוזר עם לפחות יכולת אחת מצורפת מנתב את הצ'אט שלו דרך נתיב הסוכן המושפע, בעוד שצ'אט ללא יכולות מצורפות אינו עושה זאת. הכתיבה של Lasso מתארת את הפרויקט כאחד מהנפוצים יותר בקטגוריה שלו, ומציינת ש-MaxKB נפרס בדרך כלל כשירות מרובה דיירים — מה שמציב פקודה שרצה כמשתמש היישום מתחת למודל הדיירות ולא בתוך הפרוסה של דייר אחד בו.

כלי ה-shell הגיע עם ה-framework, לא עם המוצר.

MaxKB בונה את הסוכנים האלה באמצעות ספריית deepagents של LangChain, כשהיא מוצמדת לגרסה 0.6.11 בקובץ pyproject.toml של הפרויקט, הן בתג הפגיע והן בתג הנוכחי. בקובץ apps/application/flow/tools.py, בשורה 467 של התג v2.10.3-lts, הפרויקט קורא ל-create_deep_agent כאשר backend מוגדר ל-SandboxShellBackend, תת-מחלקה של MaxKB שמריצה פקודות על המארח. לפי ההודעה האמינה, deepagents מזריק אוטומטית סט של כלים בכל פעם ש-backend מסוג shell מועבר בדרך זו: execute, ls, read_file, write_file, edit_file, glob ו-grep. הם אינם חלק מארגומנט tools=list, אשר מכיל רק את הכלים של המפעיל עצמו, כלי MCP וכלי מיומנות. לא ניתן להסיר אותם מהממשק או באמצעות תצורה.

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

שער שמפרט שלושה כלים ומשמיט את הרביעי

בקרת human-in-the-loop באותה קריאה היא שורה אחת, והיא מונה שלוש פעולות: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. כתיבת קובץ, קריאת קובץ ועריכת קובץ נקראים בשם. הרצת פקודה אינה מפתח במילון כלל. בפרשנות של ה-advisory, משמעות הדבר היא שלא מתבקש אישור עבור execute — שלוש פעולות מערכת הקבצים נקראות בשם ומוגדרות במפורש לא לעצור, וכלי ה-shell אינו נקרא בשם כלל.

כשמחברים את הדברים, הנתיב הוא: טקסט לא מהימן מגיע למודל, המודל קורא ל-execute, והפקודה מופעלת. ההודעה הייעוצית מציינת שתי דרכים שבהן טקסט לא מהימן יכול להגיע. הדרך הישירה היא צ'אט — ווידג'ט ציבורי או מוטמע, או שיחה של דייר אחר. הדרך העקיפה היא תוכן שהעוזר קולט: מסמך RAG, קובץ שהועלה, או דף אינטרנט שהפלטפורמה סורקת לתוך בסיס ידע. הפוסט של Lasso ממחיש את המסלול השני, באומרו ש"קבוצת האנשים שיכולים להציב טקסט לפני המודל גדולה מקבוצת האנשים שיכולים לשוחח איתו".

בהתקנה על חומרה פיזית, הפקודה היא רק פקודה

כל מה ש-MaxKB עושה בנוגע להכלה מתרחש ב-apps/application/flow/backend/sandbox_shell.py, וב-v2.10.3-lts הוא מתחיל בברירת מחדל. שורה 9 קוראת _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), ו-SANDBOX אינו מופיע ב-Config.defaults ב-apps/maxkb/conf.py. בהיעדר הגדרה מפורשת של MAXKB_SANDBOX, הערך הוא אפס, ענף העטיפה בשורה 65 מדולג, ו-execute מגיע ל-subprocess.run עם shell=True ישירות על המארח, בתור המשתמש שמריץ את השירות — root, בלשון ה-advisory, אם השירות רץ כ-root.

זו התצורה שבה השתמשו החוקרים עבור הוכחת ההיתכנות שלהם על המארח. הם הריצו את הקוד האמיתי של MaxKB מהמקור כאשר MAXKB_SANDBOX אינו מוגדר, יצרו עוזר עם כלי אחד מחובר, וביקשו ממנו בהודעת צ'אט אחת להריץ פקודות מידע מערכת. כלי ה-execute הופעל וכתב קובץ שתכולתו הייתה הפלט של uname, id ו-sw_vers של המארח עצמו — פלט אשר, כך צוין בהודעת האזהרה, אומת כלא קיים בתוך שום קונטיינר. Lasso גם מתעד את גבול הדבר שעצר אותו: קובץ הוכחה בשם בוטה נדחה על ידי המודל, בעוד שניסוח תפעולי תמים לא נדחה. יישור מודל, בלשונם, הוא "מכשול מהירות חלקי, לא בקרה".

על התמונה הרשמית ארגז החול רץ ובכל זאת דלף

הקונטיינר הרשמי מגדיר MAXKB_SANDBOX=1 בתמונת הבסיס, בקובץ installer/Dockerfile-base בשורה 48, כך שה-wrapper פעיל שם — וה-wrapper הוא הפגם השני. הוא בנה מחרוזת אחת: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so ואחריה gosu sandbox ואז הפקודה שסופקה על ידי המודל, שהועברה ל-shell שרץ כ-root. מכיוון שהפקודה הושתלה כטקסט, רק הטוקן הראשון שלה היה תחת gosu. כל נקודה-פסיק, צינור, הפניה מחדש או החלפת פקודה בפלט של המודל הוערכו על ידי ה-shell החיצוני כ-root לפני שה-sandbox בכלל ראה אותה.

הדוח של Lasso מציג את הצורה המעשית של זה: מטען של env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id, שבו ls מוגבל, whoami אינו מוגבל, וכל מה שאחריו רץ בחופשיות. בבדיקות, החוקרים כתבו קובץ בבעלות root באמצעות הפניה (redirect) בזמן שהפקודה הפנימית שהורצה בארגז החול נחסמה. בנוסף לכך, neither installer/Dockerfile nor installer/Dockerfile-base מכילים הוראת USER, ולכן תמונת האפליקציה רצה כ-UID 0 — הייעוץ מדווח על אישור root בזמן ריצה. לפיכך, הקונטיינר הריץ פקודות בכל מקרה, וארגז החול רק קבע אילו מהן יוחסו באופן קוסמטי למשתמש בעל ההרשאות הנמוכות.

זרימת התקיפה המלאה שתיארה Lasso אינה דורשת כלל גישה למטרה. התוקף מניח פקודות בדף אינטרנט, ממתין שסוכן של הקורבן יסרוק אותו אל תוך בסיס ידע, ולאחר מכן הקורבן שואל שאלה רגילה. התשובה חוזרת נכונה ולגיטימית; ה-curl המוזרק כבר נורה לעבר השרת של התוקף. בהודעת האבטחה נאמר כי החוקרים בדקו רק את הפריסות שלהם עצמם, ולא כל מופע MaxKB של צד שלישי או מתארח.

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

המנגנון, שני מצבי הפריסה, הקרדיט והגרסה המתוקנת תואמים בארבעה מסמכים: הייעוץ של GitHub, רשומת NVD שפורסמה ב-21 בספטמבר 2026, התיעוד הטכני של Lasso עצמה מ-10 בספטמבר 2026, והדוח של GBHackers מ-22 בספטמבר 2026, שהוא הסיקור היחיד של כלי תקשורת עצמאי שנמצא ל-CVE הזה. אף מקור לא חולק על אף חלק מהממצא, והארכיון רושם את הערך כבלתי שנוי במחלוקת בדרגת הביטחון הגבוהה ביותר שלו.

מה שהמקורות אינם מכילים הוא כל מדד לחשיפה. אין ספירה של פריסות MaxKB, אין ספירה של עוזרים חשופים לאינטרנט או מוטמעים, אין תוצאת סריקה, אין טלמטריה ואין קורבן בשם. שום דבר בתיעוד אינו מראה שהפגם נוצל נגד מישהו, והערכת הניצול של CISA עצמה מסכימה: בלוק ה-SSVC המצורף לרשומת NVD מ-22 בספטמבר 2026 מדרג את הניצול כ"poc", את היכולת לאוטומציה כ"yes" ואת ההשפעה הטכנית כ"total". מודל ה-EPSS של FIRST קבע את ההסתברות לניצול ב-30 הימים הבאים על 1.05 אחוז, האחוזון ה-64, ב-27 באוקטובר 2026, וה-CVE אינו מופיע בקטלוג Known Exploited Vulnerabilities של CISA מתאריך 27 באוקטובר 2026. הדירוג של הארכיון עצמו משקף את אותה ראיה: חומרה גבוהה, נזק אמיתי false.

הציון 10.0 ראוי לכך שהיקף ההשפעה שלו יוצהר, משום שזה המספר שסביר ביותר שיצוטט מחוץ להקשר. זהו הציון במקרה של עוזר ציבורי או מוטמע, שבו וקטור ה-CVSS הוא AV:N/AC:L/PR:N/UI:N/S:C — נגיש דרך הרשת, ללא הרשאות, ללא אינטראקציית משתמש, עם שינוי היקף משום שפקודה בתוך העוזר חוצה אל מערכת ההפעלה המארחת. הציון הוא של ה-CNA, וה-CNA כאן הוא תוכנית הייעוץ של GitHub, שהיא גם היעד שאליו מפנה מזהה המקור של רשומת ה-CVE. NVD מציגה את אותו וקטור כמדד משני, ונכון ל-28 באוקטובר 2026, היא רושמת את הערך בסטטוס "Deferred", כלומר NVD פרסמה את הניתוח של הגורם המקצה ולא את הניתוח שלה.

Rendered two-column card with the kicker 'MAXKB · CVE-2026-77521' and the title 'What the sources establish, and what they do not', subtitled with its sources: GHSA-f36j-f34j-h3rx of 2 September 2026, the NVD record of 21 September 2026, Lasso Security's write-up of 10 September 2026, GBHackers of 22 September 2026, FIRST EPSS, the CISA KEV catalogue and the repository tags. The left column, headed 'Established' in blue, lists eight items: CVSS 3.1 base score 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H for a public or embedded assistant; CWE-78 OS command injection, CWE-250 unnecessary privileges and CWE-749 exposed dangerous method; deepagents 0.6.11 auto-adding execute to any shell backend, with no excluded_tools passed by MaxKB; the approval map covering write_file, read_file and edit_file with execute not a key in it; affected at or below 2.10.3-lts per the advisory and at or below 2.10.4-lts per Lasso Security's write-up; fixed in 2.10.5-lts, published 6 August 2026, 27 days before the advisory; the CISA SSVC assessment of 22 September 2026 with exploitation poc, automatable yes and technical impact total; and EPSS 1.05 percent at the 64th percentile on 27 October 2026 with no listing in the CISA KEV catalogue of that date. The right column, headed 'Not established, or not measured' in amber, lists seven items: no exploitation in the wild recorded by any cited source, with the archive recording real harm as false; no count of affected, exposed or internet-facing deployments; no named victim and no evidence of use in any intrusion; NVD status Deferred, so the 10.0 is the assigner's analysis rather than NVD's; disagreement between the two primary sources on the affected range boundary; the researchers' testing confined to their own deployments; and no detection or triage guidance for either deployment mode. A footer reads 'Card rendered by OrcaRouter. The 10.0 is scored for a public or embedded assistant; the archive grades the record high.' The OrcaRouter logo is composited in the bottom-right corner.

הטלאי שוחרר חודש לפני שההתראה פורסמה

הכרונולוגיה נעה לאחור מן הפרסום, וזהו החלק הפחות אינטואיטיבי של התיעוד. Lasso דיווח על הפגם באופן פרטי דרך ערוץ הייעוץ של GitHub ב-8 ביולי 2026. MaxKB השיבו למחרת, וצמצמו את הדיווח לתמונה הרשמית וביקשו הוכחת היתכנות מבוססת מכולה; החוקרים סיפקו אותה ואת עקיפת ה-sandbox ב-10 ביולי. קומיט תיקון, 594f50f2, נכנס ב-9 ביולי — יום אחד לאחר הדיווח — ושכתב את sandbox_shell.py כך שמחרוזת הפקודה של המודל מפוענחת תחילה, וקידומת gosu מוחלת על כל פקודה פשוטה ולא רק על הראשונה, כאשר כל רשימת ארגומנטים מצוטטת מחדש כדי שההחלפה לא תוכל להימלט אל מעטפת האב. הכתיבה של Lasso מתארת את השינוי כהחלה של קידומת gosu "על כל פקודה פשוטה, לא רק על הראשונה".

הגרסה שנשאה אותה, v2.10.5-lts, פורסמה ב-6 באוגוסט 2026. ההתראה של GitHub עלתה ב-2 בספטמבר, NVD פרסמה את ה-CVE ב-21 בספטמבר, בלוק ה-SSVC של CISA נוסף ו-GBHackers דיווח ב-22 בספטמבר, והפרסום של Lasso עצמה הופיע ב-10 בספטמבר — באמצע הרצף הזה, לא בהתחלה. למפעיל שעוקב אחר תגי גרסה ולא אחרי פידים של התראות היה את התיקון כארבעה שבועות לפני האזהרה.

גבול הגרסה ראוי לתשומת לב רבה מזו שההתראה מעניקה לו, מפני ששני המקורות העיקריים חלוקים, והמאגר מכריע את השאלה. בשדה הטופס של ההתראה רשומות הגרסאות המושפעות כ-"<= 2.10.3-lts", עם הערה שהדבר אומת ב-2.10.3-lts ושהנתיב הפגיע "כנראה" משפיע על כל הגרסאות שבהן סוכנים נבנים בדרך זו. התיעוד של Lasso עצמו מציין את הטווח המושפע כ-"<= 2.10.4-lts". התגים מאשרים את הטווח הרחב יותר: v2.10.4-lts, שיצאה ב-16 ביולי 2026, נושאת את אותו sandbox_shell.py בן 75 השורות כמו v2.10.3-lts, והקובץ המשוכתב בן 311 השורות מופיע לראשונה ב-v2.10.5-lts. מפעיל בגרסת 2.10.4-lts שקרא רק את הטווח שצוין בהתראה היה מסיק שהוא נמצא מחוצה לו. לא כך היה המצב.

Rendered vertical timeline card with the kicker 'MAXKB · CVE-2026-77521' and the title 'Reported, fixed, released, disclosed', subtitled that the dates come from Lasso Security's disclosure timeline, the repository's release tags and commit metadata, the NVD record and GBHackers, and that every date is a single day. Ten dated entries run down a single spine: 8 July 2026, reported privately to 1Panel-dev through GitHub's advisory channel; 9 July 2026, fix commit 594f50f2 rewrites sandbox_shell.py and the vendor asks for a container proof of concept; 10 July 2026, the container proof of concept and the sandbox bypass supplied; 16 July 2026, v2.10.4-lts released, still carrying the 75-line unpatched sandbox_shell.py; 6 August 2026, v2.10.5-lts, the fixed release with a 311-line wrapper and gosu applied to every simple command; 2 September 2026, advisory GHSA-f36j-f34j-h3rx published with CVSS 10.0; 10 September 2026, Lasso Security publishes MaxKBypass; 21 September 2026, NVD publishes CVE-2026-77521, with the CISA SSVC added the next day and GBHackers reporting; 15 October 2026, v2.10.7-lts flips the code default SANDBOX from 0 to 1; 22 October 2026, v2.10.8-lts still builds the agent with SandboxShellBackend and still omits execute. A dark band at the foot headed 'The gap' reads that the fixed release preceded the advisory by 27 days, that v2.10.4-lts was released a week after the fix commit and does not contain the fix, and that the execute tool has never been gated because the approval map at v2.10.8-lts still names only write_file, read_file and edit_file. A footer reads 'Card rendered by OrcaRouter.' The OrcaRouter logo is composited in the bottom-right corner.

מה שהתיקון לא עשה

מה ש-2.10.5-lts מתקן הוא ה-wrapper: הוא כבר לא בונה מחרוזת shell אחת תחת root. מה שהוא לא עושה הוא שום דבר בנוגע לכלי. קריאה ישירה של המאגר בתג v2.10.8-lts, שפורסם ב-22 באוקטובר 2026, מראה�ה-agent עדיין נבנה עם backend=SandboxShellBackend ו-interrupt_on עדיין נושא בדיוק שלושה מפתחות — write_file, read_file ו-edit_file — ללא execute. שתי הצעות התיקון הראשונות של ה-advisory, לבנות על backend ללא הרצה כברירת מחדל ולהוסיף "execute": True למפת האישורים, אינן קיימות במהדורה ההיא.

ההמלצה לכשל סגור (fail-closed) נכנסה מאוחר יותר, ב-v2.10.7-lts, והיא חשובה במיוחד עבור מצב הפריסה שהיה במצב הגרוע ביותר. היא פורסמה ב-15 באוקטובר 2026 ומשנה את השורה ב-sandbox_shell.py מ-CONFIG.get("SANDBOX", 0) ל-CONFIG.get("SANDBOX", 1). התקנה ממקור או על חומרה חשופה שמעולם לא הגדירה את המשתנה מפעילה כעת את העטיפה כברירת מחדל במקום להשאירה כבויה, וזו ההמלצה "להיכשל סגור בפריסות שאינן מבוססות מכולות" במובן הצר. הייעוץ ביקש יותר מזה תחת אותה כותרת — שזרימת הביצוע (execute-capable flow) תסרב לעלות כאשר סביבת ההרצה של ארגז החול (sandbox runtime) אינה זמינה — וביקש בנפרד שהעטיפה לעולם לא תבנה מחרוזת פקודה עבור מעטפת root. בצד המכולות, עובדה ולא המלצה: לא installer/Dockerfile ולא installer/Dockerfile-base נושאים הוראת USER בתג v2.10.8-lts, כך שתמונת האפליקציה עדיין עולה כ-root.

בקריאה משותפת, מצב התיעוד נכון ל-28 באוקטובר 2026 הוא זה. המחצית השנייה של הפגיעות — ארגז החול שנקודה-פסיק יצאה ממנו — סגורה, וברירת המחדל מסוג fail-open בפריסות על מארח סגורה. המחצית הראשונה, כלי execute שמגיע עם אובייקט backend ואינו מפתח במפת האישורים, היא עדיין הדרך שבה MaxKB בונה עוזר עם תמיכה בכלים. עצת התיקון של החוקרים עצמם הייתה המצומצמת: לשדרג ל-2.10.5-lts ואילך, ולהריץ את גרסת ה-Docker עם ארגז החול מופעל. GBHackers העבירו את אותה הוראה בתוספת רשימה רחבה יותר למנהלים — להשבית קצוות סוכן בעלי יכולת shell אלא אם נדרשת הרצת קוד במפורש, לדרוש אישור אנושי לפני כל פעולת execute, להריץ מכולות כ-non-root, ולהתייחס לדפים שנסרקו, למסמכי RAG ולהעלאות כקלט לא מהימן.

רשומת MaxKB האחרת מאותה אצווה של ספטמבר

הרשומה השנייה של MaxKB מאצווה זו היא באג אחר עם סוף גרוע יותר. CVE-2026-77516, שפורסם גם ב-NVD ב-21 בספטמבר 2026, הוא עקיפת הרשאות ולא הזרקת פקודה: מגרסה 2.0.0 עד 2.9.2, חבר מרחב עבודה בתפקיד הנמוך ביותר, שנשללה ממנו במפורש גישה לכלי דרך WorkspaceUserResourcePermission, עדיין יכול היה לקשור את המזהה של אותו כלי דרך tool_ids, skill_tool_ids או mcp_tool_ids ולהריץ אותו דרך מסלול השיגור של סוכן או תהליך עבודה. מסלול השיגור אינו מיישם מחדש את ההרשאה לכל כלי שנתיבי הכלי הייעודיים אוכפים, והרצת כלי מפענחת init_params בצד השרת, כך שהקורא מקבל אישורי גישה שהכלי שאליו נשללה גישתו נושא. הציון שלו הוא 5.4, והתיאור של NVD מסתיים במשפט ש-CVE-2026-77521 אינו צריך לשאת: "לא זמינה גרסה מתוקנת נכון למועד סקירה זו."

הניגוד הוא החלק השימושי עבור כל מי שממיין את השניים. לפגם שקיבל ציון 10.0 היה תיקון שהועלה תוך יום ושוחרר חודש לפני שהוא פורסם. לפגם שקיבל ציון 5.4 לא פורסמה גרסה מתוקנת בזמן פרסום ה-CVE שלו.

Abstract illustration on a dark navy field: a tall translucent shelf holds a row of small pale gate symbols, and a wide unbroken corridor runs beneath the shelf from left to right with nothing standing in it. At the corridor's midpoint a thin amber line drops down from the shelf above and joins the corridor floor, and a small cluster of glowing key-shaped tokens rests just past the join, out of reach of the gates. No text, no people, no organisation logos, no literal depiction of any real system.

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