ثغرة NGINX الحرجة: تجاوز ASLR وتنفيذ تعليمات برمجية عن بعد

مقدمة تحليلية

F5 أصدرت تحديثات لمعالجة ثغرة حرجة في NGINX، تحمل المعرف CVE-2026-42533، والتي تتيح لمهاجم عن بعد وغير مصادق عليه إحداث تجاوز سعة المخزن المؤقت في الذاكرة (heap buffer overflow) ضمن عملية العامل (worker process) عبر طلبات HTTP مصممة خصيصًا. تم تصنيف الثغرة بخطورة 9.2 على مقياس CVSS v4 و 8.1 على مقياس v3.1 الأقدم، مع تعقيد هجوم مرتفع. تم تطبيق الإصلاحات في 15 يوليو 2026، ضمن إصدارات NGINX 1.30.4 (stable) و 1.31.3 (mainline)، وكذلك في NGINX Plus 37.0.3.1. يمكن أن يؤدي استغلال هذه الثغرة إلى تعطيل أو إعادة تشغيل عملية العامل، مسببًا إنكار خدمة (DoS). الأهم من ذلك، وفقًا لتقرير الباحث ستان شو (cyberstan)، قد تسمح الثغرة أيضًا بتنفيذ تعليمات برمجية عن بعد (RCE) في حال تعطيل ASLR أو تجاوزها، وهو ما يدعي شو أن الثغرة توفره بذاتها. تتأثر جميع إصدارات NGINX من 0.9.6 وحتى 1.31.2، وهو نطاق يمتد إلى عام 2011.

التحليل التقني

تكمن الثغرة CVE-2026-42533 في محرك السكربتات الخاص بـ NGINX، وتحديدًا في الكود المسؤول عن تجميع السلاسل من التوجيهات عند وقت الطلب. لا تظهر هذه الثغرة إلا في تكوين محدد:

• استخدام توجيه map المبني على تعابير نمطية (regex).
• أن يتم الرجوع إلى متغير الإخراج الخاص بـ map في تعبير سلسلة بعد التقاط (capture) من تعبير نمطي سابق.

الخلل ينبع من آلية التقييم على مرحلتين للمحرك. في المرحلة الأولى، يتم قياس حجم الذاكرة المطلوبة للنتيجة ويتم تخصيص مخزن مؤقت (buffer) بالحجم المناسب. المشكلة تحدث بين هاتين المرحلتين، حيث يؤدي تقييم تعبير map النمطي إلى الكتابة فوق حالة الالتقاط المشتركة التي قرأتها المرحلة الأولى. بالتالي، تقوم مرحلة القياس بتحديد حجم المخزن المؤقت بناءً على الالتقاط الأصلي، مثل `$1` من مطابقة الموقع، بينما تقوم مرحلة الكتابة بملء المخزن المؤقت من التقاط مختلف، بحجم يحدده المهاجم. هذا يؤدي إلى أن يكون المخزن المؤقت أصغر من اللازم، ويأتي طول المحتوى المتجاوز ومحتواه مباشرة من طلب المهاجم. تأثير الثغرة لا يقتصر على كل خادم NGINX؛ فالتعرض يعتمد بشكل حاسم على التكوين وليس فقط على الإصدار. ذكرت F5 في إرشاداتها أن الثغرة تؤثر على منتجات متعددة إلى جانب الخادم الأساسي و NGINX Plus، بما في ذلك:

• NGINX Ingress Controller
• Gateway Fabric
• App Protect WAF
• Instance Manager

