כשמודול WebAssembly ניגש לזיכרון, המנוע בודק קודם שהכתובת שביקש נמצאת בתחום שהוקצה לו. בגרסאות Wasmtime מ-32.0.0 ואילך, ועל מעבדי ARM, הבדיקה הזאת יכולה לבדוק כתובת אחת בזמן שהגישה בפועל מתבצעת לכתובת אחרת. הציון הוא 9.0 מתוך 10 בסולם CVSS 4.0, לניצול דרושים כמה תנאים במקביל, ולא ידוע על ניצול בשטח.
מה החולשה?
הבידוד של WebAssembly עומד על רעיון אחד פשוט. לאורח יש אזור זיכרון משלו, ולפני כל גישה המנוע מוודא שהכתובת שביקש נופלת בתוך האזור הזה. זאת בדיקת גבולות, והיא השומר בשער.
השמירה הזאת תקפה כל עוד מתקיים תנאי אחד שנראה מובן מאליו: שהכתובת שנבדקה היא אותה כתובת שנפתחת בסוף. כאן בדיוק נקרע הקשר. לפי הרשומה נוצרים שני חישובים נפרדים של אותה כתובת, אחד שמוזן לבדיקה ואחד שמוזן לגישה, ושניהם מגיעים לתוצאות שונות. האורח עובר את הבדיקה כחוק, ואז ניגש למקום אחר לגמרי. זה כמו מאבטח שבודק את התעודה של מי שעומד מולו, ואז מכניס את מי שעומד בצד.
מה שמייצר את הפער הוא טעות קטנה בשלב התרגום לקוד מכונה. Cranelift מזהה תבניות של חישובי כתובת ומחליף כל תבנית בקוד יעיל שמתאים לה. אחת התבניות היא כתובת בסיס ועוד מפתח שמוכפל בגודל קבוע, וכדי להחליט אם התבנית מתאימה המהדר בודק את הקבוע הזה דרך מסכה. המסכה מוגדרת לא נכון, ולכן המהדר מזהה התאמה גם במקרים שבהם לא היה אמור, ומייצר תרגום שסוטה מהמשמעות המקורית. הרשומה מציינת שהתוצאה יכולה להיות גישה לכתובת רחוקה הרבה יותר מזו שהתכוונו אליה, כי החישוב הנכון היה אמור לגלוש ולחזור לערך קטן.
התוצאה הסופית היא מה שנקרא פרימיטיב קריאה וכתיבה שרירותיות, כלומר יכולת לקרוא ולכתוב בכל מקום בזיכרון של המארח ולא רק באזור של האורח. זאת כבר יציאה מלאה מהבידוד ולא שיבוש מקומי. הסיווג הרשמי הוא CWE-125, קריאה מחוץ לתחום, והוא מתאר את נקודת הפתיחה יותר מאשר את מה שאפשר להגיע אליו ממנה.
מי מושפע?
כאן הרשומה עושה משהו שלא תמיד קורה, והיא מפרטת רשימת תנאים ומדגישה שכולם צריכים להתקיים יחד. זה משנה את התמונה, כי חולשה שנשמעת הרסנית מתבררת כתלויה בתצורה מסוימת שלא כל אחד מריץ.
התנאי הראשון הוא הארכיטקטורה: aarch64, כלומר ARM בגרסת 64 ביט.
התנאי השני הוא סוג הזיכרון. מדובר רק בזיכרון ליניארי של WebAssembly בגרסת 64 ביט, או בתצורה שבה האפשרות Config::wasm_memory64 פעילה. על כך הרשומה אומרת במפורש ש-WebAssembly בגרסת 32 ביט אינו מושפע.
התנאי השלישי נוגע להגנות שבדרך כלל פעילות. צריך שהגנות Spectre יהיו כבויות, או שמלכודות מבוססות אותות יהיו כבויות. הרשומה גם מסבירה את הקשר בין השתיים: כשהגנות Spectre פעילות, התבנית הבעייתית כלל אינה נוצרת, וכיבוי המלכודות מכבה אוטומטית גם את הגנות Spectre. כלומר שתי הדרכים להיות חשוף עוברות דרך אותה הגדרה.
טווח הגרסאות שהרשומה מונה הוא מ-32.0.0 ועד 36.0.7, מ-37.0.0 ועד 42.0.2, ובנוסף הגרסה 43.0.0 עצמה. הגרסאות המתקנות הן 36.0.7, 42.0.2 ו-43.0.1.
כמו בשאר החולשות במנוע הזה, זה עניין של מי שמפעיל תשתית ולא של משתמש קצה. מה שכן, כאן רשימת המקורות מראה שהחולשה נכנסה גם למעקב של הפצות לינוקס: ל-Red Hat יש רשומת מעקב ולצידה דיווח באגים. מי שמקבל את Wasmtime כחבילה של ההפצה, ולא ישירות מהפרויקט, צריך לעקוב דווקא אחרי הערוץ הזה.
האם מנוצלת בפועל?
אין אינדיקציה לניצול. הקטלוג שמנהלת סוכנות הסייבר האמריקאית CISA, ובו חולשות שאומת שתוקפים עושים בהן שימוש, אינו כולל את החולשה הזאת.
פרט אחד בתאריכים שווה מבט. הרשומה פורסמה כבר ב-9 באפריל 2026, והעדכון האחרון שלה הוא מ-26 באוקטובר 2026. יותר מחצי שנה של חשיפה פומבית בלי דיווח ניצול אינה הוכחה לכלום, אבל היא מתיישבת היטב עם רשימת התנאים שלמעלה. צירוף של ארכיטקטורה מסוימת, מצב זיכרון מסוים והגנות שכובו הוא לא מה שמוצאים בכל התקנה.
מה עושים?
1. עדכנו לגרסה המתקנת בענף שלכם: מענף 32 עד 35 אל 36.0.7, מענף 37 עד 41 אל 42.0.2, ומ-43.0.0 אל 43.0.1.
2. אם אתם לא יכולים לעדכן מיד, עברו על שלושת התנאים ובדקו אם אתם בכלל בטווח. ארכיטקטורה שאינה ARM, או עבודה עם זיכרון WebAssembly בגרסת 32 ביט, מוציאות אתכם מהתמונה בלי שתעשו דבר.
3. בדקו במיוחד אם כיביתם הגנות Spectre או מלכודות מבוססות אותות. אלה הגדרות שמכבים לפעמים כדי להרוויח ביצועים, ולפי הרשומה הכיבוי הזה הוא אחד התנאים לחשיפה. אם כיביתם אותן ואין לכם סיבה מחייבת, החזרתן למצב פעיל מסירה את התנאי.
4. אם אתם מקבלים את Wasmtime דרך הפצת לינוקס, בדקו את מצב החבילה אצל הספק. רשומת המעקב של Red Hat היא נקודת פתיחה טובה לסביבות כאלה.
5. לפני שאתם מסמנים את עצמכם מחוץ לטווח, עברו על רשומת הייעוץ הרשמית של הפרויקט. היא מפרטת את התנאים במלואם, והיא המקום לבדוק מולו תצורה שאינכם בטוחים לגביה.