דילוג לתוכן הראשי
POUYAM
יצירת חשבון
אבטחה ברשת

CVE-2026-98432, פגם TCP בלינוקס: איך מגנים על שרתים

מאת עדכון אחרון 15 דקות קריאה

פורסם

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

בקצרה

CVE-2026-98432 היא באג מסוג use-after-free בטיפול של ליבת לינוקס בחיבורי TCP מעל IPv4, שדורג CVSS 9.8, קריטי [1]. הוא קיים מאז Linux 4.4 ותוקן בגרסה 7.3 ובכמה מהדורות יציבות [2]. תוקף מרוחק אינו צריך להתחבר כלל [1]. התקנת ליבה מתוקנת ואתחול המערכת הם התיקון המלא היחיד [6].

עיקרי הדברים

  1. CVE-2026-98432 פורסמה ב-15 באוקטובר 2026 על ידי צוות ה-CVE של ליבת לינוקס, עם ציון CVSS 3.1 של 9.8 (קריטי) ווקטור תקיפה דרך הרשת [1].
  2. הבאג נוסף בגרסה Linux 4.4 ותוקן בגרסאות 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ו-7.3 [2].
  3. לדברי Anthropic, הוכחת ההיתכנות שלה אפשרה לתוקף מרוחק להריץ פקודות כ-root בשרתי לינוקס שיש בהם מאזין Multipath TCP (MPTCP) [4], אבל Red Hat מציינת ש-MPTCP אינו תנאי הכרחי לניצול הפגיעות [6].
  4. נכון ל-3 בנובמבר 2026, Red Hat, Debian ו-AlmaLinux כבר הפיצו ליבות מתוקנות לגרסאות הנתמכות שלהן [7][9][10], ואילו Ubuntu מציינת שהתיקונים שלה עדיין בעבודה [8].
  5. כללי חומת אש שמשליכים מנות TCP מעל IPv4 הנושאות אפשרויות IP מצמצמים את החשיפה, אבל לדברי Red Hat ו-Ubuntu אינם מונעים ניצול לחלוטין [6][8].
  6. נכון ל-3 בנובמבר 2026 הפגיעות אינה מופיעה בקטלוג הפגיעויות המנוצלות הידועות של CISA [14], ו-Akamai מציינת שאינה מכירה ניצול ציבורי עובד [11].
בעמוד הזה 12 חלקים
  1. מהי CVE-2026-98432?
  2. איך הפגיעות עובדת?
  3. מה חשפה Anthropic, ומה התפקיד של MPTCP?
  4. אילו גרסאות ליבה והפצות תוקנו?
  5. איך בודקים אם שרת פגיע?
  6. איך מתקנים או מצמצמים את CVE-2026-98432?
  7. האם CVE-2026-98432 מנוצלת בפועל?
  8. מה צפוי בהמשך?
  9. טעויות נפוצות
  10. שאלות נפוצות
  11. מילון מונחים
  12. מקורות

מהי CVE-2026-98432?

CVE-2026-98432 היא פגיעות בליבת לינוקס, הלב של מערכות ההפעלה מבוססות לינוקס. הכותרת הרשמית שלה היא ipv4: free inet_opt and ireq_opt after an RCU grace period [1]. צוות ה-CVE של ליבת לינוקס הקצה לה את המזהה ופרסם את הרשומה ב-15 באוקטובר 2026 [1]. לפי הרשומה, ציון הבסיס שלה ב-CVSS 3.1 הוא 9.8, דירוג קריטי [1].

הפגם הוא מסוג use-after-free (שימוש לאחר שחרור): תוכנה ממשיכה להשתמש בקטע זיכרון אחרי שכבר שוחרר, ולכן ייתכן שהזיכרון כבר מכיל נתונים אחרים. במקרה הזה הוא נמצא בקוד שמטפל בבקשות נכנסות לחיבורי TCP מעל IPv4 [10]. וקטור ה-CVSS הוא AV:N/AC:L/PR:N/UI:N. המשמעות היא שהתקיפה מתבצעת דרך הרשת, המורכבות שלה נמוכה, והיא אינה דורשת הרשאות או פעולה כלשהי של המשתמש [1].

הבאג קיים מאז Linux 4.4, שבה הוא נכנס עם ה-commit 079096f103fa [2]. תיקון שכתב אריק דומזה (Eric Dumazet) נכנס לקוד ב-5 באוקטובר 2026 והוא כבר חלק מהליבה הראשית (mainline) [3]. התיקון הועבר גם לענפי הגרסאות היציבות שעדיין מתוחזקים [2][4].

אילו מערכות מושפעות?

לדברי Red Hat, הפגיעות משפיעה על כל מערכת שמריצה ליבה פגיעה ושרשת TCP מעל IPv4 פעילה בה. המערכות החשופות ביותר באופן ישיר הן אלה שמקבלות חיבורי TCP נכנסים [6]. AlmaLinux ממליצה להתייחס כחשופה לכל מערכת שמקבלת חיבורי TCP מעל IPv4 מרשתות לא מהימנות [10]. הבעיה העיקרית אינה משפיעה על IPv6 [2].

איך הפגיעות עובדת?

חיבור TCP מתחיל בלחיצת יד: הלקוח שולח מנת SYN, השרת עונה במנת SYN-ACK, והלקוח מאשר. מנת SYN יכולה לשאת אפשרויות IPv4, כלומר שדות נוספים ורשותיים בכותרת ה-IP. שתי דוגמאות לכך הן Record Route ו-Timestamp [1].

לפי התיאור של מפתחי הליבה, הפונקציה tcp_v4_syn_recv_sock() מעבירה את האפשרויות השמורות לשקע הצאצא החדש בלי להעתיק אותן [2]. בינתיים, ליבת מעבד אחרת יכולה לטפל במנת SYN חוזרת של אותה בקשה ולבנות מנת SYN-ACK שקוראת את אותן אפשרויות [2]. שום דבר אינו מונע את שחרור שקע הצאצא בזמן שמנת ה-SYN-ACK עדיין נבנית. האפשרויות שלו משתחררות בקריאה רגילה ל-kfree(), ולכן הליבה קוראת זיכרון משוחרר בתוך ip_options_build() [2].

מרוץ שני, דומה, קיים כאשר העברת שקעי בקשה (request-socket migration) מופעלת, בין דרך net.ipv4.tcp_migrate_req=1 ובין דרך תוכנית BPF מסוג reuseport [2]. התיקון גורם לשני מסלולי השחרור להמתין לתום תקופת חסד של RCU, באמצעות kfree_rcu() בפונקציות inet_sock_destruct() ו-tcp_v4_reqsk_destructor() [2]. RCU (read-copy-update) היא טכניקה בליבה שדוחה את שחרור הזיכרון עד שאין עוד שום קורא שעשוי להשתמש בו.

מה תוקף יכול לעשות בעזרתה?

הערות הדירוג ברשומת ה-CVE מתארות שלוש השפעות אפשריות [1]:

  • חשיפת מידע: הזיכרון המשוחרר יכול להיות מנוצל מחדש לנתונים אחרים, ותוכנו עלול להיות מועתק למנת ה-SYN-ACK שנשלחת בחזרה אל התוקף [1].
  • השחתת זיכרון: אורכים והיסטים לא עדכניים יכולים להסיט כתיבות של הליבה אל מחוץ לגבולות, עם אפשרות להשחתת זרימת הבקרה [1].
  • קריסות: ערך אורך שנוצל מחדש עלול לגרום ל-kernel panic, וגם הכתיבות השגויות עלולות להפיל את הליבה [1].

Red Hat מוסיפה שהרצת קוד באופן אמין דרך באג כזה, הרגיש מאוד לתזמון, מחייבת שליטה מדויקת בערימה (heap). היא בכל זאת מדרגת אותו כקריטי, משום שאין לו דרישות מוקדמות ברשת והוא עלול לגרום לחוסר יציבות חמור [7].

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

מה חשפה Anthropic, ומה התפקיד של MPTCP?

ב-27 באוקטובר 2026 פרסם צוות ה-Frontier Red Team של Anthropic סקירה של פגיעויות שמצא בעזרת מודלי Claude [4][11]. לגבי CVE-2026-98432, לדברי החברה, הצוות בנה ניצול שמאפשר לתוקף מרוחק להריץ פקודות שרירותיות כ-root בשרתי לינוקס שיש בהם מאזין Multipath TCP (MPTCP), בלי פרטי התחברות ובלי שום פעולה של המשתמש [4]. MPTCP היא הרחבה של TCP שמאפשרת לחיבור אחד להשתמש בכמה נתיבי רשת בו־זמנית.