لاحظ أنه حتى وقت النشر، لم تدرج F5 الإصدارات الثابتة لهذه المنتجات الأربعة. وفقاً لـ F5، يتطلب تنفيذ التعليمات البرمجية عن بعد تعطيل ASLR أو القدرة على تجاوزها. هنا تختلف رؤية الباحث ستان شو، الذي يرى أن الثغرة نفسها توفر آلية تجاوز ASLR. أكد شو لـ The Hacker News أن التقاط الذي يتم الكتابة فوقه (capture clobbering) يعمل أيضًا بشكل عكسي: عندما يكون الالتقاط المتضرر أصغر من الأصلي، فإن المخزن المؤقت ذو الحجم الزائد يعيد بيانات كومة غير مهيأة (uninitialised heap data). وفي بيئة افتراضية مبنية على Ubuntu 24.04، يمكن لطلب GET واحد غير مصادق عليه استعادة العناوين اللازمة لتنفيذ حمولة. صرح شو بأن 'القارئ لإرشادات F5 قد يستنتج بشكل معقول أن هذا الهجوم يقتصر على إنكار الخدمة (DoS) في الأنظمة الافتراضية. هذا ليس صحيحاً.' يزعم شو أن هجومه حقق 10 من أصل 10 في اختباراته الخاصة، ويحتفظ بتفاصيل الاستغلال وإثبات المفهوم (proof-of-concept) لمدة 21 يومًا بعد الإصلاح. الحل الفوري هو الترقية إلى:

• NGINX 1.30.4 (stable)
• NGINX 1.31.3 (mainline)
• NGINX Plus 37.0.3.1

للمستخدمين الذين لا يستطيعون التحديث فورًا، توصي F5 بتخفيف مؤقت يتمثل في تحويل خرائط map المتأثرة التي تعتمد على التعابير النمطية إلى التقاطات مسماة (named captures)، وهو ما يقول شو إنه يغلق المسار الرئيسي ويغطي معظم التكوينات. ومع ذلك، حذر شو من أن هذا التخفيف يترك مسارًا أضيق مفتوحًا: إذا كانت map تحدد نفس المجموعة المسماة مثل تعبير الموقع النمطي، فيمكن الوصول إلى نفس التجاوز عبر مسار كود ثانٍ، وهو ما أكده باستخدام AddressSanitizer ولا تذكره إرشادات F5. صرح شو: 'الترقية إلى 1.30.4 / 1.31.3 هي الحل الكامل الوحيد.' التكوين المستهدف للبحث عنه هو: map تعتمد على تعبير نمطي، يظهر متغيرها في تعبير سلسلة بجانب التقاط مرقم (`$1`، `$2`) من تعبير نمطي سابق، مع كتابة الالتقاط قبل متغير map. طوّر شو أداة فحص خاصة به (0xCyberstan/CVE-2026-42533-Config-Scanner) تقوم بأتمتة هذا الفحص عبر التكوينات وتتبع التضمينات (includes)، وتشير فقط إلى الترتيبات القابلة للاستغلال. تعتبر هذه الثغرة هي الثالثة من نوع تجاوز سعة المخزن المؤقت (heap overflow) في كود تقييم التعبيرات في NGINX خلال حوالي شهرين، بعد ثغرة Rift (CVE-2026-42945) في مايو، وثغرة تداخل الالتقاطات (overlapping-captures bug) في وحدة إعادة الكتابة (rewrite module) (CVE-2026-9256) بعد أيام قليلة. جميع الثغرات الثلاث تنتمي إلى نفس الفئة: تصميم محرك سكربتات NGINX ذو المرحلتين الذي يقيس حجم المخزن المؤقت في مرحلة ويكتب فيه في المرحلة التالية، وفي كل مرة تتجاوز الكتابة الحجم الذي تم قياسه. يختلف المحفز، من علامة قديمة في Rift، إلى تداخل التقاطات في خطأ إعادة الكتابة، إلى حالة التقاط يتم الكتابة فوقها هنا. الضعف المشترك، كما يلاحظ الباحثون، هو تصميم يعتمد على قياساته الخاصة. حتى 20 يوليو، لم تكن CVE-2026-42533 مدرجة في كتالوج CISA للثغرات المعروفة المستغلة (Known Exploited Vulnerabilities catalog)، ولم يظهر أي كود استغلال عام. يؤكد شو أنه سينشر إثبات المفهوم الخاص به بعد 21 يومًا من الإصلاح، وحالة Rift تعتبر مثالًا تحذيريًا: فقد ظهر استغلالها علنًا في غضون أيام وشهد استغلالًا نشطًا بعد ذلك بوقت قصير. وهذا هو السبب لضرورة الترقية قبل ظهور استغلال هذه الثغرة.

