CVE-2026-42533: مراجعة مخاطر NGINX Map Regex

ملاحظة بحثية دفاعية حول CVE-2026-42533، وهو تجاوز سعة مخزن مؤقت في كومة الذاكرة (heap buffer overflow) في معالجة طلبات NGINX، مرتبط بتوجيهات map مع التقاطات تعبيرات نمطية وأنماط معينة لتقييم المتغيرات.

بعبارات بسيطة: NGINX هو برنامج خادم ويب ووكيل عكسي. غالبًا ما يقف أمام المواقع وواجهات برمجة التطبيقات (APIs)، ويستقبل طلبات الويب، ويقرر إلى أين يرسلها. قاعدة map هي ميزة في إعداد NGINX تعني: «إذا كانت قيمة الطلب تشبه X، فاضبط هذا المتغير على Y». التقاطات التعبيرات النمطية (regex captures) هي أجزاء النص المستخرجة من تطابق النمط.

هذا CVE مهم لأن بعض إصدارات NGINX الأقدم يمكنها معالجة نوع معين من أنماط map وتركيبات المتغيرات بشكل غير صحيح. لا يعني ذلك أن كل خادم NGINX معرّض للخطر. الإصدار مهم، لكن الإعداد النشط مهم أيضًا.

هذا المشروع آمن عمدًا: لا يتضمن حركة استغلال، أو حمولات انهيار، أو استكشافًا للبيئات الإنتاجية. الهدف هو إظهار كيفية فرز التعرض للمخاطر، وشرح الخطر، وتزويد المدافعين بمسار تحقق قابل للتكرار.

لماذا هذا مهم

تدرج NGINX هذه المشكلة كنشرة أمنية رئيسية: الإصدارات المعرضة للخطر هي 0.9.6-1.31.2، والإصدارات المُصلَّحة هي 1.30.4+ و1.31.3+. يصف سجل تغييرات NGINX تجاوز سعة مخزن مؤقت في كومة الذاكرة داخل عملية عامل (worker) عندما يستخدم توجيه map مطابقة التعبيرات النمطية، ويُضمَّن متغير الخريطة في تعبير نصي بعد التقاط متأثر بتلك الخريطة.

يسجّل NVD وصف F5: قد يثير مهاجم غير مصادَق المشكلة عبر طلبات HTTP مصمّمة بعناية، ولكن فقط عندما تتوافق شروط الإعداد والتشغيل معًا. الأثر المباشر المتوقع هو إعادة تشغيل عامل NGINX ورفض الخدمة (denial of service)، مع احتمالية تنفيذ كود إذا تم تعطيل ASLR أو تجاوزه.

فرز التعرض للمخاطر

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

1. هل ملف NGINX الثنائي قيد التشغيل ضمن نطاق إصدارات المصدر المتأثرة، مع مراعاة الحزم الخلفية من التوزيعات (distro backports)؟
2. هل يستخدم الإعداد النشط map مع مدخلات تعبيرات نمطية (regex)؟
3. هل تغذّي التقاطات التعبيرات النمطية المعيّنة تعبيرات نصية لاحقة بترتيب قد يتغير بين مرحلتي الطول والنسخ؟
4. هل تظهر في السجلات عمليات إعادة تشغيل مشبوهة للعامل، أو حلقات انهيار، أو إشارة خطأ البناء المُصلَّح no buffer space in script copy؟

إذا كانت هذه المصطلحات جديدة عليك: العامل (worker) هو عملية NGINX التي تتعامل مع الطلبات. حلقة الانهيار أو إشارة إعادة التشغيل تعني أن العملية قد تفشل ثم تُبدأ من جديد. الحزمة الخلفية من التوزيعة (distro backport) تعني أن موزّعي لينكس يطبّقون أحيانًا تصحيحًا على إصدار يبدو قديمًا دون تغيير رقم الإصدار إلى أحدث إصدار من المصدر.

سير العمل في لمحة

