ثغرة Apache HTTP/2 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 قد يعدّل عامل (worker) جدول رؤوس خُصص لسياق تنفيذ آخر، وأن هذا الوصول غير الآمن إلى الذاكرة المشتركة قد يفسد الكومة ^[2].

ويمكن للمهاجم الناجح تنفيذ شيفرة بصلاحيات عملية خادم الويب Apache دون تسجيل دخول ^[2][4]. ويُقدَّر أن Apache HTTP Server يشغّل نحو واحد من كل خمسة مواقع، بحسب BleepingComputer ^[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].
• إذا كان وكيل عكسي أو موزّع حمل أو شبكة CDN ينهي اتصال HTTP/2 ويمرّر HTTP/1.1 فقط إلى Apache، فإن جلسة HTTP/2 لدى العميل لا تجعل Apache قابلاً للوصول بحد ذاتها، لكن ينبغي التحقق من البروتوكول في كل قفزة ^[2].

وتقترح CIRCL مراجعة الإصدار والوحدات المحمّلة (apachectl -v وapachectl -M) والمضيفات الافتراضية المهيأة (apachectl -S) وكل إعداد صريح لـProtocols ^[2]. ولا يثبت اختبار يُظهر أن نقطة نهاية تقبل HTTP/2 أن الخادم الخلفي معرّض للثغرة، كما لا يثبت الاختبار السلبي أن كل منفذ أو مضيف افتراضي يرفض HTTP/2 ^[2].

كيف أتحقق مما إذا كان خادمي يقبل HTTP/2؟

تقترح CIRCL فحصين: مراجعة إعداد Apache على الخادم نفسه، ثم اختبار البروتوكول المتفاوَض عليه من الشبكة، ويُفضَّل الاتصال مباشرة بـApache لا عبر وكيل ^[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 لكنها لا تؤكد أن خادم 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].

من اكتشف ثغرة Apache HTTP/2؟

تنسب Apache الفضل إلى OSS Scanner من Anthropic التي أبلغت عن الثغرة في 26 أكتوبر 2026، وإلى أنتوني ويمز وسايمون سكانيل من Google Cloud Vulnerability Research اللذين أبلغا عنها على نحو مستقل في 3 نوفمبر ^[1].

ويُدرج اكتشاف Anthropic تحت المعرّف الداخلي ANT-2026-MAPKT6MZ ^[1]. وتصف SecurityWeek البلاغين بأنهما اكتشافان مستقلان ^[3]. وهو مثال آخر على أدوات آلية ومدعومة بالذكاء الاصطناعي تعثر على أخطاء خطيرة في برمجيات مفتوحة المصدر واسعة الاستخدام؛ ويتناول الذكاء الاصطناعي الذي يكتشف الثغرات الأمنية: ماذا تعني Glasswing وCVEs الجديدة لك دلالة هذا الاتجاه.

وأُدرج الإصلاح وصدر 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 في Linux وكيف تحمي خوادمك.

ماذا ينبغي للمسؤولين أن يراقبوا بعد ذلك؟

ترقّب ظهور استغلال عام لتنفيذ الشيفرة عن بُعد، وإصلاحات منقولة من موردي توزيعتك، وأي تقارير عن هجمات فعلية ^[3][5].

توصي CIRCL بحصر النسخ المفعّل عليها HTTP/2، والتحقق مما إذا كان كل إصدار من mod_http2 متأثراً، وترقيع الأنظمة المكشوفة دون إبطاء، مع إعطاء الأولوية لمواقع الإنترنت المواجهة للشبكة العامة وواجهات API والاستضافة المشتركة وخوادم Apache الواقعة خلف واجهات أمامية تمرّر HTTP/2 ^[2]. وعلى المؤسسات التي ترصد نشاطاً مشبوهاً أن تتبع إجراءات الاستجابة للحوادث لديها وأن تتواصل مع فريق CSIRT الوطني ^[2].