السياق وتأثير السوق

تُشير هذه الثغرة الأمنية في NGINX إلى تبعات واسعة النطاق في البنية التحتية الرقمية العالمية، بالنظر إلى الدور المركزي الذي يلعبه NGINX كخادم ويب، ووكيل عكسي، وموازن تحميل (load balancer) في عدد لا يحصى من الشبكات. حقيقة أن الثغرة تستهدف إصدارات تعود إلى عام 2011 (الإصدار 0.9.6) تعني أن ملايين الخوادم حول العالم معرضة للخطر، بما في ذلك تلك التي قد تكون تعمل بإصدارات قديمة وغير مراقبة. تقييم F5 الأولي للثغرة، الذي يشير إلى إنكار الخدمة (DoS) كالتأثير الأساسي، يبدو محافظًا مقارنة بادعاءات ستان شو بأن الثغرة توفر القدرة على تجاوز ASLR وبالتالي تنفيذ تعليمات برمجية عن بعد (RCE) على الأنظمة الافتراضية. هذا التضارب في التقييم يؤثر بشكل مباشر على استجابة المؤسسات، حيث قد يؤدي التقليل من شأن المخاطر إلى تأخير في إجراءات الترقية الضرورية. تكرار ثغرات تجاوز سعة المخزن المؤقت (heap overflow) في محرك تقييم التعبيرات الخاص بـ NGINX، مثل CVE-2026-42945 و CVE-2026-9256، خلال فترة قصيرة، يكشف عن مشكلة هندسية متأصلة في تصميم NGINX ذي المرحلتين. هذا النمط يشير إلى ضعف بنيوي وليس مجرد أخطاء فردية، مما يستدعي إعادة تقييم أعمق لآليات إدارة الذاكرة ومعالجة السلاسل في NGINX. بالنسبة للمنافسين، مثل Apache HTTP Server أو Caddy، فإن ظهور مثل هذه العيوب المتكررة في NGINX قد يدفع بعض الشركات لإعادة النظر في خياراتها، خاصة تلك التي تتطلب أعلى مستويات الأمان. مع اقتراب موعد نشر إثبات المفهوم (PoC) من قبل ستان شو بعد 21 يومًا من تاريخ التصحيح، تتقلص النافذة الزمنية المتاحة للمسؤولين عن الأنظمة لتطبيق التحديثات. التجربة مع ثغرة Rift السابقة، التي شهدت استغلالًا نشطًا بعد أيام قليلة من نشر الكود العام، يجب أن تكون بمثابة إنذار واضح. التأخير في الترقية يعرض المؤسسات لخطر كبير من الهجمات المستهدفة التي يمكن أن تؤدي إلى اختراق كامل للأنظمة. كما أن عدم إدراج الثغرة حاليًا في كتالوج CISA للثغرات المعروفة المستغلة لا يقلل من خطورتها، بل يشير إلى أنها لم تصل بعد إلى مستوى الانتشار الواسع للاستغلال الفعلي الذي تراقبه CISA، وهو وضع سيتغير حتمًا مع نشر PoC.

رؤية Glitch4Techs

تكرار ثغرات تجاوز سعة المخزن المؤقت في NGINX، وخصوصًا CVE-2026-42533، ليس مجرد حادثة أمنية منفصلة بل هو دليل قاطع على ضعف معماري أساسي في محرك معالجة التعبيرات ذي المرحلتين. اعتماد F5 الأولي على تخفيف مؤقت غير كامل، بحسب تأكيدات الباحث ستان شو، يعكس إما تقييمًا متساهلًا للمخاطر الحقيقية أو عدم فهم كامل لنطاق الثغرة. هذا النهج يضع ملايين الأنظمة في خطر غير مبرر. الواقع هو أن الترقية الفورية هي الحل الوحيد المجدي، حيث أن نافذة الأمان الوحيدة المتاحة حاليًا هي تأخر نشر كود الاستغلال العام. أي تأخير في التطبيق الكامل للتصحيحات يعرض الخوادم لهجمات RCE مباشرة وغير مصادق عليها، وهو ما يمثل فشلاً في حماية البنية التحتية الحرجة.