CVE-2026-98432: ל-Ubuntu ול-RHEL עדיין אין תיקון, ומודל Claude כבר כתב את האקספלויט

שתי העובדות درباره CVE-2026-98432 אינן מתיישבות בנוחות זו עם זו. מדובר ב-use-after-free בלחיצת היד של TCP/IPv4 בליבת לינוקס, שניתן להגיע אליו דרך הרשת ללא התחברות וללא אינטראקציה, וצוות ה-CVE של הליבה העניק לו ציון 9.8. נכון ל-30 באוקטובר 2026, לאובונטו אין תיקון שפורסם ל-22.04, 24.04, 26.04 או 26.10, ורד האט מפרטת את RHEL 8, 9 ו-10 כמושפעות, ללא תיקון וללא מיטיגציה מאושרת. העובדה השנייה היא שב-27 באוקטובר פרסמה Anthropic מחקר שלפיו מודל Claude שלא שוחרר הפיק הוכחת היתכנות עובדת להשגת גישת root מרחוק ללא אימות מול שרת עם מאזין MPTCP — כ-48 דקות לדליפת כתובת בקרנל וחמש דקות נוספות עד להרצת פקודות.

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

הבאג, בפסקה אחת

כאשר חיבור TCP נמצא בהקמה, אפשרויות IP המצורפות לחבילה הנכנסת מועברות לסוקט החדש במקום להיות מועתקות. אם לחיצת היד משדרת מחדש, החבילה עשויה להיות מעובדת במעבד אחר מזה שבבעלותו מאגר האפשרויות — ואותו מעבד שני יכול לקרוא זיכרון שהמעבד הראשון כבר שחרר. מרוץ דומה קיים במסלול העברת הבקשה. הטווח המושפע מתחיל בקרנל 4.4, כלומר רוב המכונות שעדיין מריצות קרנל מתוחזק. התיקון במעלה הזרם, קומיט code>e3f33b0a1d89/code>, מעכב את שחרור מאגרי האפשרויות עד שאין עוד ליבה אחרת שיכולה להחזיק בהפניה.

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

שלושה ספקים, שלושה מספרי חומרה

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

• צוות CVE של הקרנל — 9.8, קריטי. נגיש מרשת, ללא צורך בהרשאות, ללא אינטראקציה.

• Red Hat — 8.1, חשוב. עמדת החברה היא שקשה לנצח במרוץ בפועל.

• Ubuntu — עדיפות גבוהה, ללא ציון מספרי שפורסם בעמודים שנבדקו.

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

למי יש פתרון, ולמי אין

נכון ל-29–30 באוקטובר, התמונה אינה אחידה באופן שתופס אנשים שמניחים שקרנל יציב משמעו קרנל מתוקן.

• Debian 12 bookworm — תוקן בגרסה 6.1.190-1 באמצעות DLA-4841-1.

• Debian 13 trixie — תוקן בגרסה 6.12.113-1 באמצעות DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — אין תיקון ששוחרר; העבודה בעיצומה.

• Ubuntu 16.04, 18.04, 20.04 — פגיע, לא פורסם תיקון.

• RHEL 8, 9, 10 ו-OpenShift 4 — מושפעים, אין תיקון, ואין הקלה מאושרת על ידי Red Hat.

• RHEL 6 ו-7 — לא מושפע.

• Amazon Linux 2023 — דווח כי kernel 6.18 תוקן; Oracle Linux UEK דווח שתוקן; SUSE מדווחת שחלק מהמהדורות תוקנו ואחרות עדיין בבדיקה, מבלי לנקוב בשמות הגרסאות.

מהדורות יציבות במעלה הזרם הכוללות את התיקון הן 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ו-7.3 — וזוהי הרשימה שכדאי לבדוק מול הבנייה שלכם אם אתם מקמפלים את הקרנל בעצמכם במקום לקחת חבילת הפצה.

למה MPTCP כל הזמן עולה

