ב-Incus, מערכת לניהול מכולות ומכונות וירטואליות על שרת, יש הגדרה שמעבירה אפשרויות אל הפקודה שמפרמטת נפח אחסון. לפי הרשומה, משתמש שמוגבל לפרויקט אחד יכול לקבוע את ההגדרה הזאת בעצמו, ודרכה להוסיף דגלים לפקודה שרצה בהרשאות root. הציון הוא 9.0 מתוך 10 בסולם CVSS 4.0, התיקון נמצא בגרסה 7.5.0, ואין דיווח על ניצול.

מה החולשה?

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

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

את ההרצה עצמה הוא מזמן בצעד שני. הוא קובע את ההגדרה על נפח, ואז מבקש העתקה או הזזה אל מאגר שמפרמט. באותו רגע mkfs רצה, בהרשאות root, עם הדגלים שהוא בחר.

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

הדירוג, בסולם CVSS 4.0, מסמן שהתקיפה מגיעה מהרשת, שנדרשות הרשאות נמוכות ושיש תנאים נוספים שצריכים להתקיים. מה שמעלה אותו ל-9.0 הוא הסימון של ההשפעה מחוץ לרכיב עצמו: גבוהה בסודיות, בשלמות ובזמינות של המערכת שמסביב. זה מה שצפוי כשהפקודה שמושפעת רצה כ-root על המאחסן.

מי מושפע?

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

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

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

האם מנוצלת בפועל?

אין דיווח על ניצול, והחולשה אינה מופיעה בקטלוג ה-KEV של CISA, סוכנות הסייבר האמריקאית, שמרכז את החולשות שיש עליהן ראיות לניצול בשטח.

הרשומה חדשה, היא עלתה ל-NVD ב-22 באוקטובר 2026. לצד הודעת האבטחה של המפתחים מופיעה בה גם רשומה של vulncheck, ושתיהן מתארות את הנתיב בשמות המדויקים: ההגדרה, הפעולות שדרכן קובעים אותה, והפקודה שבסוף.

מה עושים?

1. עדכנו ל-Incus 7.5.0 ומעלה. זו הגרסה שהרשומה מסמנת כמתוקנת, והטווח החשוף מתחיל ב-7.3.0.
2. עד לעדכון, מי שמשתמש בהגבלת פרויקטים כדי להפריד בין לקוחות או בין צוותים צריך להתייחס להפרדה הזאת כאל הפרדה שאינה מחזיקה. אם יש משתמשים מוגבלים שאינם זקוקים כרגע להרשאה ליצור ולהעתיק נפחי אחסון, זמנית אפשר להוריד להם אותה.
3. עברו על נפחי האחסון המותאמים שקיימים אצלכם ובדקו אם מוגדר באיזה מהם block.create_options שאינכם מכירים. ההגדרה הזאת היא הכלי של החולשה, וערך שאף אחד אצלכם לא שם שם הוא סיבה לבדוק הלאה.
4. אחרי העדכון, אם ההתקנה שירתה משתמשים שאינם מנהלים בזמן שהיתה בטווח, בדקו את המאחסן עצמו ולא רק את המכולות שעליו: תהליכים ומשימות מתוזמנות שאינכם מזהים, ומשתמשים שנוספו למערכת ההפעלה.
5. הפרטים המלאים נמצאים בהודעת האבטחה של Incus.