Zapscape (CVE-2026-64561): VM אחד, כל השרת

הקדמה: הפעם זה לא "עוד פגיעות קרנל"

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

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

ופרט מטריד נוסף: זו הפגיעות השנייה באותו אזור בקרנל, מאותו חוקר, בתוך חודש. לפניה הייתה Januscape ‏(CVE-2026-53359) בתחילת יולי באג נפרד לגמרי.

מה זה Zapscape בשתי דקות

הפגיעות התגלתה ודווחה על ידי חוקר האבטחה Hyunwoo Kim (@v4bel), והיא מסוג use-after-free שימוש בזיכרון שכבר שוחרר ב-shadow MMU של KVM/x86.

בקצרה על המנגנון: כשמכונה וירטואלית ניגשת לזיכרון, מישהו צריך לתרגם בין הכתובת שהיא חושבת שהיא ניגשת אליה לכתובת הפיזית האמיתית. בחומרה מודרנית המעבד עושה את זה בעצמו (EPT באינטל, NPT ב-AMD). אבל במצב אחד החומרה לא מספיקה: וירטואליזציה מקוננת מכונה וירטואלית שמריצה בתוכה מכונה נוספת. אז הקרנל חוזר לנהל את התרגום בתוכנה, בטבלאות משלו. זה מסלול קוד ותיק ומורכב שלא רץ אצל רוב המשתמשים ביום-יום ובדיוק שם יושב הבאג.

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

התיקון ב-upstream נכנס ב-21 ביולי 2026 (קומיט 2abd5287f083) והוא פשוט כמו הבעיה: להזיז את הבדיקה כך שתרוץ אחרי פינוי הדפים, בשני הנתיבים.

מה אפשר לעשות עם זה

הפרסום מתאר שלוש תוצאות, בסדר חומרה יורד: בריחה מ-guest ל-host עם הרשאות root (זו שהודגמה ב-PoC), הפלת השרת המאחסן כלומר השבתה של כל המכונות שרצות עליו, והסלמת הרשאות מקומית על שרתים שבהם /dev/kvm פתוח לכולם.

‏The Hacker News תיארה את מסלול הניצול שהודגם כך: “can run commands on the host with kernel, or root, privileges”

הנקודה שהכי חשוב להבין: גם בלי אף מכונה וירטואלית

בהפצות נפוצות מאוד בכללן CloudLinux 8, ‏8 LTS, ‏9, ‏9 LTS ו-10 קובץ ההתקן /dev/kvm מוגדר בברירת מחדל כ-0666. כלומר: כל משתמש בשרת יכול לפתוח אותו, וכל מי שיכול לפתוח אותו יכול ליצור מכונה וירטואלית. שרשרת התקיפה נראית כך:

1. תוסף וורדפרס פגיע, סיסמה חלשה או סקריפט PHP מיושן  והתוקף מריץ קוד בהרשאות של משתמש אתר רגיל.
2. המשתמש הזה פותח את /dev/kvm ובונה לעצמו מכונה וירטואלית זמנית.
3. בתוך המכונה הזאת הוא root בלי לגעת באף חשבון אחר ובלי exploit נוסף. הוא root כי זו המכונה שלו.
4. מתוך אותה מכונה הוא מנצל את Zapscape ותוקף את הקרנל של השרת האמיתי.

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

שלושת התנאים: האם אתם חשופים?

שלושה תנאים צריכים להתקיים יחד. אם אחד מהם לא מתקיים השרת לא חשוף במסלול הזה.

1. האם משהו על השרת יכול להשתמש ב-KVM?

ls -l /dev/kvm 2>/dev/null || echo "no /dev/kvm - module not currently loaded"

הרשאות crw-rw-rw- (מצב 0666) פירושן שכל משתמש בשרת יכול לפתוח את ההתקן.

2. האם וירטואליזציה מקוננת מופעלת?

# הערך החי, אם המודול כבר טעון:
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null    # kvm_amd על מעבדי AMD

