פרצת HTTP/2 ב-Apache, CVE-2026-119618: עדכנו ל-2.4.71

מהי CVE-2026-119618?

CVE-2026-119618 היא פרצה קריטית ב-mod_http2, המודול שמטפל בתעבורת HTTP/2 ב-Apache HTTP Server; היא עלולה להוביל להשחתת ערימה (heap) ולהרצת קוד מרחוק ^[1].

Apache מתארת אותה כ“פרצת ביצוע במקביל תוך שימוש במשאב משותף עם סנכרון לא תקין ב-mod_http2 של Apache HTTP Server בפונקציה assign_headers()” ש“עלולה להוביל ל-RCE” ^[1]. CIRCL, צוות התגובה הלאומי לחירום מחשבים של לוקסמבורג, מסביר שבעת עיבוד מקבילי של זרמי HTTP/2, תהליך עבודה יכול לשנות טבלת כותרות שהוקצתה להקשר ביצוע אחר, וגישה לא בטוחה זו לזיכרון משותף יכולה להשחית את הערימה ^[2].

תוקף מוצלח יכול להריץ קוד בהרשאות של תהליך שרת האינטרנט של Apache, בלי להתחבר ^[2][4]. לפי BleepingComputer, Apache HTTP Server פועל על כחמישית מאתרי האינטרנט בערך ^[4].

התיקון במעלה הזרם משנה כתיבה אחת בקובץ modules/http2/h2_request.c מטבלת כותרות הבקשה המשותפת אל כותרות הקלט של הבקשה הנוכחית עצמה ^[2].

אילו גרסאות Apache מושפעות?

Apache HTTP Server מגרסה 2.4.55 עד 2.4.70 מושפע, יחד עם גרסאות mod_h2 עצמאיות מ-2.0.8 עד 2.0.42 מ-GitHub; גרסה 2.4.71 מתקנת זאת ^[1].

חבילות הפצה מסבכות את בדיקת הגרסה. CIRCL ממליצה לארגונים שמשתמשים בחבילות שמתוחזקות על ידי מפיצים לאמת את ה-backport האבטחתי ולא להסתמך רק על מספר הגרסה במעלה הזרם ^[2]. Red Hat, כפי שמסכמת CIRCL, מדרגת את חבילות RHEL 9 ו-10 שלה כחשובות (Important) ולא כקריטיות, כי מקצה הזיכרון שלהן מקשה על הניצול, ומדווחת ש-RHEL 8 ומוקדמות יותר אינן מושפעות ^[2].

Red Hat נותנת ציון CVSS v3.1 כללי של 9.8 (קריטי) ^[2][3]. הדירוג של Apache עצמה הוא קריטי ^[1].

האם שרת ה-Apache שלי פגיע?

רק אם הוא מריץ גרסה מושפעת ומקבל בפועל חיבורי HTTP/2: Red Hat אומרת ששרתים שמוגדרים להגיש רק HTTP/1.1 אינם פגיעים ^[3]. CIRCL מדגישה שאי אפשר להגיע לנתיב הקוד רק משום ש-mod_http2 מותקן או נטען ^[2].

• ההנחיה Protocols שולטת ב-HTTP/2: “h2” מפעילה אותו מעל TLS ו-“h2c” מעל טקסט גלוי ^[2].
• ברירת המחדל של הליבה של Apache היא http/1.1, וטעינת mod_http2 אינה משנה זאת בעצמה ^[2]. BleepingComputer מציין ש-HTTP/2 כבוי כברירת מחדל ^[4].
• מארח וירטואלי יכול להגדיר הנחיית Protocols משלו, ולכן בדיקה של ההגדרות הגלובליות בלבד עלולה לפספס אתר שמופעל בו HTTP/2 ^[2].
• אם proxy הפוך, מאזן עומסים או CDN מסיים את HTTP/2 ומעביר ל-Apache רק HTTP/1.1, הפעלת ה-HTTP/2 של הלקוח אינה הופכת את Apache לנגיש בעצמה, אך כדאי לוודא את הפרוטוקול בכל חוליה ^[2].

CIRCL מציעה לבדוק את הגרסה והמודולים שנטענו (apachectl -v, apachectl -M), את המארחים הווירטואליים שהוגדרו (apachectl -S) ואת כל הגדרת Protocols מפורשת ^[2]. בדיקה שמראה שנקודת קצה מקבלת HTTP/2 אינה מוכיחה שה-backend שלה פגיע, ובדיקה שלילית אינה מוכיחה שכל יציאה או מארח וירטואלי דוחים HTTP/2 ^[2].