flowchart LR
    advisory["Read advisory and changelog"] --> version["Check NGINX version"]
    version --> config["Review active config"]
    config --> scanner["Run safe map-pattern scanner"]
    scanner --> validate["Validate fixed build or vendor patch"]
    validate --> hunt["Hunt restart and diagnostic signals"]
    hunt --> remediate["Patch, reload, and document"]

محتويات المستودع

• scripts/audit_nginx_map_risk.py
  ماسح استدلالي دفاعي لملفات إعداد NGINX. يبحث عن كتل map ذات التعبيرات النمطية، والالتقاطات، والتعبيرات النصية اللاحقة التي تشير إلى الالتقاطات ومخرجات الخريطة. لا يثبت أن الخادم قابل للاستغلال، بل يعثر على إعدادات تستحق مراجعة بشرية.

• scripts/render_demo_gif.py
  يعيد بناء صورة GIF التجريبية الصغيرة في README من مخرجات الماسح الفعلية.

• detections/splunk_nginx_cve_2026_42533.spl
  عمليات بحث Splunk لجرد الإصدارات، وأعراض الانهيار/إعادة التشغيل، وسلاسل التشخيص بعد التصحيح.

• detections/defender_hunting_notes.kql
  ملاحظات البحث في Microsoft Defender لمضيفي لينكس حيث تُجمع سجلات NGINX ونشاط العمليات.

• detections/sigma_nginx_worker_restart_symptoms.yml
  قاعدة بحث Sigma لأعراض إعادة تشغيل أو انهيار عامل NGINX. هي مؤشر للمراجعة، وليست دليل استغلال.

• samples/nginx_map_patterns.conf
  أمثلة إعداد آمنة وتخطيطية لشرح نمط الخطر. هذه ليست حمولات استغلال.

• SECURITY.md
  ملاحظة نطاق للمستودع. وهذا يبقي المشروع دفاعيًا واضحًا وآمنًا للمراجعة.

• lab/windows-quickstart.ps1 مشغّل أدلة متوافق مع ويندوز ينفّذ الماسح ويحفظ المخرجات تحت .

الأدلة

يُخزَّن التحقق المحلي الحالي في evidence/. يشغّل البدء السريع لويندوز الماسح على إعداد المثال المرفق ويحفظ المحضر. يقوم تحقق Windows NGINX بتنزيل بناء NGINX الرسمي المُصلَّح، ويتأكد من إعداد المختبر عبر nginx -t، ويشغّل الماسح، ويحفظ الأدلة. يشغّل تحقق Kali VM الماسح نفسه داخل ضيف Kali VMware قابل للتخلص. يثبت هذا أن المستودع قابل للتنفيذ والمراجعة على ويندوز ولينكس مع إبقاء المشروع داخل حدود دفاعية.

powershell -ExecutionPolicy Bypass -File .\lab\windows-quickstart.ps1
powershell -ExecutionPolicy Bypass -File .\lab\windows-nginx-validation.ps1
python .\scripts\self_check.py

سير العمل الدفاعي

1. جرد إصدارات NGINX قيد التشغيل.
2. تحقق مما إذا كان موزّعك قد نقل التصحيح إلى إصداره (backport).
3. ابحث في الإعدادات النشطة عن كتل map ذات التعبيرات النمطية (regex).
4. راجع ما إذا كانت الالتقاطات ومخرجات الخريطة تظهر في تعبيرات نصية لاحقة.
5. طبّق التصحيح للوصول إلى 1.30.4+ أو 1.31.3+، أو إلى إصدار NGINX Plus المُصلَّح المناسب.
6. أعد تشغيل العاملين أو أعد تحميلهم، وتأكد من أن الملف الثنائي المُصلَّح يعمل فعليًا.
7. راقب إعادة تشغيل العاملين، وارتفاع الطلبات، ورسالة no buffer space in script copy بعد تطبيق التصحيح.

المصادر

• صفحة النشرة الأمنية لـ NGINX: https://nginx.org/en/security_advisories.html
• سجل تغييرات NGINX: https://nginx.org/en/CHANGES
• سجل NVD لـ CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-42533
• الشرح الفني من Penligent: https://www.penligent.ai/hackinglabs/cve-2026-42533/