Anthropic מתארת שני שלבים. תחילה הניצול מדליף מצביע של הליבה כדי לעקוף את KASLR, מנגנון הערבול של כתובות הליבה. אחר כך הוא דורס מצביע של פונקציית callback, כך שהליבה מריצה כ-root פקודה שבחר התוקף [4]. מרוץ שנכשל רק מכשיל את לחיצת היד ואינו מפיל את המערכת, ולכן התוקף יכול לנסות שוב ושוב [4]. בהוכחת ההיתכנות של Anthropic, הדלפת מצביע הליבה ארכה 48 דקות, והרצת הפקודה ארכה עוד חמש דקות [4].

האם MPTCP הכרחי?

לא, לפי הספקים שבחנו את הנושא. Red Hat קובעת ש-MPTCP אינו תנאי הכרחי לפגיעות הזו, ושמערכות שבהן MPTCP כבוי עדיין מושפעות [6]. צוות האבטחה של Go מציין שהניצול שהודגם אכן דורש מאזין MPTCP, אבל שהבאג עצמו אינו ייחודי ל-MPTCP [5]. Go רלוונטית כאן משום שמאז Go 1.24, תוכניות Go מפעילות כברירת מחדל MPTCP בשקעי האזנה בלינוקס [5].

לדברי Akamai, Anthropic לא פרסמה את הניצול שמשיג הרשאות root, וב-2 בנובמבר 2026 ציינה Akamai שאינה מכירה ניצול ציבורי עובד [11].

אילו גרסאות ליבה והפצות תוקנו?

צוות ה-CVE של הליבה מונה את התיקונים הבאים במקור (upstream): 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 והליבה הראשית 7.3 [2]. עם זאת, רוב האנשים מריצים ליבה שבנתה ההפצה שלהם, ולה מספרי גרסה משלה. בדקו את הודעת האבטחה של ההפצה שלכם, ואל תשוו למספרי הגרסאות של המקור.

המצב נכון ל-3 בנובמבר 2026:

  • Red Hat Enterprise Linux: ליבות מתוקנות שוחררו ב-1 בנובמבר 2026 עבור RHEL 8, 9 ו-10. RHEL 6 ו-7 מופיעות כלא מושפעות. ליבת הזמן האמת של RHEL 9 ותמונות הצמתים של OpenShift עדיין מופיעות כמושפעות [7].
  • Ubuntu: Ubuntu מדרגת את הבעיה כקריטית. מערכת המעקב שלה מציגה את 26.10, 26.04 LTS, 24.04 LTS ו-22.04 LTS כפגיעות, כשהתיקונים בעבודה; גם 20.04, 18.04 ו-16.04 מופיעות כפגיעות, ו-14.04 מופיעה כלא מושפעת [8].
  • Debian: יש תיקונים ל-Debian 12 bookworm (linux 6.1.190-1 ו-linux-6.12 6.12.113-1~deb12u1), ל-Debian 13 trixie (linux 6.12.113-1) ולענף unstable [9].
  • AlmaLinux: ליבות מתוקנות ל-AlmaLinux 8, 9 ו-10 נמצאות במאגרי הייצור [10].
  • אחרות: לפי Akamai, עד 30 באוקטובר 2026 הפיצו SUSE, Oracle Linux ו-Amazon Linux 2023 ליבות מתוקנות לחלק מהגרסאות שלהן [11].

ומה לגבי טלפוני Android?

מערכת Android משתמשת בליבת לינוקס, אבל עלון האבטחה של Android שפורסם ב-2 בנובמבר 2026 אינו כולל את CVE-2026-98432 [13]. בעלי טלפונים צריכים להתקין את עדכוני האבטחה כאשר יצרן המכשיר משחרר אותם.