# אם לא הודפס דבר המודול לא טעון. בדקו במה ישתמש כשייטען:
modinfo kvm_intel 2>/dev/null | grep -i nested             # kvm_amd על מעבדי AMD

‏Y או 1 = מופעל. התקיפה מחייבת שהמכונה של התוקף תיצור בתוכה מכונה נוספת בלי וירטואליזציה מקוננת השרשרת לא מתחילה.

3. איזה מעבד יש בשרת?

‏AMD בטווח, בלי תנאי נוסף. Intel רק כשהשרת חושף למכונות גם EPT בארבע רמות וגם בחמש, כלומר Ice Lake-SP ומעלה:

# שרתי Intel בלבד:
grep -w ept_5level /proc/cpuinfo

פלט ריק על שרת Intel = התנאי לא מתקיים.

גרסאות: מי נושא את הפגם, ומה כבר תוקן

‏CloudLinux 7 (קרנל 3.10) אינו פגיע הוא לא נושא את הכלל מ-5.9 שהופך את הפגם לניתן לניצול. פגיעים: CloudLinux 7h, ‏8, ‏8 LTS, ‏9, ‏9 LTS, ‏10 ו-CloudLinux for Ubuntu 22.04. מסלול המשתמש המקומי פתוח ב-8, ‏8 LTS, ‏9, ‏9 LTS ו-10 (שם /dev/kvm פתוח לכולם); ב-7h הוא מוגבל.

מצב התיקונים תצלום ל-11 באוגוסט 2026

לגבי livepatch: לפי המיפוי שפורסם, משפחת EL9 והפצות Ubuntu 24.04 ו-Debian 12 היו בשלב סקירה; EL8 ו-Ubuntu 22.04 הוכנו והמתינו לוולידציה; EL10 בתור. כיסוי livepatch חייב להתאים לבילד הקרנל המדויק אל תסירו מיטיגציה זמנית לפני אימות שהתיקון הוחל בפועל.

מבט מקצועי: כמה חמור זה באמת?

כאן יש חוסר הסכמה שכדאי להכיר, כי הוא ישפיע על איך שתדווחו על זה פנימית. Red Hat דירגה את Zapscape כ-Important עם CVSS 3.1 של 7.0, ותיארה את ההשפעה כחוסר יציבות ומניעת שירות בסביבות וירטואליות ולא כבריחה מ-guest ל-host. ה-NVD לא הקצה ציון בזמן הפרסום. החוקר, מנגד, מדגים בריחה מלאה עם הרשאות root.

‏TuxCare הדגישה שה-PoC שפורסם מריץ קוד כ-root על המאחסן, ולא סתם מפיל אותו:

“not just a panic that kills every co-tenant VM”

 TuxCare, ניתוח CVE-2026-64561

ומהצד השני  חשוב לא להגזים. הניתוח של Penligent מנסח את הגבול היטב: מדובר בפגיעות ש“not an unauthenticated network RCE against every Linux server” היא לא מנוצלת מרחוק, לא עוקפת אימות, ולא מסכנת כל שרת לינוקס. היא דורשת וירטואליזציה מקוננת, הרשאות קרנל במכונה התוקפת, ותנאי מעבד.

נכון לכתיבת שורות אלה לא אושר ניצול in-the-wild, והחוקר עצמו מתאר את ה-PoC כקוד הדגמה ולא כנשק מוכן לענן. CloudLinux דיווחה שבבדיקות שלה ה-PoC כפי שפורסם לא רץ נגד קרנלים שנבנו על ידה. אבל הם גם הוסיפו את ההסתייגות הנכונה:

“An exploit that does not run against our kernels today is not protection.”

Akos Vajda, ‏CloudLinux

