Apache تسد ثغرة تتيح تنفيذ تعليمات برمجية دون كلمة مرور في الإصدار 2.4.71

إذا كان Apache يخدم موقعكم أو واجهة API لديكم عبر HTTP/2، فقد أصبحت لدى فريق البنية التحتية مهمة عاجلة: التحقق من الإصدار وتثبيت التصحيح. اكتُشف خلل في الوحدة المسؤولة عن معالجة هذا البروتوكول يتيح للمهاجم تنفيذ تعليمات برمجية دون مصادقة. فقد يكون الخادم الموجود أمام تطبيقكم عرضة للخطر مثلًا، ولا يحتاج هذا الهجوم إلى كلمة مرور لوحة الإدارة.

أصدرت Apache التصحيح في 11 نوفمبر ضمن الإصدار 2.4.71. وحملت الثغرة المعرّف CVE-2026-119618 وصُنّفت حرجة. ووفقًا لـإشعار Apache الرسمي، تتأثر الإصدارات 2.4.55–2.4.70. وهذا سبب واضح للرجوع إلى سجل الخوادم، وتحديد مواضع استخدام HTTP/2، وتعيين مسؤول عن التحديث.

ما الذي اختل داخل الخادم

يقع الخلل في mod_http2، داخل الدالة assign_headers(). تصل عدة خيوط تنفيذ إلى موارد مشتركة دون مزامنة صحيحة. وقد يؤدي ذلك إلى إفساد الخادم لذاكرته، ما يتيح للمهاجم استغلال هذا التلف لتنفيذ تعليمات برمجية.

تخيلوا موظفَين يعدّلان في الوقت نفسه بندًا واحدًا في طلب شراء. يغيّر أحدهما محتواه، بينما يواصل الآخر العمل اعتمادًا على حالته القديمة. بالنسبة إلى خادم ويب، يُعد هذا الخلل في التنسيق خطيرًا، لأنه يمس ذاكرة عملية قيد التشغيل. هذا تشبيه مبسّط لسبب الخلل، وليس وصفًا لطريقة اختراق جاهزة.

ومن الأمثلة العملية خادم Apache موجود أمام خدمة اشتراكات. حتى إذا كان تسجيل الدخول إلى حساب العميل محميًا بالمصادقة متعددة العوامل، فإن معالجة بروتوكول الشبكة تحدث قبل أن يتحقق التطبيق من المستخدم. لذلك، فإن تقوية كلمات المرور لا تعالج هذه المشكلة تحديدًا. يحتاج الفريق إلى تصحيح المكوّن الذي يستقبل الطلبات.

ما دور Anthropic وGoogle هنا

ذكرت Apache ضمن مكتشفي الثغرة Anthropic OSS Scanner، إلى جانب أنتوني ويمز وسايمون سكانيل من فريق Google Cloud Vulnerability Research. وصل بلاغ Anthropic في 26 أكتوبر، وبلاغ Google في 3 نوفمبر. وتؤكد هذه المعلومات مشاركة ماسح Anthropic في اكتشاف خلل خطير في برمجيات خوادم واسعة الاستخدام.

لكن عبارة «الذكاء الاصطناعي اكتشف ثغرة» تخفي تفصيلًا مهمًا: السجل الرسمي يسمّي ماسحًا محددًا وباحثين محددين. ولا يمكن الاستنتاج منه أن الاكتشافين تمّا باستقلالية كاملة، أو أن البشر لم يعودوا ضروريين للتحقق من النتائج. أما ما يهم مطوري أدوات الأمن هنا فهو النتيجة نفسها: فقد نجح البحث الآلي في الوصول إلى خلل في التنسيق بين خيوط التنفيذ يمكن أن يؤدي إلى تنفيذ تعليمات برمجية.

وتتطلب أرقام الانتشار قراءة متأنية. وفقًا لـبيانات Wiz، تضم 64% من البيئات السحابية التي رصدتها موارد تعمل بإصدارات متأثرة، وتضم 51% منها مثيلات متاحة للعامة. وتوضح الشركة أن هذه التقديرات لا تأخذ الإعدادات في الحسبان. وبالتالي، فإن عدد عمليات التثبيت لا يكشف وحده عدد الخوادم التي يمكن مهاجمتها فعليًا عبر HTTP/2.

عند نشر تقرير Wiz في 11 نوفمبر، لم تكن هناك شيفرة استغلال متاحة للعامة، ولم ترد بلاغات عن استغلال الثغرة. وهذه صورة للوضع في تاريخ محدد: فهي لا تضمن غياب الهجمات، ولا تصف الوضع بعد أسبوع.

ما الذي ينبغي لفريقكم التحقق منه

ابدؤوا بالخوادم المتاحة عبر الإنترنت: حدّدوا إصدار Apache، وما إذا كانت mod_http2 موجودة، وما إذا كان HTTP/2 مستخدمًا فعليًا. وإذا كان هناك وكيل آخر أمام التطبيق، فتحققوا من البروتوكول الذي يصل إلى Apache. فوجود خدمة وسيطة وحده لا يجيب عن هذا السؤال.

بعد ذلك، ثبّتوا تصحيح Apache 2.4.71 أو تحديث الحزمة المناسب الذي يقدمه مورّد نظامكم. وبالنسبة إلى الحزم التي أُدرجت فيها التصحيحات ضمن إصدارات أقدم، استندوا إلى إشعار المورّد: فقد لا يبيّن رقم الإصدار الأساسي وحده ما إذا كان التصحيح موجودًا. وبعد التحديث، تحققوا من بدء تشغيل الخادم وإعداداته ومسارات الاستخدام الرئيسية.

إذا تعيّن تأجيل التحديث، تقترح Wiz تعطيل HTTP/2 مؤقتًا. وبعد التغيير، تأكدوا من أن الخدمة متاحة للعملاء وأن البروتوكول المتأثر قد عُطّل بالفعل. وهذا إجراء مؤقت إلى حين تثبيت التصحيح.

بالنسبة إلى مسؤول المنتج أو المؤسس، فالمهمة عملية وواضحة: منح الفريق وقتًا لإجراء التحديث، والحصول على تأكيد يحدد الخوادم التي جرى فحصها. هذه النتيجة أكثر فائدة من رسالة عامة تقول إن «الأمن تحت السيطرة».