איך בודקים אם שרת פגיע?

  1. מצאו את הליבה שרצה כעת. הריצו uname -r. תיקון נחשב מותקן רק אחרי שהמחשב אותחל אל תוך הליבה החדשה. AlmaLinux מנחה את המשתמשים לאתחל את המערכת ולוודא את הגרסה באמצעות uname -r [10].
  2. השוו למערכת המעקב של הספק שלכם. חפשו את CVE-2026-98432 בדף האבטחה של ההפצה שלכם. Red Hat [7], Ubuntu [8], Debian [9] ו-AlmaLinux [10] מפרטות כל אחת את גרסאות החבילות שכוללות את התיקון.
  3. בדקו את MPTCP. הפקודה sysctl net.mptcp.enabled מראה אם MPTCP פעיל. הפקודה sudo ss -lnMp מציגה את מאזיני ה-MPTCP ואת התהליכים שמחזיקים בהם [10]. Akamai ממליצה לבדוק גם את net.ipv4.tcp_migrate_req [11].
  4. חפשו שירותים שנכתבו ב-Go. תוכניות שנבנו עם Go 1.24 ואילך פותחות כברירת מחדל מאזיני MPTCP בלינוקס [5]. לכן כל שירות Go שאתם מריצים עלול לחשוף את המסלול שאותו ניצלה Anthropic.
  5. בדקו מוצרים שבנויים מעל הליבה. Red Hat מזהירה שכל מוצר שבנוי על ליבת RHEL, כולל OpenShift, OpenStack ו-Red Hat Virtualization, עלול להיות מושפע גם הוא [6].
מנהל מערכות מצולם מאחור ליד שולחן במשרד בלילה, שני מסכים מציגים חלונות מסוף מטושטשים בירוק ובלבן

איך מתקנים או מצמצמים את CVE-2026-98432?

התיקון האמיתי הוא ליבה מעודכנת. Red Hat מגדירה את התקנת עדכוני הליבה כפתרון המלא היחיד [6], וצוות האבטחה של Go מציין שהתיקון הטוב ביותר הוא שדרוג לליבה מתוקנת [5]. התקינו את עדכון הליבה של ההפצה שלכם, אתחלו את המערכת וודאו מהי הגרסה שרצה בפועל.

מה אפשר לעשות לפני שמגיע עדכון?

  • השליכו מנות TCP שנושאות אפשרויות IPv4. Red Hat מפרסמת, ומערכת המעקב של Ubuntu מציגה כפתרון עוקף שתרמו משתמשים, כלל nftables שמשליך מנות TCP נכנסות מעל IPv4 שכותרת ה-IP שלהן ארוכה מ-20 הבתים הבסיסיים, כלומר מנות שנושאות אפשרויות (ip hdrlength > 5) [6][8]. אפשרויות TCP רגילות, כמו חותמות זמן והגדלת חלון, נמצאות בכותרת ה-TCP ואינן מושפעות [8]. שני הספקים מציינים שהכלל מקטין את הסיכון אבל אינו יכול למנוע ניצול לחלוטין [6][8].
  • הכירו את המגבלות של הכלל. AlmaLinux מציינת שהגרסה שלה אינה שורדת אתחול, שתעבורה בין קונטיינרים באותו מארח עשויה לעקוף אותה, שהיא משליכה גם מנות מועברות במארחים שמשמשים כנתבים, ושהיא שוברת רשתות שמסתמכות על תוויות CIPSO/NetLabel [10]. Ubuntu מציינת שבקונטיינרים עם רשת נפרדת יש להחיל את הכלל בנפרד [8].
  • כבו את MPTCP אם אינכם צריכים אותו. ההגדרה net.mptcp.enabled=0 מכבה את MPTCP בכל המערכת [10]. Akamai ממליצה גם להגדיר net.ipv4.tcp_migrate_req=0 [11]. עם זאת, Akamai מזהירה שכיבוי MPTCP לבדו אינו מונע ניצול, אלא רק מקטין את הסיכוי להפעיל את המרוץ [11]. תוכניות Go יכולות גם לוותר עליו באמצעות GODEBUG=multipathtcp=0, אבל צוות Go מגדיר ויתור ברמת התוכנית הבודדת כפתרון שביר [5].
  • סננו בקצה הרשת. לגבי OpenShift, Red Hat מציינת שכללים בצומת אינם מסננים תעבורה בין פודים, ואילו סינון בגבול הרשת שלפני האשכול נמנע מהמגבלה הזו [6].