העברית: התאמת exploit לקרנל ספציפי היא עבודה שגרתית לכל מי שמונע לעשות אותה. "ה-PoC לא רץ אצלנו" הוא נתון מרגיע להיום, לא תוכנית הגנה למחר. והמסקנה המעשית: אל תבנו את החלטת התיקון על הציון. ציון CVSS הוא ממוצע גלובלי; הסיכון שלכם הוא פונקציה של שלושת התנאים למעלה ושל מי בכלל מריץ קוד על השרתים שלכם.

מה עושים עכשיו צ'קליסט

1. לעדכן קרנל

אם יש גרסה מתוקנת להפצה שלכם זו התשובה הנכונה. תמיד.

# CloudLinux 9 / AlmaLinux 9 התיקון ביציב
dnf update 'kernel*'
reboot

2. אם השרת לא מריץ מכונות וירטואליות: להוציא את KVM מהמשחק

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

sudo modprobe -r kvm_intel kvm_amd kvm 2>/dev/null

printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
  | sudo tee /etc/modprobe.d/disable-kvm.conf

קראו את תוצאת הפקודה הראשונה לפני שממשיכים. "Module not found" או "not currently loaded" מצוין, זה הצפוי על שרת אחסון שיתופי. "Module is in use" משהו מחזיק את KVM פתוח (בדרך כלל מכונה שרצה), ואז עברו לסעיף 3. אימות: lsmod | grep kvm לא מחזיר כלום.

3. אם השרת כן מריץ מכונות וירטואליות

לכבות וירטואליזציה מקוננת (‏kvm_amd על AMD):

echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/zapscape.conf

להגביל את התקן KVM סוגר את מסלול המשתמש המקומי (לא את זה של דייר במכונה וירטואלית):

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger /dev/kvm

מי שצריך KVM באמת usermod -aG kvm <user>, ולא החזרת ההרשאות ל-0666.

4. לבדוק מי בכלל יכול להריץ קוד על השרת, ולתעד

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

הפיל שבחדר: הקצב

ב-מאמר על OVSwrap פרסנו את פגיעויות הקרנל של 2026 שדרשו התייחסות תפעולית. עברו עשרה ימים, וצריך להוסיף שורה:

תשעה אירועים בחמישה חודשים. ושתיים מהן Januscape ו-Zapscape באותו רכיב, מאותו חוקר, בהפרש של חודש.

ויש נתון שכמעט לא קיבל כיסוי: בין 2 ל-8 באוגוסט פורסמו כ-46 פגיעויות בקרנל (כולן תוקנו ב-stable, אף אחת לא 0-day) ושלוש מהן נוגעות באותו אזור של וירטואליזציה מקוננת: Zapscape עצמה, ‏CVE-2026-64562 (‏use-after-free ב-shadow VMCS) ו-CVE-2026-68081 (דליפת דפי host כשל-VM-Enter מקונן נכשל). כלומר: מי שמריץ וירטואליזציה מקוננת צריך את עדכון ה-stable המלא, לא patch נקודתי ל-Zapscape.

המשמעות התפעולית מתחדדת: "נתזמן ריסטארט לסוף השבוע" הוא לא לוח זמנים הוא הימור. חלון החשיפה נמדד היום בשעות; תהליך התחזוקה המסורתי נמדד בימים.

איפה SPD Kernel Shield נכנס לתמונה

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

‏SPD Kernel Shield נבנה בדיוק בשביל הפער הזה: הוא מחיל עדכוני אבטחה לליבת Linux על שרת שרץ, בזמן אמת, בלי ריסטארט ובלי חלון תחזוקה. סוכן על כל שרת בודק את הפיד באופן שוטף ומחיל את התיקון אוטומטית ברגע שהוא זמין במקום להמתין לזמן שנוח לכולם.

שתי בעיות שונות, כלי אחד

הבעיה הסייברית חלון החשיפה. התיקון מוחל מיד עם פרסום ה-patch ולא בעוד שבוע. השירות משתלב עם סורקי חולשות (Nessus, Qualys, Rapid7), כך שהסורק רואה את מצב האבטחה האמיתי כולל patches שהוחלו בזיכרון בלי False Positives על חולשות שכבר טופלו. יש תמיכה ב-UEFI Secure Boot ובסביבות FIPS-140: התיקון לא שובר את שרשרת האמון ולא נוגע ברכיבי ההצפנה שעברו ולידציה.