איך בודקים אם השרת שלי מקבל HTTP/2?

CIRCL מציעה שתי בדיקות: לעבור על תצורת Apache בשרת עצמו, ואז לבדוק מהרשת את הפרוטוקול שמתנהל, רצוי בהתחברות ישירה ל-Apache ולא דרך proxy ^[2].

1. בדקו את הגרסה והמודולים. הריצו apachectl -v כדי לראות את הגרסה ואת apachectl -M, מסונן לפי http2, כדי לראות אם המודול נטען ^[2].
2. רשמו את המארחים הווירטואליים. apachectl -S מציג כל מארח וירטואלי שהוגדר, וזה חשוב כי לכל אחד יכולה להיות שורת Protocols משלו ^[2].
3. מצאו כל הנחיית Protocols. CIRCL נותנת פקודת grep שמחפשת ב-/etc/apache2 וב-/etc/httpd הגדרות Protocols מפורשות, כולל דריסות במארחים וירטואליים; הנתיבים משתנים בין הפצות ^[2].
4. בדקו מעל TLS. בקשת curl עם האפשרות --http2 שמדפיסה את גרסת ה-HTTP מראה אם נקודת קצה ב-HTTPS מנהלת משא ומתן על HTTP/2 ^[2].
5. בדקו טקסט גלוי. curl עם --http2-prior-knowledge בודק אם נקודת קצה ב-HTTP רגיל מקבלת h2c ^[2].

קראו את התוצאות בזהירות. תשובה שמדווחת על HTTP/2 מראה שנקודת הקצה שנבדקה קיבלה HTTP/2 אך אינה מאשרת שה-backend של Apache שלה פגיע; תוצאה שלילית אינה מוכיחה שכל כתובת, יציאה או מארח וירטואלי דוחים אותו ^[2]. עצת CIRCL היא לאשר יחד את תצורת Apache האפקטיבית ואת מצב החבילה המתוקנת אצל הספק ^[2]. בסביבות ענן, Wiz מזהירה שמופע Apache שנפרץ עלול להפוך לנקודת כניסה לתנועה לרוחב אל מיקרו-שירותים סמוכים או אל נקודות קצה של מטא-נתוני ענן, סיבה נוספת לבדוק כל מופע ולא רק את אתר האינטרנט הציבורי ^[5].

איך מתקנים את CVE-2026-119618?

שדרגו ל-Apache HTTP Server 2.4.71 ומעלה, או התקינו את החבילה המתוקנת של ההפצה שלכם, ואז הפעילו מחדש את Apache ווודאו שהתהליכים הרצים משתמשים בגרסה החדשה ^[2][1].

1. עדכנו את Apache. התקינו 2.4.71 או גרסת ספק שתוקנה במפורש עבור CVE-2026-119618 ^[2].
2. עדכנו את mod_h2 העצמאי אם אתם משתמשים בו, לפי הנחיית הספק שלו; Wiz אומרת לעבור את 2.0.42, ו-CIRCL מזהירה לא להניח שקיימת גרסה עצמאית חדשה יותר בלי לבדוק ^[5][2].
3. הפעילו מחדש ואמתו שהתהליכים הרצים משתמשים בגרסה המתוקנת ^[2].
4. אם אי אפשר לעדכן עדיין, השביתו את HTTP/2: הגדירו Protocols ל-http/1.1, הסירו את h2 ו-h2c מכל מארח וירטואלי שדורס, בדקו עם apachectl -t וטענו מחדש ^[2]. זה חוסם את הנתיב של הפרצה הזו אך אינו מתקן את הקוד ^[2].
5. הגבילו גישה לרשתות מהימנות כאמצעי זמני כאשר לא ניתן לא לעדכן ולא לשנות פרוטוקול ^[2].

חוקרי watchTowr סיכמו זאת כ“לעדכן עכשיו או להפיל את h2 עד שאפשר”, מדווח BleepingComputer ^[4]. SecurityWeek מדווח ש-Defiant הזהירה גם שעדכוני אבטחה של WordPress אינם יכולים לפתור את הבעיה כי היא משפיעה על שרת האינטרנט שמתחת ^[3].

האם CVE-2026-119618 מנוצלת?

נכון לפוסט של Wiz מ-11 בנובמבר 2026, לא היה ניצול זמין ולא היו דיווחים על ניצול בשטח ^[5]. התמונה משתנה במהירות, אף על פי כן.

