نظرة عامة
| المعلومة | القيمة |
|---|---|
| رقم CVE | CVE-2026-42533 |
| نوع الثغرة | تجاوز سعة كومة الذاكرة (Heap Buffer Overflow) بمحرك تقييم التعبيرات النمطية (Regex) |
| الخطورة | Critical — CVSS v4: 9.2 / CVSS v3.1: 8.1 |
| الأنظمة المتأثرة | NGINX من الإصدار 0.9.6 حتى 1.31.2، وكذلك NGINX Ingress Controller وGateway Fabric وApp Protect WAF وInstance Manager |
| الحاجة للمصادقة | لا — طلب HTTP واحد غير مصادَق كافٍ |
| تعقيد الاستغلال | مرتفع (يحتاج إعداد تهيئة محدد بالخادم) |
| حالة التصحيح | متوفر — 1.30.4 (stable)، 1.31.3 (mainline)، NGINX Plus 37.0.3.1 |
| توفر كود استغلال (PoC) | لا يوجد علنًا بعد؛ الباحث المكتشف يخطط لنشره بعد 21 يومًا من التصحيح |
ملاحظة على درجة CVSS: لاحظ الفرق بين نسختين من نظام التقييم — 9.2 حسب المعيار الأحدث (CVSS v4) و8.1 حسب المعيار الأقدم (v3.1). الاختلاف طبيعي لأن كل نسخة من المعيار تحسب عوامل الخطورة بطريقة مختلفة قليلًا؛ المهم هنا إنه بكلا المعيارين الثغرة تقع بخانة “حرجة/عالية جدًا”.
أي إعداد بالضبط معرَّض؟
هذه الثغرة لا تصيب كل تنصيبات NGINX تلقائيًا — هي مرتبطة بنمط إعداد (تهيئة) محدد: خوادم تستخدم توجيه (directive) اسمه map مبني على تعبير نمطي (Regex)، وتكون متغيّرات الإخراج الناتجة عن هذا الـmap مُستخدَمة داخل تعبير نصي (String Expression) بعد التقاط (Capture) من تعبير نمطي آخر سابق له. لو إعدادك ما فيه هذا النمط المحدد، خطر التعرض المباشر أقل — لكن ننصح تتحقق فورًا لأن هذا النمط شائع بإعدادات NGINX المعقدة.
كيف تعمل الثغرة تقنيًا؟
محرك السكربتات بـNGINX بيقيّم توجيه map على مرحلتين:
المرحلة الأولى: قياس المساحة
النظام يحسب حجم المخزن المؤقت (Buffer) اللازم لتخزين ناتج المتغير، بناءً على البيانات المتوفرة بتلك اللحظة.
ما يحصل بين المرحلتين
المشكلة تبدأ هون: بين المرحلة الأولى والثانية، يتم تقييم التعبير النمطي الخاص بالـmap نفسه — وهذا يكتب فوق حالة الالتقاط (Capture State) السابقة الموجودة بالذاكرة.
المرحلة الثانية: الكتابة الفعلية
النظام يكتب البيانات الفعلية بالمخزن المؤقت — لكن باستخدام بيانات التقاط مختلفة عن يلي استُخدمت لحساب الحجم بالمرحلة الأولى، وهذه البيانات تحت سيطرة المهاجم بالكامل عبر محتوى طلب HTTP نفسه.
النتيجة: المخزن المؤقت يُحسَب بحجم أصغر من اللازم (لأنه اعتمد على بيانات قديمة/مختلفة)، بينما الكتابة الفعلية تستخدم بيانات جديدة أكبر — فيحصل تجاوز سعة، وطول التجاوز ومحتواه كلاهما تحت تحكم المهاجم عبر تصميم طلب HTTP مُعدّ بعناية.
هل ممكن تتحول لتنفيذ أوامر عن بُعد (RCE)؟
هذا الجزء الأكثر إثارة للقلق بالخبر. الباحث الأمني Stan Shaw (المعروف بلقب cyberstan)، وهو من اكتشف الثغرة، يرى إنه آلية التجاوز نفسها توفر تجاوزًا مدمجًا لحماية ASLR (Address Space Layout Randomization — تقنية حماية تُبعثر مواقع البرامج بالذاكرة عشوائيًا لمنع المهاجم من التنبؤ بعناوين دقيقة يستهدفها).
حسب Shaw، عملية “الكتابة فوق” (Clobbering) بين المرحلتين تُنتج بيانات كومة غير مُهيّأة (Uninitialised Heap Data) يمكن استغلالها لاستخراج عناوين ذاكرة حقيقية. وأوضح إنه على نظام Ubuntu 24.04 تحديدًا، تمكّن من استرجاع عناوين الحمولة (Payload) اللازمة بطلب GET واحد غير مصادَق فقط. هذا يعني إنه لو صح هذا التحليل، المهاجم ممكن نظريًا يتجاوز إحدى أهم طبقات الحماية الحديثة ضد استغلال ثغرات الذاكرة، بخطوة واحدة بسيطة نسبيًا.
التخفيف المؤقت
الحل المؤقت المقترح: تحويل توجيهات الـmap المبنية على تعبيرات نمطية إلى التقاط مُسمّى (Named Captures) بدل الالتقاط الرقمي العادي. لكن Shaw نفسه حدد مسارًا فرعيًا أضيق بالمشكلة — إعدادات تستخدم map بمجموعات مُسمّاة تتطابق أسماؤها مع تعبير نمطي بتوجيه location — يعني حتى هذا التخفيف المؤقت مو حل كامل 100% لكل الحالات.
الخلاصة العملية: التصحيح الرسمي هو الحل الوحيد الموثوق، مو الإعدادات البديلة.
هل توجد أداة استغلال متاحة؟
لا، ليس بعد. حتى تاريخ 20 تموز/يوليو 2026 لا يوجد كود استغلال علني. لكن Shaw أعلن نيته نشر كود إثبات مفهوم (PoC) بعد 21 يومًا من صدور التصحيح — وهذا يعطي نافذة زمنية محددة ومعروفة مسبقًا لازم تستغلها بتحديث أنظمتك قبل ما ينتهي العد التنازلي.
سابقة تستحق الانتباه: ثغرة سابقة مشابهة بنفس المكوّن، اسمها Rift (CVE-2026-42945)، شافت استغلالًا فعليًا خلال أيام قليلة فقط من نشر تفاصيلها. هذا نمط متكرر مؤخرًا بمكوّن تقييم التعبيرات بـNGINX.
نمط متكرر: ثالث ثغرة بنفس المكوّن خلال شهرين
هذه ثالث ثغرة تجاوز سعة بمحرك تقييم التعبيرات بـNGINX خلال فترة قصيرة نسبيًا (شهرين تقريبًا):
- CVE-2026-42945 (بالاسم الرمزي Rift) — أيار/مايو 2026
- CVE-2026-9256 — التقاطات متداخلة (Overlapping Captures) بوحدة إعادة الكتابة (Rewrite Module)
- CVE-2026-42533 — هذه الثغرة (تموز/يوليو 2026)
تكرار هذا النمط بنفس المكوّن التقني يشير لمشكلة بنيوية أعمق بطريقة تصميم محرك التعبيرات النمطية بـNGINX، مو مجرد خطأ برمجي معزول — وهذا سبب إضافي لمتابعة أي تحديثات مستقبلية بنفس المكوّن عن قرب.
كيف تحمي خادمك؟
- حدّث NGINX فورًا — 1.30.4 (النسخة المستقرة)، 1.31.3 (mainline)، أو NGINX Plus 37.0.3.1 حسب النسخة يلي تستخدمها.
- راجع إعداداتك — تحقق هل عندك توجيهات
mapمبنية على Regex بنمط الاستخدام الموصوف فوق (متغيّر إخراج مُستخدَم بتعبير نصي بعد التقاط سابق). - حوّل الالتقاطات لالتقاط مُسمّى (Named Captures) كتخفيف مؤقت — مع الانتباه إنه هذا مو حل كامل لكل الحالات حسب تحذير الباحث نفسه.
- راقب تحديثات NGINX عن كثب بالفترة الجاية — النمط المتكرر بهذا المكوّن يزيد احتمال ظهور ثغرات مشابهة إضافية.
ملاحظات
- الخبر الأصلي كتبته الصحفية Swati Khandelwal على The Hacker News بتاريخ 19 تموز/يوليو 2026.
- الثغرة تصيب أيضًا منتجات NGINX الموسّعة: Ingress Controller، Gateway Fabric، App Protect WAF، وInstance Manager — مو بس الخادم الأساسي.
المصدر
المقال الأصلي: Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution