Wasmtime מריצה קוד WebAssembly בתוך תא מבודד, כדי שאפשר יהיה להריץ קוד שהגיע ממקור שאינו מהימן בלי לתת לו את המכונה. בגרסאות שלפני 36.0.19 ושלפני 43.0.0 יש במהדר הפנימי שלה באג ספירה שמאפשר לקוד כזה לצאת מהתא. הציון הוא 9.9 מתוך 10, התיקון נמצא בשתי הגרסאות האלה, ולא ידוע על ניצול בשטח.

מה החולשה?

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

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

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

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

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

מי מושפע?

כל מי שמריץ Wasmtime בגרסה שקודמת ל-36.0.19 או שקודמת ל-43.0.0. שימו לב שאלה שני ענפי תחזוקה נפרדים ולא רצף אחד, כך שהשאלה הראשונה היא באיזה ענף אתם ורק אחריה מה המספר.

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

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

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

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

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

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

מה עושים?

1. בררו באיזה ענף אתם, ואז עברו ליעד המתאים לו: מענף 36 אל 36.0.19, ומהענף החדש אל 43.0.0. אל תקפצו בין ענפים רק כדי להגיע למספר גבוה יותר, כי זה שינוי גדול בהרבה מהתקנת תיקון.

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

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

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