• Red Hat אומרת שמחקר פומבי הדגים ניצול אמין נגד שרת שבו mod_http2 מופעל, אך ההודעה שלה אינה מציינת את המחקר ^[3]. CIRCL מציינת שזה כשלעצמו אינו מבסס ניצול בשטח ^[2].
• הוכחת היתכנות פומבית ב-GitHub מדווחת על שחזור השחתת זיכרון וקריסות של Apache, אך אינה מדגימה הרצת קוד מרחוק ^[3].
• נתוני Wiz מראים ש-64% מסביבות הענן מכילות משאבים שמריצים גרסאות מושפעות ול-51% יש מופעים חשופים לציבור; Wiz מציינת שהדבר אינו מביא בחשבון תצורה, ולכן אלה לא בהכרח מערכות שניתן לנצל ^[5][3].

CIRCL מונה סימנים ששווה לחקור: קריסות בלתי צפויות של תהליכי עבודה, הפעלות מחדש חריגות, תהליכי בן חשודים, שינויי קבצים לא מורשים וחיבורים יוצאים בלתי צפויים ^[2]. אלה רמזים, לא אינדיקטורים מאושרים לפריצה, ועדכון אינו מסיר התמדה שהוקמה לפני העדכון ^[2].

מי גילה את פרצת ה-HTTP/2 ב-Apache?

Apache נותנת קרדיט ל-OSS Scanner של Anthropic, שדיווח על הפרצה ב-26 באוקטובר 2026, ולאנתוני ווימס (Anthony Weems) ולסיימון סקנל (Simon Scannell) מ-Google Cloud Vulnerability Research, שדיווחו עליה באופן עצמאי ב-3 בנובמבר ^[1].

הממצא של Anthropic רשום תחת המזהה הפנימי ANT-2026-MAPKT6MZ ^[1]. SecurityWeek מתאר את שני הדיווחים כגילויים עצמאיים ^[3]. זו דוגמה נוספת לכלים אוטומטיים ומבוססי בינה מלאכותית שמוצאים באגים חמורים בתוכנת קוד פתוח נפוצה; בינה מלאכותית שמוצאת באגי אבטחה: מה Glasswing ו-CVE חדשים אומרים לכם בוחן מה המגמה הזו אומרת.

התיקון נקלט וגרסה 2.4.71 פורסמה ב-11 בנובמבר, באותו יום שבו Apache חשפה את הבעיה ברשימת התפוצה oss-security ^[1][2].

מה עוד מתקנת Apache 2.4.71?

Apache HTTP Server 2.4.71 מתקנת שלוש פרצות CVE בסך הכול: אחת קריטית, אחת חשובה ואחת נמוכה ^[1].

• CVE-2026-106023 (חשובה): הפניית מצביע NULL ב-mod_md בזמן עיבוד בקשה, שעלולה להקריס תהליך בן; משפיעה על 2.4.30 עד 2.4.70 ^[1].
• CVE-2026-109163 (נמוכה): דריסה של בייט אחד במאגר מחסנית ב-mod_vhost_alias, ש-Apache מתייגת “אחרי CVE-2026-63292” (הפרצה הקודמת ההיא תוקנה ב-2.4.69); משפיעה על 2.4.69 ו-2.4.70 ^[1].

הגרסה הקודמת, 2.4.69 באוקטובר 2026, תיקנה 20 פרצות CVE ^[1]. מנהלי מערכות שדילגו עליה מקבלים את התיקונים האלה גם כן במעבר ל-2.4.71. לפרצת שרת עדכנית נוספת, ראו CVE-2026-98432 מוסברת: פרצת ה-TCP בלינוקס ואיך מגנים על השרתים שלכם.

מה על מנהלי מערכות לעקוב אחריו בהמשך?

עקבו אחר ניצול פומבי להרצת קוד מרחוק, אחר backports של ספקים להפצה שלכם ואחר כל דיווח על מתקפות בשטח ^[3][5].

CIRCL ממליצה למפות מופעים שבהם HTTP/2 מופעל, לבדוק אם כל גרסת mod_http2 מושפעת ולעדכן מערכות חשופות ללא דיחוי, בעדיפות לאתרי אינטרנט הפונים לאינטרנט, ממשקי API, אחסון משותף ושרתי Apache מאחורי חזיתות שמעבירות HTTP/2 ^[2]. ארגונים שרואים פעילות חשודה צריכים לפעול לפי נהלי תגובה לאירועים וליצור קשר עם ה-CSIRT הלאומי שלהם ^[2].