הרשומה מתארת חולשה ב-Incus, מערכת שמנהלת מכולות ומכונות וירטואליות, שמאפשרת למי שמשמש מקור להעברת מכונה לכתוב קבצים על מערכת הקבצים של המארח המקבל בהרשאות root. הציון הוא 9.4 מתוך 10, וגרסאות התיקון הן 6.0.7, 7.0.2 ו-7.5.0, כל אחת בקו שלה.
מה החולשה?
העברה של מכולה או מכונה וירטואלית בין שני מארחים היא בפועל העברה של נפח. המארח השולח אורז את מערכת הקבצים של המכונה ושולח אותה, והמארח המקבל פורש אותה אצלו ומניח את הקבצים במקום שייעד להם.
בתוך מערכת קבצים אפשר להניח גם קישור סמלי, כלומר רשומה שאינה קובץ אלא מצביע למקום אחר. כשתוכנה כותבת אל קישור סמלי בלי לבדוק לאן הוא מפנה, הכתיבה נוחתת ביעד של המצביע ולא במקום שבו הקישור יושב. זה הכשל שהסיווג CWE-59 מתאר.
התרגיל שהרשומה מתארת בונה בדיוק על זה. מקור העברה זדוני מרכיב את הזרם שהוא שולח, ב-rsync או ב-btrfs receive, כך שיכיל קישור סמלי. הדוגמה שהרשומה נותנת היא קישור בשם rootfs שמצביע אל ראש מערכת הקבצים של המארח, כלומר אל הנתיב /. המארח המקבל פורש את הנפח, כותב לתוך מה שנראה לו כמו תיקיית המכונה, והקבצים נוחתים על המארח עצמו. מכיוון שהפרישה נעשית בהרשאות root, הקבצים נכתבים כ-root.
כתיבת קבצים שרירותיים כ-root על מארח אינה נשארת כתיבת קבצים. היא הדרך להחליף תוכן שהמערכת מריצה או סומכת עליו, והרשומה אכן מנסחת את התוצאה כהשתלטות מלאה על המארח.
הווקטור מוסיף שתי נקודות. הראשונה, נדרשות הרשאות ברמה נמוכה ולא גישה חופשית: צריך להיות בעמדה של מקור העברה כלפי המארח המקבל. השנייה, הפגיעה חורגת מהרכיב הפגיע עצמו, וזה מדויק כאן, כי היעד אינו Incus אלא המערכת שהוא רץ עליה.
מי מושפע?
שלושה קווי גרסאות, לפי הרשומה: כל גרסה שלפני 6.0.7, גרסאות מ-6.1.0 שלפני 7.0.2, וגרסאות מ-7.1.0 שלפני 7.5.0.
התנאי המעשי הוא אם המארח שלכם מקבל העברות של מכונות, וממי. מארח שמקבל מכונות רק ממארחים שאתם עצמכם מפעילים נמצא במצב שונה לגמרי ממארח שמקבל מכונות ממקור שאינכם שולטים בו, למשל בסביבת אירוח שאליה לקוחות מעבירים מכונות פנימה. החולשה הזאת מניחה מקור עוין, ולכן השאלה מי מורשה לשלוח אליכם מכונה היא כאן שאלת האבטחה המרכזית.
בישראל Incus מופיע אצל ספקי אירוח, צוותי פלטפורמה, מעבדות ומי שמריץ מכולות על שרת משלו במקום בענן מנוהל. זה אינו קהל רחב, אבל ההקשר שבו הוא רלוונטי מוגדר היטב.
האם מנוצלת בפועל?
אין לה רשומה בקטלוג החולשות המנוצלות בפועל של CISA, ולא ידוע על ניצול.
החולשה פורסמה ב-NVD ב-22 באוקטובר 2026, והמקורות שהרשומה מפנה אליהם הם מאגר הקוד של הפרויקט ורשומה אצל VulnCheck. כלומר הכשל זוהה ותוקן בתוך הפרויקט.
מה שכן, המסלול שהרשומה מתארת אינו דורש כלים מיוחדים. קישור סמלי בתוך נפח הוא דבר שאפשר להכין בשורה אחת, והרשומה אף נוקבת בשם שבו נבנתה הדוגמה.
מה עושים?
1. עדכנו לגרסת התיקון של הקו שלכם: 6.0.7, 7.0.2 או 7.5.0.
2. בררו מי יכול להעביר מכונות אל המארח שלכם. העברה ממארח שאתם מפעילים היא סיפור אחד, והעברה ממקור חיצוני היא הסיפור שהחולשה הזאת בנויה עליו. אם אין לכם צורך לקבל העברות ממקורות חיצוניים, סגרו את האפשרות.
3. אם קיבלתם העברות ממקור שאינו בשליטתכם בזמן שהרצתם גרסה מושפעת, בדקו את המארח. חפשו קבצים שנכתבו כ-root ושאינכם יכולים להסביר, בעיקר בתיקיות שמהן המערכת טוענת תוכן והגדרות, והשוו את זמני הכתיבה שלהם למועדי ההעברות.
4. אם מצאתם משהו כזה, התייחסו למארח כולו כאל מערכת שנפרצה ולא רק כאל מערכת שצריך לעדכן. הרשומה מנסחת את התוצאה כהשתלטות על המארח, וזאת נקודת הפתיחה הנכונה לבדיקה.