הבאג אינו ייחודי ל-MPTCP, וכאן הרבה מהסיקור טועה. Red Hat מתייחסת לכל שירות TCP נגיש כאל טריגר אפשרי. מה ש-MPTCP מספק הוא מסלול מוכח, ומה שמספק את התעבורה הוא Go: גרסה 1.24 ואילך מפעילה multipath TCP כברירת מחדל עבור שקעי האזנה ב-Linux כאשר MPTCP מופעל בקרנל. צוות האבטחה של Go הזהיר מפני השילוב ב-29 באוקטובר.

אז "disable MPTCP" מסיר את הנתיב ש-Anthropic הדגימה, לא את הפגיעות. זהו צעד ביניים מוצדק עם הסתייגות מסוימת: כדאי ליישם אותו היום בשירותי Go, והוא אינו תחליף לקרנל מתוקן.

הבדיקות קצרות:

• code>ss -Mltnp/code> — הצג שקעים המשתמשים כעת ב-MPTCP.

• code>net.mptcp.enabled/code> — האם תכונת הליבה פעילה בכלל.

• code>net.ipv4.tcp_migrate_req — כבוי כברירת מחדל; אם הפעלתם אותו, כבו אותו שוב.

עבור Go בפרט, הגדרת code>GODEBUG=multipathtcp=0/code> בזמן ריצה, או שורת code>godebug/code> ב־code>go.mod/code>, מוציאה את הבינארי מהאפשרות.

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

מה ש-Anthropic פרסמה בפועל

המחקר צר וספציפי. מודל Claude שטרם פורסם, בהינתן ה-CVE ויעד עם מאזין MPTCP, הפיק שרשרת שדלפה כתובת קרנל בתוך כ-48 דקות והגיעה להרצת פקודות כחמש דקות לאחר מכן. Anthropic לא פרסמה את האקספלויט, ונכון ל-29 באוקטובר לא ספקים ולא רשומת ה-CVE דיווחו על תקיפות בשטח; הפגיעות אינה נמצאת בקטלוג ה-KEV של CISA. ב-30 באוקטובר פרסם מאגר GitHub של צד שלישי כלי מעבדה להפעלת מצב מירוץ ולדליפת זיכרון — רתמת שחזור, אך לא עד כדי הרצת קוד מלאה.

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

מה לעשות השבוע

• יש להחיל תיקון ולאתחל מחדש היכן שקיים פתרון. תיקון קרנל שמותקן אך לא בוצע אתחול מחדש אינו תיקון; יש לאמת באמצעות code>uname -r/code>.

• כאשר להפצה שלך אין טלאי — Ubuntu 22.04 עד 26.10, RHEL 8 עד 10 — החליטו כעת אם תיקחו טלאי חי מהספק, תעברו לגרסה מתוקנת, או תקבלו את החשיפה כאשר MPTCP כבוי בשירותי Go.

• יש למפות את החשיפה ל-MPTCP במקום להניח שהיא כבויה. ברירת המחדל השתנתה ב-Go, לא בקונפיגורציה שלך, ושינוי בברירת מחדל אינו נראה ב-diff של קונפיגורציה.

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

שתי השאלות שה-CVE הזה למעשה מעלה

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

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

מה שאסור לעשות הוא לסווג את זה תחת "להמתין לספק". העמוד של הספק עצמו אומר שאין עדיין למה להמתין.

הערת מקורות: המנגנון, טווח ההשפעה החל מגרעין 4.4, קומיט במעלה הזרם code>e3f33b0a1d89/code>, רשימת הגרסאות היציבות והנחיות המיטיגציה מגיעות מרשומת ה-CVE ומהתראות האבטחה של ההפצות שנקראו ב-30 באוקטובר 2026. דירוגי 9.8, 8.1 ו-High של Ubuntu הם של צוות ה-CVE של הגרעין, של Red Hat ושל Canonical בהתאמה. מצב הטלאים לכל הפצה מגיע מ-DLA-4841-1 ו-DSA-6568-1 של Debian, מדפי ה-CVE של Red Hat ו-Ubuntu, ומהצהרות הספקים באותו תאריך. ציר הזמן של הוכחת ההיתכנות, הנתונים של 48 דקות וחמש דקות, ותכונת הניסיון החוזר הם ממחקר של Anthropic מ-27 באוקטובר, שלא פרסם את ה-exploit. מאגר המעבדה מ-30 באוקטובר מתואר כמאגר של צד שלישי ואינו שלנו.