האם init_on_free=1 עוזר?

פוסט אחד ברשימת התפוצה oss-security הציע את אפשרות האתחול init_on_free=1 כפתרון ביניים נוסף. חבר בצוות הליבה של CIQ השיב שהיא אינה מצמצמת את הפגיעות הזו באופן משמעותי ושאין לייחס לה משקל בהודעות אבטחה [12]. התייחסו אליה כהקשחה כללית, לא כאמצעי הגנה מפני הבאג הזה.

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

האם CVE-2026-98432 מנוצלת בפועל?

נכון ל-3 בנובמבר 2026, CVE-2026-98432 אינה מופיעה בקטלוג הפגיעויות המנוצלות הידועות של CISA, הרשימה של ממשלת ארה״ב של פגיעויות שניצולן בעולם האמיתי אושר [14]. Akamai ציינה ב-2 בנובמבר 2026 שאינה מכירה ניצול ציבורי עובד [11]. אין בכך הוכחה שאיש אינו מנצל את הבאג. הוכח שקיים ניצול אמין [4], והפרטים הטכניים גלויים לכול בתיקון הליבה [3].

גם תמונת החומרה השתנתה עם הזמן. הפגיעות פורסמה לראשונה ב-15 באוקטובר 2026 [1]. תשומת לב רחבה יותר הגיעה אחרי הסקירה של Anthropic מ-27 באוקטובר [4][11]. בין 29 באוקטובר ל-2 בנובמבר יצאו הודעות של ספקים עם אמצעי הגנה זמניים [5][6][10]. מנהלי מערכות שרק עיינו ברשומה המקורית עלולים היו להחמיץ את ההנחיות המאוחרות יותר.

מה צפוי בהמשך?

Red Hat מתארת את החקירה שלה כנמשכת ומציינת שההודעה שלה תעודכן כשיתגלה מידע חדש [6]. צפו שהחבילות שנותרו, כמו ליבת הזמן האמת של RHEL 9 ותמונות OpenShift [7] וליבות Ubuntu שעדיין בעבודה [8], יקבלו תיקונים בימים או בשבועות הקרובים. עקבו אחרי מערכות המעקב של הספקים ולא אחרי סיכומים בחדשות, משום שהדפים האלה השתנו כמה פעמים בשבועות הראשונים.

תיקון הליבה גם משאיר בעיה קשורה אחת פתוחה. לפי התיאור של מפתחי הליבה, לפונקציה tcp_v6_reqsk_destructor() של IPv6 יש אותה בעיית העברה עם אפשרויות שמוגדרות רק על ידי CALIPSO, והיא תטופל בתיקון נפרד [2]. לפי מדיניות החשיפה המתואמת של Anthropic, היא מקצה 90 ימים לתיקון ועוד 45 ימים לפני שהיא דנה בפרטים שמעבר להודעה הפומבית [4]. לכן ייתכן שפרטים טכניים נוספים יתפרסמו בהמשך.

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

מצב התיקון של CVE-2026-98432 לפי מקור, נכון ל-3 בנובמבר 2026
ליבה או הפצהגרסה מתוקנת או מצבהערות
ענפים יציבים במקור 5.10 / 5.15 / 6.15.10.272, 5.15.223, 6.1.190 [2]הבאג נוסף בגרסה 4.4 [2]
ענפים יציבים במקור 6.6 / 6.12 / 6.186.6.159, 6.12.113, 6.18.56 [2]התיקון הועבר לענפים המתוחזקים [4]
מקור 7.2 / ליבה ראשית7.2.10 ו-7.3 [2]התיקון נכנס לליבה הראשית ב-5 באוקטובר 2026 [3]
Red Hat Enterprise Linux 8 / 9 / 10ליבות מתוקנות שוחררו ב-1 בנובמבר 2026 [7]kernel-rt של RHEL 9 ו-OpenShift עדיין מופיעים כמושפעים [7]
Ubuntu 22.04, 24.04, 26.04, 26.10פגיעות, התיקון בעבודה [8]עדיפות ב-Ubuntu: קריטית [8]
Debian 12 ו-136.1.190-1 ו-6.12.113-1~deb12u1 (12); 6.12.113-1 (13) [9]תוקנו באמצעות DLA-4841-1, DLA-4850-1 ו-DSA-6568-1 [9]
AlmaLinux 8 / 9 / 10ליבות מתוקנות במאגרי הייצור [10]MPTCP כבוי כברירת מחדל, אבל התיקון עדיין נחוץ [10]