הבעיה התפעולית העלות האמיתית של "פשוט תעשו ריסטארט". אפס downtime, בלי ניתוק משתמשים ובלי פגיעה ברציפות עסקית. בלי תיאום בין מחלקות והודעות מראש ללקוחות עם SLA. בלי "reboot backlog" אותו צבר שרתים שממתין לתחזוקה כי אף פעם אין זמן טוב. וכשהקצב הוא פגיעות אחת לשבועיים, ההפרדה בין "דחוף" ל"מתוזמן" היא ההבדל בין צוות תפעול מתפקד לצוות שרוף.

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

uname -r                                        # מול גרסת המטרה של קו הקרנל
kcarectl --patch-info | grep 'CVE-2026-64561'   # אימות ברמת CVE

שאלות ותשובות

אנחנו לא מריצים מכונות וירטואליות בכלל. אנחנו בסדר?

לא בהכרח, וזו הנקודה המרכזית של המאמר. אם /dev/kvm פתוח לכתיבה לכל משתמש וזו ברירת המחדל בהפצות נפוצות משתמש רגיל או אתר שנפרץ יכולים לבנות מכונה וירטואלית זמנית ולתקוף את הקרנל מתוכה. הבדיקה בתנאי 1 תיקח 5 שניות.

ה-WAF שלנו עוצר את זה?

לא, ולא אמור. זו לא מתקפה שמגיעה דרך HTTP. WAF מגן על שכבת האפליקציה; Zapscape פועלת בשכבת מערכת ההפעלה.

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

אנחנו על CloudLinux 10 / ELS ואין עדיין קרנל מתוקן. מה עושים בינתיים?

נכון ל-11 באוגוסט 2026 זה אכן המצב, וזו לא סיבה לחכות. אם השרת לא מריץ מכונות וירטואליות הורידו את מודולי KVM וחסמו את טעינתם (סעיף 2 בצ'קליסט): מיטיגציה שסוגרת את שני המסלולים, לא דורשת ריסטארט, ולוקחת דקה. אם השרת כן מריץ מכונות הגבילו את /dev/kvm כדי לסגור לפחות את מסלול המשתמש המקומי.

אנחנו על Intel מדור קודם. זה מוציא אותנו מהתמונה?

לגבי Zapscape הספציפית כן, מעבדי Intel לפני Ice Lake-SP לא בטווח. אבל זו הגנה שנגזרת מהחומרה שיש לכם, לא מהחלטת אבטחה שקיבלתם. היא לא תעזור בפגיעות הבאה.

שורה תחתונה

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

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

אם אתם מנהלים שרתים בעצמכם, זה הזמן להפסיק להתייחס ל-live kernel patching כאל "נחמד שיהיה" ולהתחיל להתייחס אליו כאל תשתית בסיסית. בדיוק כמו גיבוי.

מקורות וקריאה נוספת

• המחקר המקורי, הפרטים הטכניים וה-PoC: ‏V4bel/Zapscape ב-GitHub  Hyunwoo Kim (@v4bel)
• הפרסום ברשימת oss-security: ‏seclists.org · התיקון: קומיט ‏2abd5287f083
• עדכוני אבטחה ומיטיגציות: ‏CloudLinux · TuxCare
• סיקור ודירוגים: ‏The Hacker News · ‏Red Hat · ‏NVD
• לא התקנתם Open vSwitch מעולם? אתם עדיין פגיעים OVSwrap
• zero downtime Live Kernel Patching ולמה זה שינה את כללי המשחק
• DirtyClone: כך חבילת רשת אחת מעניקה לתוקף הרשאות root

צוות SPD Hosting
support@spd.co.il