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

ב-22 באוקטובר פרסם פרויקט TianoCore, שמתחזק את edk2 (קוד הייחוס הפתוח שרוב יצרני הקושחה בונים עליו את ה-UEFI שלהם), התראת אבטחה על חולשה שקיבלה אצלו ציון 9.5 בגרסה 4 של CVSS. המזהה הוא CVE-2026-97631. את החולשה מצאו Alex Matrosov מ-Anthropic ו-Dan Holmes-Mitra מגוגל, ששלחו גם את התיקון המוצע. הקוד הבעייתי עצמו לא חדש: הוא נכנס ל-edk2 בייבוא הגדול של רכיבי הרשת בשנת 2010, 142 קבצים בקומיט אחד, ומאז הוא שם.

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

למה הקושחה בכלל מדברת ברשת

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

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

504 בתים, ושני מקומות שסופרים לא נכון

כשהדרייבר מנהל אתחול רשת הוא משאיר בקשת קליטה פתוחה להודעות שגיאה של פרוטוקול ICMP, אותן הודעות "היעד לא זמין" או "החבילה גדולה מדי" שנתבים מחזירים כשמשהו בדרך נכשל. כל הודעה כזאת מועתקת לשדה בשם Mode.IcmpError במבנה הנתונים הפרטי של הדרייבר, ולשדה הזה יש גודל קבוע: 504 בתים.

לפי ההתראה, חישוב הגבולות שגוי בשני המסלולים במקביל, ב-PxeBcIcmpErrorDpcHandle שמטפל ב-IPv4 וב-PxeBcIcmp6ErrorDpcHandle שמטפל ב-IPv6. הודעות ארוכות מ-504 בתים מועתקות אל השדה בכל זאת. לטעות הזאת מצטרפת שנייה: מצביע היעד מתקדם לפי האורך המצטבר של ההודעה ולא לפי האורך של כל מקטע בנפרד, כך שההעתקה זוחלת קדימה גם כשאין לה לאן. והחלק שהופך את שתיהן למעשיות: שום שלב מוקדם יותר בנתיב הקליטה לא מגביל את אורך ההודעה.

התנאים שההתראה מונה קצרים. המכונה צריכה להיות בתוך אתחול PXE, מעל IPv4 או IPv6, והתוקף צריך לשלוח אליה הודעת שגיאת ICMP אחת לכתובת שהלקוח קיבל. אין כאן סיסמה לנחש ואין הרשאה לבקש.

אז מה קורה כשההודעה מגיעה?

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

השנייה דורשת מהתוקף לדעת באיזה build של קושחה מדובר. אם הוא יודע, הוא יכול לשתול באותה חבילה עצמה מבנה שההתראה מכנה counterfeit event, event מזויף: רשומה שנראית לקושחה כמו אירוע תקין שממתין לטיפול, ומצביעה על הבתים שהתוקף שלח. כשהקושחה קוראת ל-CoreSignalEvent() כדי להודיע על האירוע, היא מריצה את מה שהתוקף שם שם, בשלב DXE. ההתראה מסמנת את החולשה בשלושה מזהי CWE, ביניהם כתיבה מחוץ לתחום וחישוב שגוי של גודל באפר.

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

התיקון שפורסם שלושה שבועות לפני ההתראה

לפי הדיווח של The Hacker News, התיאום בין החוקרים ליצרנים היה אמור להסתיים בינואר 2027. הוא לא החזיק. ב-28 בספטמבר נפתחה ב-edk2 בקשת מיזוג ציבורית שכותרתה אומרת בפירוש "Fix ICMP buffer overflow in IPv4/IPv6 handle (CVE-2026-97631)", והתיאור שמתחתיה מסביר את הבאג במילים של מי שמתקן אותו: "לוגיקת העתקה שגויה בטיפול בשגיאות ICMP אפשרה לחבילות גדולות לכתוב מעבר לבאפר שהוקצה". חתימת ה-Signed-off-by על הקומיט היא של מפתח מכתובת דואר ב-ami.com, כלומר מאחד מספקי הקושחה הגדולים בשוק.

המזהה, המקום המדויק בקוד והתיקון עצמו היו אם כן פומביים שלושה שבועות ויותר לפני שההתראה יצאה. הבקשה ההיא נסגרה ב-14 באוקטובר ככפולה של בקשה מקבילה שפתח Michael Kinney, וזו מוזגה ל-master למחרת. התיקון עצמו צנוע: בדיקות גבולות, תיקון חישוב ההיסט, וקטיעה של חבילות גדולות מדי כשהשדה מתמלא. נוספה גם קריאת ZeroMem שמנקה את השדה לפני ההעתקה, כדי שמקטעים קצרים לא ישאירו אחריהם בתים ישנים, ונוספו בדיקות אוטומטיות למסלולי IPv4 ו-IPv6.

אז מי חשוף, ולמה הציונים לא מסכימים

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

TianoCore נתנה 9.5, עם וקטור שמסמן גישה מהרשת ותנאים שצריכים להתקיים, כלומר חלון ה-PXE. רד האט נתנה לאותה חולשה 8.8 ב-CVSS 3.1, עם וקטור שמגדיר את וקטור התקיפה כרשת צמודה ולא כרשת פתוחה, ומסמנת את המדדים שלה כראשוניים ונתונים לבדיקה. ב-NVD וב-cve.org המדדים עדיין ריקים. מעקב האבטחה של דביאן מסמן את חבילת edk2 כחשופה ב-bookworm, ב-trixie וב-sid בלי גרסה מתוקנת, ומוסיף ל-trixie הערה יבשה אחת: no-dsa, "Minor issue". בקטלוג החולשות המנוצלות בפועל של CISA, בגרסה מ-27 באוקטובר, החולשה לא מופיעה.

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

ומי שהחליט בכל זאת לעדכן נתקל בבעיה שלישית. בדף הגרסאות של edk2 הגרסה היציבה האחרונה היא edk2-stable202608 מ-21 באוגוסט 2026, כלומר מלפני התיקון; שום גרסה יציבה עוד לא מכילה אותו. Project Mu של מיקרוסופט כבר הכניסה את התיקון לענפי הגרסאות שלה ושחררה תגים ב-26 באוקטובר. כל השאר תלוי ביצרן הלוח או השרת, שצריך לבנות קושחה חדשה ולהפיץ אותה. בתשובה ל-The Hacker News אמרה אינטל שאף אחד ממוצריה שנמצאים בתמיכת אבטחה אינו ידוע כחשוף, אבל לוחות של יצרנים אחרים עשויים להכיל את הקוד.

הרקע לכל זה מוכר למי שעוקב אחרי האזור. בינואר 2024 פרסמו Francisco Falcon ו-Iván Arce מ-Quarkslab את PixieFail, תשע חולשות באותה שכבת רשת של edk2, רובן בנתיב ה-DHCPv6 שמשמש את PXE. אותו קוד, אותו שלב אתחול, שנתיים וחצי הבדל.

מה זה אומר בפועל

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

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