טעויות נפוצות

  • התקנת חבילת הליבה בלי לאתחל את המערכת

    הדרך הנכונה: הליבה הישנה ממשיכה לרוץ עד לאתחול. אתחלו את המערכת ואז ודאו את הגרסה שרצה באמצעות uname -r, כפי ש-AlmaLinux ממליצה [10].

  • ההנחה ששרת בטוח כי MPTCP כבוי בו

    הדרך הנכונה: Red Hat מציינת ש-MPTCP אינו תנאי הכרחי ושמערכות שבהן הוא כבוי עדיין מושפעות [6]. לדברי Akamai, כיבוי MPTCP רק מקטין את הסיכוי להפעיל את המרוץ [11]. עדכנו את הליבה.

  • התייחסות לכלל ה-nftables כאל תיקון

    הדרך הנכונה: Red Hat ו-Ubuntu מציינות שתיהן שהכלל לחסימת אפשרויות IPv4 מצמצם את החשיפה אבל אינו יכול למנוע ניצול לחלוטין [6][8]. השתמשו בו רק עד שתותקן ליבה מתוקנת, ואז הסירו אותו כפי ש-Red Hat מתארת [6].

  • השוואת מספרי גרסה של המקור לליבות של ההפצות

    הדרך הנכונה: ההפצות מעבירות תיקונים לאחור תחת מספרי גרסה משלהן. בדקו את הפגיעות במערכת המעקב של הספק שלכם, למשל של Red Hat [7], של Ubuntu [8] או של Debian [9].

  • שכחת הקונטיינרים והאשכולות

    הדרך הנכונה: תעבורה בין קונטיינרים באותו מארח עשויה לעקוף את כללי חומת האש של המארח [10], וכללים בצמתי OpenShift אינם מסננים תעבורה בין פודים [6]. עדכנו את ליבת המארח, כי הקונטיינרים חולקים אותה.

שאלות נפוצות

האם CVE-2026-98432 אמיתית, ועד כמה היא חמורה?

כן. זוהי רשומת CVE שפרסם צוות ה-CVE של ליבת לינוקס, מתאריך 15 באוקטובר 2026, עם ציון CVSS 3.1 של 9.8 (קריטי) [1]. גם Red Hat [7] ו-Ubuntu [8] מדרגות אותה כקריטית.

האם CVE-2026-98432 משפיעה על המחשב הביתי או על הטלפון שלי?

לדברי Red Hat, המערכות החשופות ביותר באופן ישיר הן אלה שמקבלות חיבורי TCP נכנסים [6], כלומר בעיקר שרתים. עלון האבטחה של Android שפורסם ב-2 בנובמבר 2026 אינו כולל את הפגיעות [13]. בכל מקרה, התקינו את העדכונים של היצרן שלכם.

האם MPTCP צריך להיות פעיל כדי שאהיה פגיע?

לא. הניצול של Anthropic השתמש במאזין MPTCP [4], אבל Red Hat מציינת ש-MPTCP אינו תנאי הכרחי [6], וצוות האבטחה של Go מציין שהבאג עצמו אינו ייחודי ל-MPTCP [5].

אילו גרסאות של ליבת לינוקס מתקנות את CVE-2026-98432?

התיקונים במקור נמצאים בגרסאות 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ו-7.3 [2]. לליבות של ההפצות יש מספרים משלהן, ולכן בדקו את הודעת האבטחה של הספק שלכם [7][8][9].

האם קיים ניצול ציבורי ל-CVE-2026-98432?

Anthropic תיארה הוכחת היתכנות עובדת אבל לא פרסמה אותה [4][11]. נכון ל-2 בנובמבר 2026, Akamai לא הכירה ניצול ציבורי עובד [11], ונכון ל-3 בנובמבר הפגיעות לא הופיעה בקטלוג KEV של CISA [14].

האם IPv6 מושפע?

לא מהבעיה העיקרית. לפי התיאור של מפתחי הליבה, IPv6 משכפל את האפשרויות במקום להעביר אותן, אבל קיימת בעיית העברה קשורה עם אפשרויות CALIPSO שתתוקן בתיקון נפרד [2].

מילון מונחים

CVE
Common Vulnerabilities and Exposures: מזהה ציבורי של פגם אבטחה מסוים ומתועד, כמו CVE-2026-98432 [1].
שימוש לאחר שחרור (Use-after-free)
באג של בטיחות זיכרון שבו תוכנה ממשיכה להשתמש בזיכרון אחרי שכבר שוחרר, ולכן ייתכן שהזיכרון מכיל כעת נתונים אחרים.
CVSS
Common Vulnerability Scoring System: ציון חומרה בין 0 ל-10; ציון 9.8 נמצא בטווח הקריטי [1].
MPTCP
Multipath TCP: הרחבה שמאפשרת לחיבור TCP יחיד להשתמש בכמה נתיבי רשת. Go 1.24 ואילך מפעילות אותה כברירת מחדל בשקעי האזנה בלינוקס [5].
אפשרויות IPv4
שדות רשותיים בכותרת IPv4, כמו Record Route ו-Timestamp, שתוקף יכול להכניס למנת SYN כדי להגיע לקוד הפגיע [1].
KASLR
Kernel Address Space Layout Randomisation: מנגנון הגנה שממקם את הליבה בכתובת זיכרון בלתי צפויה. הניצול של Anthropic מדליף קודם מצביע כדי לעקוף אותו [4].
RCU
Read-copy-update: טכניקה בליבה שדוחה את שחרור הזיכרון עד שאין עוד קורא שעשוי להשתמש בו. התיקון מחליף שתי פעולות שחרור ב-kfree_rcu() [2].

מקורות

  1. CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period CVE Program (record assigned by the Linux kernel CNA) · 2026-10-15
  2. CVE-2026-98432 announcement: description, severity and affected/fixed versions Linux kernel CVE team (kernel.org) · 2026-10-15
  3. ipv4: free inet_opt and ireq_opt after an RCU grace period (mainline commit e3f33b0a1d89) Linux kernel source tree (kernel.org) · 2026-10-05
  4. Discovering vulnerabilities with Claude Anthropic · 2026-10-27
  5. Fwd: Protecting against CVE-2026-98432 when using Go programs (Go Security Team announcement) oss-security mailing list (Openwall) · 2026-10-30
  6. RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432) Red Hat Product Security · 2026-10-30
  7. CVE-2026-98432 (Red Hat CVE database: severity, statement and affected packages) Red Hat; live page, retrieved 2026-11-03 · 2026-10-15
  8. CVE-2026-98432 | Ubuntu Canonical Ubuntu Security; live page, retrieved 2026-11-03 · 2026-10-15
  9. CVE-2026-98432 (Debian Security Bug Tracker) Debian Security Team; live page, retrieved 2026-11-03
  10. CVE-2026-98432: fixed kernels and interim mitigations for AlmaLinux AlmaLinux OS Foundation (Andrew Lukoshko) · 2026-10-30
  11. CVE-2026-98432: A Remote Use-After-Free in the Linux Kernel's TCP Stack Akamai Security Intelligence Group · 2026-11-02
  12. Re: CVE-2026-98432: init_on_free=1 as an additional interim mitigation oss-security mailing list (Openwall) · 2026-11-03
  13. Android Security Bulletin, November 2026 Android Open Source Project (Google) · 2026-11-02
  14. Known Exploited Vulnerabilities Catalog US Cybersecurity and Infrastructure Security Agency (CISA); checked 2026-11-03
שתפו את המדריך Telegram WhatsApp X
0 לייקים

תגובות

הערות מובילות

על צוות Pouyam מדיניות מערכת

ב-Pouyam

גלו את Pouyam

המדריכים הם רק פינה אחת של Pouyam. הנה לאן ממשיכים.

ניווט מהיר

גילויעזרהPouyam PlayתרגוםאקדמיהמבחניםקהילהחדשותסרטוניםReelsמוזיקהמשחקיםStudioצ'אטחדרלוח מוביליםהפניהארנקעזור לכפהPoke Worldמדריכיםחנותהגדרות