ثغرات NGINX: الأسباب والإصلاحات والتحقق من الإنتاج

تاريخ المقالة التاريخية: 2026-10-14 (تاريخ الإفصاح والإصدار الأمني). تم فحص المصادر واستكمال المعلومات من خلال 2026-10-27.

تمت أرشفة هذه المقالة حسب تاريخ الحدث؛ تم تضمين تحديثات الإصدار والإصدار التي تم إصدارها بعد 14 أكتوبر أدناه. الجمهور: موقع NGINX Open Source / NGINX Plus وموظفي تشغيل وصيانة الوكيل العكسي، وموظفي الاستجابة الأمنية، ومشرفي التوزيع، بالإضافة إلى المهندسين الذين يقومون بتجميع NGINX ذاتيًا ويحافظون على وحدات الطرف الثالث.

تركز هذه المقالة على الثغرات الأمنية الأساسية الخمس NGINX التي تم الكشف عنها وإصلاحها بشكل مكثف في 14 أكتوبر 2026، وتنظر أيضًا إلى الثغرات الأمنية المتعلقة بسلامة الذاكرة التمثيلية وتكامل الطلبات من مايو إلى سبتمبر 2026. يغطي المحتوى شروط التشغيل، والأسباب على مستوى التعليمات البرمجية، ونطاق التأثير، وسير عمل الإصلاح، وإجراءات التخفيف قصيرة المدى، وتنفيذ التصحيح الرسمي، والمنافذ الخلفية إلى الفروع القديمة والتحقق من الإنتاج. ترتبط المراجع مثل S1 بملحق المصدر. تُستخدم التكوينات النموذجية فقط لتوضيح أفكار النشر والتدقيق، ويجب التحقق منها استنادًا إلى الإصدار الفعلي ووراثة التكوين والتبعيات وقدرة الأعمال قبل التنفيذ.

TL؛ DR: الإجراءات ذات الأولوية

1. إعطاء الأولوية للترقيات الأمنية. بالنسبة لحزم nginx.org مفتوحة المصدر، قم بتحديث فرع Stable 1.30 إلى 1.30.6 على الأقل وفرع Mainline 1.31 إلى 1.31.7. على الأقل في تاريخ التحقق، 1.31.8 هو الأحدث الافراج عن Mainline. هذه خطوط أساس فرعية منفصلة؛ لا تقارن أعدادهم عبر الفروع. S1S2
2. التحقق من عمليات تثبيت التوزيع بواسطة إصدار الحزمة الكاملة. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 لها منافذ خلفية للموردين؛ يتطلب Debian 13 (trixie) 1.26.3-3+deb13u10 على الأقل. عند التحقق، لا تزال الحزمة Debian 12 (bookworm) 1.22.1-9+deb12u10 تحمل علامة متأثرة. تحقق من كل مكافحة التطرف العنيف؛ لا يثبت تقرير Debian 13 أن Debian 12 قد تم إصلاحه. S13S14S15
3. قم بمراجعة خمس مجموعات تكوين: alias + rewrite + $request_filename، وmap + regex + تقييم المتغير، وaio + ssi + include virtual، وHTTP/3 مع proxy_request_buffering on، وssl_session_cache shared:... مع دوران مفتاح تذكرة الجلسة TLS التلقائي. إن وجود التوجيه وحده لا يثبت إمكانية الاستغلال؛ تقييم مسار الطلب ونطاق التكوين. S1S3S4
4. استبدال كافة العمليات والحاويات القديمة. قم بتشغيل nginx -t، ثم أعد تشغيل الخدمة أو قم بإجراء عملية نشر متجددة عالية الإتاحة. تأكد من خروج عمليات master/worker القديمة؛ nginx -s reload وحده لا يثبت أن الثنائي الجاري تشغيله قد تغير.
5. تحقق من نقاط النهاية الفعلية: HTTP/1.1، وHTTP/2، وHTTP/3 في حالة تمكينها، والتحميلات الوكيلة وهيئات طلب API، ومصادقة شهادة mTLS، وصفحات SSI وسجلات الوصول. قم بتسجيل مصدر الحزمة وإصدارها وملخص الصور والعمليات الجارية والنتائج لكل نقطة نهاية.
6. إذا كانت الترقية الفورية مستحيلة، فقم بإزالة شروط التشغيل القابلة للتطبيق: قم بتعطيل SSI/AIO أو HTTP/3، وقم بمراجعة مراجع متغيرات alias/rewrite/map غير الضرورية، وقم بتقييم ssl_session_tickets off; المؤقتة للمتأثرة خدمات mTLS. تغطي حدود المعدلات وتغييرات التكوين WAF وASLR بعض الشروط فقط ولا يمكن أن تحل محل التصحيحات الرسمية. S3S4S8S12

1. نظرة عامة على الضعف والحكم على المخاطر

أصدرت NGINX 1.30.6 (Stable) و1.31.7 (Mainline) في 14 أكتوبر 2026، لإصلاح خمس مشكلات أمنية. تتضمن ثلاثة منها تجاوزات الكومة أو الاستخدام المجاني بعد الحصول على درجات F5 CVSS v4.0 من 9.2 / Critical. ويؤثر الاثنان الآخران على تكامل طلب HTTP/3 ومصادقة شهادة العميل TLS. S1S2S3

التمييز بين أنظمة التصنيف: يدرج nginx.org جميع المشكلات الخمس على أنها medium، بينما يصنف F5 CVSS v4.0 وبعض وكالات الأمن القومي مشكلات الذاكرة الثلاثة على أنها حرجة. هذا لا يعني أن الخمسة جميعًا يسمحون بتنفيذ غير مشروط للتعليمات البرمجية عن بعد. التكوين وإمكانية الوصول إلى حركة المرور والظروف الخارجة عن سيطرة المهاجم. يعد تلف الذاكرة وRCE الموثوق به مستويات مختلفة من الأدلة. S1S3S4

مكافحة التطرف العنيف	المشكلات الفنية وظروف التشغيل النموذجية	التأثير الأساسي	التقييم والتخلص
CVE-2026-15176	تعيين مسار alias + rewrite تغيير URI + تقييم $request_filename	تجاوز سعة المخزن المؤقت للكومة، تعطل Worker؛ RCE المحتملة في ظل ظروف معينة	F5 CVSS v4.0 9.2; تحديد أولويات استكشاف الأخطاء وإصلاحها
CVE-2026-93479	تقييم البرنامج النصي HTTP/Stream، وخاصة التقاط التعبير العادي map ودليل root، وتسجيل الإسناد الترافقي المتغير	تتم الكتابة فوق المخزن المؤقت المحجوز وتجاوز الكومة؛ RCE المحتملة في ظل ظروف معينة	F5 CVSS v4.0 9.2; هو خطر الانحدار بعد الإصلاحات السابقة
CVE-2026-97205	يتضمن SSI الظاهري وAIO/عملية غير متزامنة؛ تجاوز عدد العمليات المعلقة	الاستخدام بعد الاستخدام المجاني، تعطل Worker، تلف الذاكرة؛ RCE المحتملة	F5 CVSS v4.0 9.2; يتطلب التكوين غير الافتراضي
CVE-2026-95101	HTTP/3 تم تجزئة الإطار غير المعروف عبر المخازن المؤقتة، وتم تمكين التخزين المؤقت لنص طلب الوكيل	إدخال بايتات غير DATA بشكل غير صحيح في نص الطلب الأولي، مما قد يؤدي إلى تجاوز الحد الأقصى لحجم نص الطلب	تؤثر مشكلة عدم الحصانة هذه على تكامل الطلب. لا يوفر في حد ذاته تنفيذ التعليمات البرمجية عن بعد (RCE).
CVE-2026-97629	ذاكرة التخزين المؤقت المشتركة لجلسة TLS، والتدوير التلقائي للمفاتيح، والنسخ المتطابق للمفاتيح Worker	تزوير تذكرة الجلسة؛ قد يحدث تجاوز لمصادقة شهادة العميل لخدمة mTLS المتأثرة	يجب إيلاء اهتمام خاص لتأثير الأعمال لنوع مصادقة الشهادة API

يتم الحصول على درجة CVSS أعلاه بواسطة F5 باستخدام v4.0؛ قد تظهر نفس الثغرة الأمنية خطورة مختلفة في درجات CVSS و3.1 وnginx.org الخاصة بها وتقييمات خطورة التوزيع. S1S3S4

1.1 إعطاء الأولوية لتعرض النشر بدلاً من نتائج CVE وحدها

نموذج النشر	نقاط التحقيق الرئيسية	توصيات أولوية التخلص
الوكيل العكسي للشبكة العامة، بما في ذلك rewrite المخصص وalias وmap المعقد	CVE-2026-15176، CVE-2026-93479 وإعادة كتابة/تخطيط نقاط الضعف من مايو إلى يوليو	P0: التدقيق والتحديث على الفور
API / مستوى الإدارة باستخدام شهادة العميل باعتبارها مصادقة المدخل الوحيد أو الرئيسي	تذكرة الجلسة وتكوين ذاكرة التخزين المؤقت المشتركة لـ CVE-2026-97629	P0: قم بتأكيد حدود المصادقة والتحديث على الفور
توفير تحميل HTTP/3 خارجي، واجهة تغيير الحالة، فئة المعاملة API	CVE-2026-95101، وخاصة نص الطلب الذي يتم توكيله إلى الواجهة الخلفية	P0/P1: الترتيب وفقًا لأهمية العمل
SSI صفحة ديناميكية أو إدخال/إخراج ملف غير متزامن	CVE-2026-97205	P1: قم بتأكيد شروط المجموعة والإصلاح في أسرع وقت ممكن
الصفحات الثابتة فقط + الوكيل العكسي البسيط HTTP/1.1/2	لا يزال التكوين والإصدار بحاجة إلى التدقيق، ولكن قد تكون بعض شروط CVE مفقودة	P1: مضمن في نافذة ترقية الأمان في حالات الطوارئ
استخدم مجتمع Kubernetes المتقاعد ingress-nginx	يتوقف المشروع عن صيانة الأمن، ولا تقتصر المخاطر على هذه المخاطر الخمسة	قم بعمل خطة ترحيل لوحدة التحكم الفردية

P0/P1 هي اقتراحات التخلص من التشغيل والصيانة الواردة في هذه المقالة فيما يتعلق بالتعرض للشبكة العامة وحساسية الشهادة. إنه ليس تصنيف CVSS رسميًا، ولا ينبغي أن يحل محل الأصول الداخلية للمؤسسة وتغيير تقييم المخاطر.

1.2 حدود التأثير وأذونات الهجوم

توجد الثغرات الأساسية في هذه الدفعة بشكل أساسي في مستوى بيانات NGINX: نقطة دخول الهجوم هي اتصال العميل وطلبه، ويحدث التأثير الفعلي عادةً في عملية Worker. إذا تم استيفاء الشروط القابلة للاستغلال لتلف الذاكرة، فسيتم تقييد إذن تنفيذ التعليمات البرمجية بشكل عام من قبل المستخدم قيد التشغيل، وقيود الحاوية، وإمكانات Linux، وأذونات التثبيت والشبكة الخاصة بـ Worker؛ لا يعني RCE المحتمل تلقائيًا امتيازات root أو تسوية المضيف. S4

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

2. تحليل السبب

2.1 فهم الحدود الثلاثة المعرضة للخطأ في NGINX

NGINX worker هي عملية طويلة الأمد تعتمد على الأحداث وتحافظ على حالة الطلب والعمليات غير المتزامنة وموزعي البروتوكول. تجسد مشكلة عدم الحصانة هذه قيودًا على ثلاثة مستويات هندسية:

1. يجب أن يكون تقييم المتغير وحجم الذاكرة متسقين: rewrite بعد تغيير الطلب URI، يجب أن يكون تعيين المسار متسقًا مع location الفعال حاليًا؛ عندما يقوم مترجم البرنامج النصي بحساب الطول المتغير، يجب أن تغطي مساحة الكتابة الإخراج الفعلي والمناطق المحجوزة.
2. يجب أن تعمل العمليات غير المتزامنة على إطالة دورة حياة الذاكرة المطلوبة: عندما تكون هناك قراءة وكتابة ملف غير مكتملة، أو انتظار ذاكرة التخزين المؤقت أو مهام الخيط، لا يمكن تحرير تجمع ذاكرة الطلب ذي الصلة مسبقًا.
3. لا يمكن الخلط بين حالة البروتوكول وحالة الأمان أو حذفهما: HTTP/3 لا يمكن اعتبار طول تخطي الإطار غير المعروف بمثابة طول نص طلب DATA؛ TLS يجب تهيئة جميع فتحات المفاتيح المشاركة في التحقق من التوقيع بشكل صحيح ومزامنتها أثناء تدوير تذكرة الجلسة.

يعتمد المحتوى التالي على الالتزام بالإصلاح الأولي لـ NGINX وإعلان البائع لشرح آلية الفشل التي يمكن تشغيلها؛ جزء المثال المخصص للتحليل، وليس الكود الكامل الذي يمكن استخدامه مباشرة لإصلاح بيئة الإنتاج. S5S6S7S8S9

2.2 CVE-2026-15176: تعيين المسار بين alias وURI المعاد كتابته غير صالح.

في NGINX، يحدد location المطابق وalias مسار الملف؛ يمكن لـ rewrite تغيير الطلب الحالي URI. بعد إعادة الكتابة، قد لا تكون الافتراضات المستخدمة في تعيين location الأصلي صالحة بعد الآن.

لم يتحقق مسار المعالجة المتأثر بشكل كافٍ مما إذا كان الطلب قد تمت إعادة كتابته عند التحقق من حالة alias في ngx_http_map_uri_to_path(). عندما يستمر التكوين في تقييم $request_filename بعد إعادة الكتابة، قد يتم إنشاء المسار بافتراضات لا تتوافق مع حالة URI الحالية، مما يؤدي في النهاية إلى تشغيل كتابة خارج الحدود إلى ذاكرة الكومة. S5

تركيبة نموذجية (تستخدم فقط كمثال مضاد لتدقيق التكوين، ولا يوصى بالنشر):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

لا يقتصر الخطر على return: set، if، add_header، log_format، وما إلى ذلك بحاجة أيضًا إلى التدقيق إذا تم تشغيل تقييم $request_filename في نفس عملية الطلب. return في المثال يجعل مسار الحالة هذا سهل الرؤية فقط، ولا يمكن استخدامه لاستنتاج أن جميع تكوينات الإنتاج ستنتج تجاوزات. S5S10

عواقب الهجوم: قد يؤدي إنشاء طلب إلى إعادة تشغيل Worker أو انقطاع الخدمة؛ في ظل ظروف مثل إغلاق ASLR أو إمكانية تجاوزه، يوجد RCE محتمل. جوهر التصحيح الأولي هو رفض إكمال تعيين مسار URI المعاد كتابته في سياق alias الذي لم يعد صالحًا، بدلاً من مجرد توسيع مخزن مؤقت معين. S5S10

2.3 CVE-2026-93479: عدم التطابق بين “المساحة المحجوزة” والطول المتغير الحقيقي في تقييم البرنامج النصي

تحتوي وحدات HTTP وStream الخاصة بـ NGINX على مقيمين للبرنامج النصي يقومون بتسلسل السلاسل الحرفية والقيم المتغيرة في السلسلة الناتجة. تتضمن أمثلة التطبيقات مسارات root لمستند HTTP، ومسارات سجل الوصول، والتعبيرات المتغيرة في Stream.

تسمح تكوينات معينة للتعبيرات العادية map + بقراءة القيم الملتقطة بواسطة تعبيرات أخرى قبل تقييم متغير النتيجة map. بالاشتراك مع طريقة تنفيذ البرنامج النصي ذات الطول المحجوز، سيحسب التنفيذ القديم المساحة المحجوزة len في مجمع الطول الذي تم تقييمه مسبقًا، بحيث لا تعد حسابات مؤشر الكتابة اللاحقة متوافقة مع حدود المخزن المؤقت. في تسلسل تقييم متغير محدد، قد تؤدي عمليات كتابة السلسلة اللاحقة إلى الكتابة فوق المنطقة المحجوزة، مما يتسبب في تجاوز سعة الكومة. S6

العناصر التشاركية	لماذا يستحق الاهتمام به
التعبير العادي في map	قد يكون لتقييم متغير الالتقاط دورة حياة مستقلة وسلوك تخزين مؤقت
عمليات التقاط مجهولة المصدر، مثل $1، و$2، وما إلى ذلك.	يمكن استبدالها بسهولة بواسطة تعبيرات أو تعبيرات عادية أخرى، مما يجعل من الصعب تتبع الملكية
المتغيرات في root	تنفيذ البرنامج النصي وحجز المخزن المؤقت عند بدء بناء المسار
log_format/مسار السجل الديناميكي	قد يتم تشغيل نفس النوع من التقييم لاحقًا في الطلب
تعبيرات البرنامج النصي في stream	يقوم الإصلاح المنبع أيضًا بتعديل ngx_stream_script_run(). لا يمكنك مراجعة وحدة HTTP فقط.

علاقة انحدار مهمة: يرتبط الكود المتعلق بهذه الثغرة الأمنية بالتغييرات السابقة التي أصلحت CVE-2026-42533. ينص DSA الرسمي لـ Debian 13 بوضوح على أنه تم تقديم الكود المتأثر إلى حزمة trixie عبر منفذ خلفي أمني سابق. لذلك، لا يعني “تم تثبيت تصحيح الثغرات الأمنية map لشهر يوليو” أنه تمت تغطية CVE-2026-93479 لشهر أكتوبر؛ يجب التحقق من سلسلة إصلاح الأمان الكاملة. S6S14S17

ترتبط مخاطر RCE المحتملة هنا ببيئة حماية الذاكرة، ولا ينبغي الادعاء بأن التعبير العادي map وحده سيكون قادرًا على استغلاله من قبل مهاجمين مجهولين. S11

2.4 CVE-2026-97205: AIO يؤدي التفاف عدد العمليات غير المكتملة إلى الاستخدام بعد الحرة

هذه الثغرة الأمنية ليست مجرد “قم بتشغيل SSI وستحصل على UAF”. يكمن المفتاح في العدد المرجعي للعملية غير المتزامنة الموجود في الطلب الرئيسي.

NGINX استخدم r->main->blocked لتتبع المعالجة غير المتزامنة التي لم تكتمل بعد، في التطبيق القديم كان عددها 8 بت؛ لم تقم بعض المسارات بفحص الحد الأعلى قبل زيادة العدد. عندما يتراكم نفس الطلب الرئيسي 256 عملية معلقة، قد يلتف العدد من 255 إلى 0. ستعتقد العمليات اللاحقة خطأً أنه لا توجد عملية غير متزامنة تمنع تحرير الطلب، وبالتالي تحرير تجمع ذاكرة الطلب الذي لا يزال يتم الرجوع إليه بواسطة المهمة. S7

يمكن تقسيم عملية الفشل إلى:

1. مع تمكين مسار الإدخال/الإخراج/مؤشر الترابط غير المتزامن المرتبط، تقدم صفحة SSI طلبات فرعية متعددة أو عمليات قراءة عبر include virtual.
2. يتم تجميع العمليات المعلقة لطلب رئيسي معين حتى الحد الأعلى الذي يمثله حقل العد.
3. يلتف عدد 8 بتات، ويتم التعبير عنه بشكل غير صحيح على أنه “لا توجد عمليات معلقة”.
4. يتم تحرير تجمع ذاكرة الطلب، بينما تظل قراءة الملف أو انتظار ذاكرة التخزين المؤقت أو عمليات الاسترجاعات لمهام مؤشر الترابط تحتفظ بمراجع إليه.
5. تصل عمليات رد الاتصال غير المتزامنة اللاحقة إلى الذاكرة المحررة، مما يؤدي إلى تعطل UAF أو Worker أو تلف محتمل في الذاكرة.

يضيف الإصلاح الرسمي NGX_HTTP_MAX_BLOCKED 250 إلى ملف رأس الطلب، ويضيف قيودًا على مرشح الإخراج وقراءة ذاكرة التخزين المؤقت ومسار مؤشر الترابط الأولي؛ عند الوصول إلى الحد الأدنى، يتم إكمال العمليات ذات المسارات المتزامنة بشكل متزامن، وإذا تعذر معالجتها بأمان، فسيتم رفض إضافة المزيد من المهام المعلقة. S7

حكم قابلية التطبيق: يجب تقييم ما إذا كان من الممكن حدوث SSI وAIO والتضمين الافتراضي والطلبات الفرعية والعمليات غير المتزامنة ذات الصلة معًا في نفس سلسلة الطلب. هذه عادةً ليست تكوينات الوكيل الثابتة العادية الافتراضية. يمكن لـ aio off; أو ssi off; إزالة عناصر تشغيل محددة، ولكن يجب تأكيد تبعيات وظيفة العمل أولاً. S4S7S25

2.5 CVE-2026-95101: يتم الخلط بين الإطار غير المعروف HTTP/3 وحالة نص الطلب DATA

يجب أن يميز محلل الإطارات HTTP/3 بين إطارات DATA (التي تحتاج إلى تمريرها إلى معالجة نص طلب HTTP) والإطارات غير المعروفة التي يجب تخطيها. يجب أيضًا الحفاظ على طول الإطارات غير المعروفة بدقة عند التجزئة عبر المخازن المؤقتة للشبكة.

استخدم التطبيق القديم لـ ngx_http_v3_parse_data() حقل st->length لحفظ “العدد المتبقي من البايتات التي سيتم تخطيها” عند تخطي إطارات غير معروفة، بينما يفسر مرشح نص الطلب نفس الحقل على أنه “طول الحمولة المتبقية DATA”. إذا حدث أن الإطار غير المعروف يغطي مكالمات تحليل متعددة، فقد يتم الخلط بين الدفعة التالية من البايتات بعد مقاطعة التحليل كجزء من نص الطلب. S8

ينشأ نوعان من المخاطر:

• حقن نص الطلب: قد يتم نقل حمولة الإطار غير DATA التي أرسلها العميل إلى التطبيق الأولي، مما يؤدي إلى تغيير البيانات المستلمة فعليًا بواسطة الواجهة الخلفية.
• يتجاوز الحد الأقصى للحجم: client_max_body_size والقيود الأخرى. تتركز عمليات التحقق المتوقعة على مسار DATA، وقد يتجاوز المحتوى المحول بشكل غير صحيح عملية التحقق المقابلة.

سيناريو التشغيل النموذجي الذي وصفه المسؤول هو عندما يتلقى ngx_http_v3_module طلب HTTP/3 ويعيد توجيه proxy_request_buffering on. يتم تمكين التخزين المؤقت لنص طلب الوكيل بشكل افتراضي في ngx_http_proxy_module. ولذلك، يجب التحقق أولاً من الوكيل العكسي الذي يقوم بتشغيل HTTP/3. ليس من المناسب افتراض عدم وجود شرط تشغيل لمجرد عدم كتابة proxy_request_buffering on; بشكل صريح. S8S18

النتيجة المباشرة لهذه الثغرة الأمنية هي تكامل طلب الواجهة الخلفية وتغيير حدود الأمان، وهو ليس التعبير المكافئ لـ RCE المكتمل مباشرة في نواة NGINX. يعتمد التأثير النهائي للأعمال على كيفية تحليل هذه البايتات والوثوق بها في المراحل الأولية. S24

2.6 CVE-2026-97629: TLS يفتقد دوران التذكرة فتحة المفتاح الثالث

في التكوينات المتأثرة، يمكن لـ NGINX إنشاء مفاتيح تذكرة جلسة TLS وتدويرها تلقائيًا من خلال ذاكرة التخزين المؤقت للذاكرة المشتركة، مما يسمح لـ Worker المتعددة بمعالجة نفس مجموعة التذاكر.

يخصص منطق المزامنة ذي الصلة 3 فتحات رئيسية لكل Worker، وسيقوم رد اتصال فك التشفير أيضًا باجتياز هذه الفتحات؛ لكن التطبيق القديم ينسخ فقط فتحتين رئيسيتين من الذاكرة المشتركة في كل مرة، مما يؤدي إلى اسم المفتاح ومفتاح HMAC وAES للفتحة الثالثة. قد يظل المفتاح غير مهيأ. إذا كان معرف المفتاح للتذكرة مطابقًا لهذه الحالة، فقد يتم استخدام مادة مفتاح غير مهيأة للتحقق من التوقيع وفك التشفير، وبالتالي تشكيل مسار لتزوير جلسة TLS. S9

عادةً ما تكون مجموعات النشر عالية المخاطر:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

أخطر عواقب الأعمال لهذه الثغرة الأمنية هي أنه في الخدمات التي تستخدم مصادقة شهادة العميل (mTLS) في ssl_verify_client on; وطرق أخرى، قد تتجاوز جلسات الاسترداد المزورة التحقق من شهادة العميل. إن نجاح الهجوم يخضع أيضًا لظروف لا يمكن السيطرة عليها. موقع يستخدم فقط شهادة HTTPS عادية من جانب الخادم ولا يجب أن يتم وصف مصادقة شهادة العميل بشكل خاطئ على أنه “يمكن للمهاجم تجاوز تسجيل الدخول إلى موقع الويب بالكامل.” S9S12

هذه مشكلة حالة مصادقة جلسة TLS وليس لها علاقة بما إذا كان المفتاح الخاص TLS الخاص بالخادم قد تم اختراقه أو ما إذا كانت شهادة CA root العامة قد تأثرت. S24

2.7 كيفية فهم DoS وRCE وتجاوز المصادقة وعمليات الاستغلال المعروفة

• DoS: خطأ في الذاكرة يتسبب في تعطل Worker أو إعادة التشغيل على نطاق واسع. ويرتبط ما إذا كان يسبب عدم التوفر بشكل عام بضغط حركة المرور، والقدرة على إعادة تشغيل العملية، ووقت صيانة الاتصال، والهندسة المعمارية عالية التوفر.
• RCE المحتملة: تشير بعض الإعلانات إلى إمكانية تنفيذ التعليمات البرمجية عند إغلاق ASLR أو تجاوزه. هذا لا يعني أنه تم الكشف عن سلسلة هجوم عامة يمكنها تنفيذ الأوامر بشكل مستقر وعالمي. S4
• طلب تجاوز الحقن/المصادقة: قد يغير حالة العمل المحمي أو محتوى الطلب مباشرة، ولا يمكن تجاهله لمجرد أنه لا يحصل على الصدفة مباشرة.
• اكتشف محاولات الهجوم: CVE-2026-42945 في مايو 2026 لديه تقارير عن أنشطة استغلال داخلية؛ لا ينبغي أن نستنتج بشكل مباشر أن هذه الحقيقة التاريخية تعني أن جميع مكافحة التطرف العنيف الخمسة في أكتوبر قد تم استغلالها بنجاح على نطاق واسع. S23

3. إصلاح الإصدار واختيار التصحيح

3.1 NGINX Open Source خط الأساس الرسمي للتصحيح

فرع المنبع	النسخة الرسمية الأولى تغطي خمس نقاط ضعف في أكتوبر	التوصيات اعتبارًا من 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	قم بتثبيت 1.30.6 على الأقل، ثم قم بمتابعته مع إصدارات الأمان اللاحقة.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
فرع NGINX Open Source السابق	لا يمكن الحكم عليه فقط بناءً على “تم تطبيق تصحيحات الثغرات القديمة”	قم بالانتقال إلى الفرع الذي تتم صيانته أولاً؛ وبخلاف ذلك، يتعين على البائع تقديم دليل رسمي على الدعم على أساس CVE-by-CVE.

هذه هي استنتاجات الإصدار للكود المصدري/الفرع الرسمي لـ nginx.org، ولا ينبغي استخدامها لرفض حزمة الأمان مباشرةً مع الإصلاحات الخلفية المقدمة من بائع التوزيع. حتى لو كانت قيمة 1.31.6 أكبر من 1.30.6، فإنها لا تزال أقل من خط الأساس للتصحيح للفرع الرئيسي. S1S2

3.2 نطاق التأثير الأولي لخمسة تحديات خطيرة

تم إدراج النطاقات التالية وفقًا للنص الأصلي لنشرة الأمان nginx.org ويجب فهمها جنبًا إلى جنب مع “الفرع الحالي قيد التشغيل” و”مسار التكوين الفعلي”:

مكافحة التطرف العنيف	العلامات المنبع تتأثر الإصدارات	النسخة الثابتة المسمى رسميا
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ أو 1.31.7+، ضمن الفروع الخاصة بكل منهما
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	نفس ما ورد أعلاه
CVE-2026-97205	0.8.11–1.31.6	نفس ما ورد أعلاه
CVE-2026-95101	1.25.0–1.31.6	نفس ما ورد أعلاه
CVE-2026-97629	1.23.2–1.31.6	نفس ما ورد أعلاه

CVE-2026-93479 له حدود محددة لإصدار المقدمة؛ لا يتأثر كل إصدار NGINX القديم بهذا الانحدار. قد تظل الإصدارات الأقدم خارج هذه النطاقات متأثرة بالثغرة الأمنية السابقة map regex CVE-2026-42533. S1

3.3 Ubuntu: منافذ التوزيع الخلفية (USN-8955-1)

يوفر Canonical USN-8955-1 بتاريخ 26 أكتوبر 2026 تحديثًا أمنيًا لأربعة إصدارات Ubuntu: S13

نسخة Ubuntu	nginx ونفس الإصدار الثابت لحزمة المصدر	الوصف
22.04 LTS	1.18.0-6ubuntu14.22	إنه منفذ خلفي للبائع. لا يزال رقم الإصدار الأولي يظهر 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	نفس ما ورد أعلاه
26.04 LTS	1.28.3-2ubuntu1.12	نفس ما ورد أعلاه
26.10	1.30.4-7ubuntu1.1	نفس ما ورد أعلاه

يحتوي الإعلان على إصدارات ثابتة مقابلة من الحزم المتماثلة مثل nginx-core، وnginx-extras، وnginx-full، وnginx-light. لا تستخلص استنتاجات حول ما إذا كان سيتم إصلاحه من الجزء الأولي الذي يظهر فقط بواسطة nginx -v. مثل Ubuntu 24.04 و1.24.0-2ubuntu7.19 تم تصحيحها بواسطة هذا البائع، ولكن 1.24.0 من أي مصدر ليس آمنًا بطبيعته.

تم وضع علامة Ubuntu رسميًا بوضوح أيضًا على أن CVE-2026-95101 يؤثر فقط على Ubuntu 26.04 / 26.10، وCVE-2026-97629 يؤثر فقط على Ubuntu 24.04 / 26.04 /26.10. إليك التغليف والنطاق الوظيفي الخاص بـ Ubuntu، والذي لا يمكن ترقيته مباشرة إلى توزيعات أخرى. S13

3.4 Debian: يجب التحقق من الاختلافات بين الإصدارات بشكل منفصل

تغطي استشارة Debian DSA-6575-1 (2026-10-21) هذه المخاطر الخمسة الكبرى وتحدد حزمة nginx الثابتة لـ Debian 13 / trixie على النحو التالي:

1.26.3-3+deb13u10

ومع ذلك، اعتبارًا من وقت التحقق من هذا التقرير، لا يزال يتم وضع علامة على 1.22.1-9+deb12u10 لـ Debian 12 / bookworm على أنها عرضة للخطر بواسطة Debian Security Tracker. لذلك:

• Debian 13 ما عليك سوى التحديث والقبول وفقًا لـ DSA-6575-1.
• يجب أن يتحقق Debian 12 من إصلاحات الأمان التي يوفرها متتبع الأمان الحالي أو بائع ELTS واحدًا تلو الآخر؛ قبل تأكيد الإصلاح في الإعلان، لا تعلن أنه تم إصلاح جميع العناصر الخمسة بناءً على نجاح apt upgrade.
• قد تحمل الحزمة المصدر Debian مجموعة تصحيحات مستقلة عن رقم الإصدار nginx.org. بالنسبة للإصدارات المخصصة، تحتاج إلى التحقق من مجموعة إصلاح حزمة التعليمات البرمجية المصدر الكاملة، ولا يمكنك فقط نسخ التزام واحد واعتباره مكتملاً.

يعتمد التمييز أعلاه على سجلات تتبع DSA وCVE. S14S15S16

3.5 NGINX Plus، njs ووحدة التحكم في الدخول

المنتجات/المكونات	النقاط الرئيسية لاختيار الأمان والتحقق
NGINX Plus (النسخة التجارية)	يرجى الرجوع إلى تعليمات الإعلان والترقية الخاصة بفرع Plus المطابق لـ F5. أحدث CR في وقت التحقق هو PLS.37.2.0.1، والبنية الأمنية لـ LTS هي PLS.37.0.7.1؛ لا يمكن استبدال الإصدار Plus والمنفذ الخلفي المضمن مباشرةً بعتبة 1.30/1.31 الخاصة بالمصدر المفتوح. S19
njs / ngx_http_js_module	2026-10-14 يصدر njs 1.0.2 ويصلح CVE-2026-101019 وCVE-2026-101025؛ إذا كنت تستخدم njs، فيجب عليك أيضًا التحقق من توافق الوحدة مع NGINX. S20
F5 NGINX وحدة التحكم في الدخول / نسيج البوابة	إن NGINX عبارة عن سلسلة توزيع برمجيات ذات صلة ولكنها مستقلة. قم بإصلاح الثغرات الأمنية ذات الصلة باستخدام وحدات التحكم والصور وملاحظات الإصدار الخاصة بكل منها. لا يمكنك فقط استبدال ثنائي NGINX في Pod.
مجتمع Kubernetes kubernetes/ingress-nginx	تم إيقاف تشغيل المشروع في مارس 2026 ولن يوفر صيانة أمنية جديدة بعد الآن. يجب أن تخطط للانتقال إلى وحدة التحكم التي تمت صيانتها أو Gateway API بدلاً من الخلط بين رقم إصدارها وF5 NGINX Ingress Controller. S21

3.6 ما هو التصحيح الذي يجب أن تختاره بالفعل؟

نموذج النشر	الممارسات الموصى بها	إثبات الإصلاح
حزمة nginx.org DEB/RPM الرسمية	الترقية إلى الإصدار الثابت من فرع المنبع	nginx -v/-V، مصدر الحزمة، إعلان أمني رسمي
المستودع الرسمي Ubuntu/Debian	تثبيت حزم أمان البائع	إصدار الحزمة الكاملة + حالة البائع USN/DSA + CVE
RHEL/ألما/روكي/سوسي/توزيعات أخرى	قم بالترقية وفقًا لنشرات أمان التوزيع المحددة وإصدارات الحزمة	لا يمكن تطبيق إعلان/CSAF للمورد المقابل، إصدار Ubuntu/Debian
صور الحاوية الرسمية أو المخصصة	قم بإعادة بناء أو سحب صورة الإصلاح التي تم التحقق منها واستبدالها على أساس دوري	ملخص الصورة، إنشاء SBOM، تشغيل معرف صورة الكبسولة/الحاوية
NGINX، أو OpenResty، أو Tengine، أو الإصدارات التي تم تصحيحها باستخدام وحدات خارجية	إعطاء الأولوية لاستخدام الإصدار الأمني الكامل الخاص بالمشرف؛ تنفيذ عمليات تصحيح خلفية تمت مراجعتها لشجرة المصدر المستهدفة عند الضرورة	خمسة إصلاحات للثغرات الأمنية، وتوافق ABI/الوحدة النمطية، وانحدار الوحدة والأعمال

OpenResty وTengine هما نظامان إصدار مختلفان؛ يصف هذا الجدول طريقة التحقق فقط. لا يعني ذلك أن جميع إصداراته ستتأثر في نفس الوقت مع NGINX القياسي، ولا يمكن تطبيق تصحيح التعليمات البرمجية الأولية دون قيد أو شرط.

4. عملية الإصلاح الرسمية

4.1 جرد الحالات الفعلية لتلقي حركة المرور الخارجية

قم بتجميع كل إدخال على الأقل:

• اسم المجال، وموازنة التحميل/CDN/رابط وكيل الحافة، وطريقة التعرض للموقع الأصلي وبروتوكول الشبكة المستخدم.
• منتجات NGINX (مفتوحة المصدر، Plus، Ingress، وما إلى ذلك)، النسخة الكاملة، مصدر مستودع الحزمة، ملخص الصور.
• يعرض nginx -V وحدات البناء ومعلمات التجميع؛ ما إذا كانت هناك وحدات ديناميكية njs وLua وOpenResty ووحدات ديناميكية خارجية.
• تشغيل حقيقي لـ master/worker PID ووحدة الخدمة/الحاوية/الكبسولة والنسخة المتماثلة وعقدة Worker.
• التكوينات الفعالة الفعلية http/stream، server، location، include.
• ما إذا كان سيتم تمكين HTTP/3، وmTLS، وSSI/AIO، ومسار السجل الديناميكي، وmap المعقد والتقاط التعبير العادي.

لا تقم فقط بالتحقق من /etc/nginx/nginx.conf الافتراضي. غالبًا ما تقوم بيئة الإنتاج بتحميل مواقع متعددة وتكوينات TLS والوحدة النمطية من خلال include. قد يكون هناك أيضًا مسارات تثبيت NGINX متعددة أو طبقات وكيل متعددة.

4.2 التحقق من معلومات الإصدار والتجميع

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

يُبلغ nginx -V عن إنشاء الملف الثنائي الموجود في مسار سطر الأوامر؛ لا يثبت أن worker قيد التشغيل قد قام بتحميله. قد يحذف nginx -v لاحقة الحزمة الكاملة للتوزيع، لذا تحقق من مدير الحزم أو سجلات سلسلة التوريد أيضًا.

4.3 قم بتصدير التكوين الفعال وإجراء الجولة الأولى من الفحص الثابت

سيقوم nginx -T باختبار التكوين وتفريغ التكوين المدمج. قد يحتوي الإخراج على معلومات حساسة مثل بيانات اعتماد المصادقة، ومسارات المفاتيح، وأسماء المضيفين الداخليين، وما إلى ذلك. يوصى بحفظ الجهاز الذي يتم التحكم فيه بأذونات root وأذونات الملفات الخاصة، وعدم نشر الملفات الأصلية إلى أوامر العمل العامة:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

هذا مجرد محدد مسار المرشح، وليس أداة تحديد تلقائية موثوقة لمكافحة التطرف العنيف:

1. لا يمكن لـ grep تحديد ما إذا كانت المتغيرات موجودة في نفس location أو في نفس سلسلة تقييم الطلب، ولا يمكنها استنتاج علاقة توريث التكوين.
2. proxy_request_buffering on، تحتوي بعض تكوينات ذاكرة التخزين المؤقت والتذكرة على قيم افتراضية، وعدم كتابة التعليمات المقابلة لا يعني اختفاء الخطر.
3. قد تختلف التكوينات التي تم إنشاؤها بواسطة الوكلاء العكسيين، أو CDN، أو العربات الجانبية للحاوية، أو وحدات التحكم عن الملفات التي تم فحصها يدويًا.
4. قد يلزم تأكيد خصائص NGINX Plus والوحدات الديناميكية باستخدام أدوات الإدارة الرسمية الخاصة بها.

4.4 قم بنشر الإصلاح من خلال القنوات الموثوقة

Debian/Ubuntu (مستودع التوزيع الرسمي):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

لا يمكن لمجموعة الأوامر هذه إنشاء إصلاحات أمنية من فراغ غير متوفرة بعد. خاصة بالنسبة لـ Debian 12، إذا كانت الحزمة التي تمت ترقيتها لا تزال تعتبر معرضة للخطر من قبل نظام التتبع الأمني، فستكون هناك حاجة إلى إجراءات إضافية لإصلاح البائع أو عزله أو ترحيله. S13S14S15

الحزمة الرسمية nginx.org:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

في حالة استخدام OpenResty أو Tengine أو NGINX Plus المجمعة ذاتيًا، استخدم إصدار الإصلاح المدعوم من المشرف المقابل ولا تخلط بين nginx.org وحزم التوزيع ومستودعات الطرف الثالث. يجب الحفاظ على الثنائيات/الصور الأصلية والتكوينات والتوقيعات وبيانات نشر التراجع.

الحاويات/Kubernetes: قم بتحديث الصورة غير القابلة للتغيير، وقم بتسجيل ملخصها واستبدال جميع النسخ المتماثلة القديمة بطرح مرحلي. يؤكد kubectl rollout status فقط أن وحدة تحكم النشر قد انتهت؛ تحقق أيضًا من ملخصات الصور وتوجيه الدخول والنسخ المتماثلة غير الصحية.

4.5 التحقق من التكوين واستبدال Worker القديم

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

لا تعامل nginx -s reload كدليل على تشغيل ثنائي جديد: تتيح عمليات إعادة تحميل التكوين العادية لـ master القديم بدء عمال جدد دون استبدال الملف القابل للتنفيذ. يدعم NGINX إجراء ترقية ثنائي مخصص عبر الإنترنت، ولكنه يتطلب خطوات إضافية وتحققًا. بدون إجراء محدد، استخدم مفتاح حركة مرور عالي التوفر متبوعًا بإعادة تشغيل الخدمة، أو قم بطرح حاويات بديلة. S22

إذا كنت تدير NGINX عبر مقبس systemd أو البرنامج النصي لإدخال الحاوية أو عمليات التثبيت المتعددة، فيجب عليك التحقق من هدف التشغيل الفعلي ومسار العملية بدلاً من الافتراض المباشر أن systemctl restart nginx يغطي جميع المثيلات.

4.6 قبول وتنفيذ انحدار الأعمال من المدخل الخارجي الحقيقي

يوصى بإجراء ما يلي على الأقل:

• هل HTTPS العادي والمسارات المعاد كتابتها والموارد الثابتة وصفحات تعيين alias صحيحة.
• هل توزيع map العادي، ومسار root المتغير، ومسار سجل الوصول، وتوجيه SNI/الشهادة، والوكيل Stream صحيح.
• هل لا تزال عمليات التحميل العادية والتحميلات المقسمة وطلبات API وحدود حجم المنبع لـ HTTP/3 (عند تمكينها) كما هو متوقع؟
• mTLS: يجب أن تنجح طلبات الشهادات الشرعية؛ يجب الاستمرار في رفض الشهادات المفقودة أو منتهية الصلاحية أو غير المصرح بها، ويجب ألا يؤدي استئناف/إعادة الاتصال بـ TLS إلى تغيير الأذونات عن طريق الخطأ.
• ما إذا كان الوصول إلى صفحة SSI والملف غير المتزامن أمرًا طبيعيًا؛ لا يُظهر سجل الأخطاء أي طلبات غير طبيعية لمراجع الذاكرة أو أعطال Worker المتكررة.
• بعد تبديل حركة المرور، يجب أن يتم الخروج من عملية الإصدار القديم والنسخة المتماثلة للصورة القديمة.

يجب إجراء الاختبار في بيئة خاصة أو معتمدة. لا يمكن لاختبار دخان الطلب العادي أن يثبت وحده أنه تم إصلاح ثغرة الذاكرة؛ في النهاية، يجب قبول الإصدار الثابت للمورد وتصحيح التعليمات البرمجية المصدر واختبار وقت التشغيل بشكل مشترك للقبول.

5. تدابير التخفيف عندما لا يكون الترقية الفورية ممكنة

يعد هذا القسم خيارًا لتقليل المخاطر، وليس بديلاً للتصحيح. يجب عمل نسخة احتياطية لجميع تغييرات التكوين المؤقتة، وتنفيذ nginx -t، وإصدارها على دفعات، والتراجع عنها سريعًا إذا لزم الأمر. S3S4

5.1 التحكم في أولوية حركة المرور بناءً على التعرض الخارجي

إعطاء الأولوية لتقليل سطح الهجوم للخدمات التي لا يمكن ترقيتها في الوقت المناسب: على سطح الإدارة وAPI الداخلي، أضف التحكم في الوصول إلى المصدر الموثوق به، وعزل الشبكة الأولية أو عدم الاتصال بالإنترنت على المدى القصير؛ إضافة الاتصال وهيئة الطلب وحدود الأسعار إلى المداخل عالية المخاطر؛ تأكد من حدوث مصادقة المصدر في NGINX ذات الصلة بالإدخال قبل سلسلة معالجة الطلب. تجدر الإشارة إلى أن معظم الثغرات الأمنية نفسها موجودة في NGINX داخل مستوى البيانات، قد لا تحدد قواعد WAF التقليدية شروط تشغيل التكوين المخصص بدقة.

5.2 alias / rewrite: تجنب تقييم $request_filename بعد إعادة الكتابة

يوصى بفحص وضبط:

• حاول عدم تنفيذ rewrite الذي سيغير URI في نفس الوقت مع location باستخدام alias.
• تجنب استخدام $request_filename عندما تتم إعادة كتابة URI لكن مطابقة الموضع الصحيح لم تكتمل بعد.
• تحقق من وجود مراجع متغيرات غير مباشرة في return، وset، وif، وadd_header، وتنسيق سجل الوصول، وقم بتضمين الملفات.
• استخدم root/try_files/location المستقل الواضح عندما تسمح الأعمال بذلك، ولكن فقط قم بتغيير alias إلى root. وقد يغير أيضًا دلالات مسار الملف، والتي يجب التحقق منها واحدًا تلو الآخر.

لا تقم بنسخ “قالب إعادة الكتابة الآمنة” الشائع مباشرةً على الإنترنت لاستبدال التكوين الحالي. تؤدي بادئات location المختلفة وإعادة كتابة الأهداف إلى ربط المسار بمعاني مختلفة تمامًا. S5

5.3 map/Regex: تقليل خلط حالة الالتقاط المتغيرة

يوصى بإعطاء الأولوية للالتقاطات المسماة والحد من نطاق نشرها، بدلاً من السماح بإعادة استخدام الالتقاطات المجهولة مثل $1 عبر مسارات تقييم regex المختلفة مع مرور الوقت. على سبيل المثال:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

يوضح هذا المقتطف فقط بنية أسهل للتدقيق للملكية المتغيرة؛ لا يعني أنه قد ثبت أنه يزيل بشكل مستقل جميع مسارات تشغيل CVE-2026-93479. على وجه الخصوص، راجع ما إذا كان يتم الرجوع إلى متغيرات الالتقاط مسبقًا بواسطة root أو log_format الأخرى، وما إذا كان هناك volatile ومسارات ديناميكية وسلاسل تقييم مترابطة. توصي F5/CERT باستخدام الالتقاط المسمى وقصر نطاق الاستخدام على تكوين المطابقة العادية المطابق كإغاثة قصيرة المدى. S3S6

5.4 AIO + SSI: إيقاف تشغيل مجموعات الوظائف غير الضرورية

بالنسبة للخوادم/المسارات التي لا تتطلب SSI أو إدخال/إخراج ملف غير متزامن، استخدم:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

من منظور ظروف إثارة الثغرة الأمنية، عادةً ما يكون إغلاق أحد الاثنين كافيًا لإزالة السلسلة المحددة الموصوفة؛ ولا ينطبق الإغلاق في نفس الوقت إلا على السيناريوهات التي لا تعتمد فيها الشركة على هذه الإمكانية. التحقق من سلوك include virtual والطلبات الفرعية وذاكرة التخزين المؤقت وتجمع مؤشرات الترابط؛ عندما يكون تحميل الوكيل العكسي مرتفعًا، قد يؤدي إيقاف تشغيل AIO إلى تغيير زمن الوصول وأداء الإدخال/الإخراج. S7

5.5 HTTP/3 طلب حقن الجسم: أغلق المدخل مؤقتًا إذا لزم الأمر

قم بتعطيل مستمع quic الذي يشتمل على HTTP/3، وقم بإلغاء رأس الاستجابة Alt-Svc الذي يعلن عن HTTP/3، وتحقق مما إذا كانت طبقة الحافة/موازن التحميل لا يزال يرسل طلبات QUIC مباشرة إلى NGINX التي لم يتم إصلاحها:

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

ما ورد أعلاه هو مجرد وصف لفرق التغيير، وليس تكوينًا كاملاً للخادم يمكن تمكينه بشكل فردي. يرتبط بناء جملة الإعداد HTTP/2 بإصدار NGINX؛ إذا كنت بحاجة إلى الاحتفاظ بـ HTTP/2، فيجب عليك استخدام http2 on; أو بناء الجملة الصحيح الحالي وفقًا للإصدار المقابل، والتحقق من ذلك باستخدام nginx -t. يجب دمجها مع تكوين الخادم الحالي قبل النشر، بدلاً من استبدال القسم بأكمله بهذا القسم. يتحقق أيضًا من جدار الحماية UDP 443 وموقع إنهاء HTTP/3 والمسار الاحتياطي للعميل لـ CDN/الوكيل الأمامي.

هناك نوع آخر من التخفيف على المدى القصير وهو استخدام proxy_request_buffering off; على مسار الوكيل المتأثر، ولكن هذا سيغير سلوك تدفق نص الطلب الأولي، وإعادة المحاولة الفاشلة، وبعض سير عمل التحميل؛ لا يمكن استخدامه إلا بعد إجراء اختبارات كافية والتأكد من أن التوجيه قد وصل إلى مسار الوكيل HTTP/3 المتأثر. S8S18

تذكرة جلسة 5.6 TLS: حماية الأولوية mTLS حد المصادقة

إذا لم تكن الترقية ممكنة وكان المثيل يعتمد على ذاكرة التخزين المؤقت للجلسة المشتركة + التدوير التلقائي لمفتاح التذكرة، فقم بتقييم:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

يمكن أن يؤدي هذا إلى إيقاف تشغيل آلية تذكرة الجلسة TLS، وبالتالي إزالة مسار تزوير التذكرة الموضح في هذه الثغرة الأمنية؛ ومع ذلك، قد يؤثر على أداء استئناف جلسة العمل. لا يمكنك فقط إيقاف تشغيل التحقق من شهادة العميل mTLS “لتجنب الثغرات الأمنية”، لأن ذلك سيؤدي مباشرة إلى حذف حدود المصادقة الأصلية. S9S12

يمكن أيضًا استخدام ملفات ssl_session_ticket_key الصريحة والتدوير الآمن من خلال عمليات إدارة TLS الاحترافية للتحايل على الشروط التي يتم إنشاؤها تلقائيًا، ولكن يجب تدقيق المفاتيح والتوزيع الكامل للعقدة والتدوير ودورات حياة التذاكر القديمة بعناية. لا يُنصح بترميز مفتاح طويل الأمد قابل لإعادة الاستخدام في تكوين الويب العادي أو البرامج النصية لحالات الطوارئ المؤقتة. يجب أيضًا مراقبة الخدمات المهمة التي تستخدم mTLS لسلوك استئناف جلسة TLS ورفض الطلبات بدون شهادة عميل صالحة. S12

5.7 دور نظام التشغيل وحماية الحدود

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR، والعمال غير root، وأنظمة ملفات الحاويات للقراءة فقط، والحد الأدنى من أذونات الملفات وعزل الشبكة يمكن أن تقلل من تأثير RCE المحتمل. لا يقوم ASLR بإصلاح تجاوزات الكومة أو UAF ولا يضمن عدم تعطل العمال. WAF وحدود المعدل وحدود حجم نص الطلب لا تعمل على إصلاح مزامنة مفتاح التذكرة TLS. S4

5.8 سوء فهم شائع: هذه العمليات ليست كافية لإكمال عملية الإصلاح

العمليات المشتركة	لماذا هي غير كافية؟
“يبدو nginx -v جديدًا نسبيًا”	لم يتم التحقق من الفرع الذي ينتمي إليه، وإصدار الحزمة الخلفية الكاملة لإصدار الإصدار والعملية عبر الإنترنت.
”تمت ترقية شبكة إنترانت واحدة فقط”	لا يزال المثيل الأصلي Worker/الحاوية القديمة/المثيل الأصلي CDN يتلقى الطلبات
”الموقع لا يستخدم علامات PHP/الديناميكية”	يحدث الخلل في المسار الأساسي NGINX أو تحليل البروتوكول ولا يعتمد على تنفيذ PHP.
”فتح WAF/Cloudflare يكفي”	لا يمكن إثبات قيام WAF بحظر جميع عيوب الذاكرة المعتمدة على تكوين NGINX أو عيوب استئناف TLS
”تم فتح ASLR بالفعل”	مجرد الاستفادة من تخفيف الصعوبة؛ DoS مع طلب الحقن لا يزال ممكنًا
”HTTP/3 غير مكشوف للشبكة العامة، لذلك ليست هناك حاجة للترقية على الإطلاق”	ولا تزال تحديات مكافحة التطرف العنيف الأربعة الأخرى تتطلب تقييما مستقلا؛ وقد تكون هناك اتصالات مباشرة بأصول خفية
”تم إصلاح الثغرة الأمنية map لشهر يوليو”	يتضمن CVE-2026-93479 لشهر أكتوبر مشكلات انحدار تقييم البرنامج النصي اللاحقة
”تعطيل التخزين المؤقت يحل جميع المشاكل”	يؤثر فقط على بعض ذاكرة التخزين المؤقت TLS أو سيناريوهات AIO، ولا يغطي الاسم المستعار، البرنامج النصي، HTTP/3

6. أفكار تنفيذ التصحيح الرسمية ونقاط المراجعة

يتبع هذا القسم إصلاحات NGINX لشهر أكتوبر 2026. توضح المقتطفات التغييرات التمثيلية لمراجعة التصحيح؛ فهي ليست إصلاحات كاملة وقابلة للتجميع بشكل مستقل. بالنسبة للإصدارات المخصصة، راجع الالتزامات الكاملة والتعليمات البرمجية والاختبارات المحيطة، وفضل إصدارًا مدعومًا كاملاً. S5S6S7S8S9

6.1 CVE-2026-15176: تمت إعادة كتابة URI لتشمل شروط رفض تعيين المسار alias

تم تعديل التزام المنبع ngx_http_map_uri_to_path() في src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

التركيز على المراجعة: لا يمكن الاستمرار في حساب مسار نظام الملفات عند تغيير URI ولكن دلالات الموقع المقابلة لـ alias لم تعد موثوقة. وهذا تعزيز لقيد ما قبل الدولة. ليس من السهل التحقق مما إذا كان الطلب URI يحتوي على أحرف غير قانونية. S5

6.2 CVE-2026-93479: التمييز بشكل صحيح بين طول بيانات الإخراج والطول المحجوز

يقوم الالتزام المنبع بتحديث src/http/ngx_http_script.c وsrc/stream/ngx_stream_script.c في نفس الوقت. ويمكن تلخيص النية الأساسية على النحو التالي:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

هنا، pool هو اسم معلمة توضيحية: تختلف تعبيرات تخصيص HTTP وStream الفعلية. يقوم التغيير بحساب طول إخراج البرنامج النصي أولاً، ثم يضيف الطول المحجوز إلى التخصيص النهائي بحيث لا يقوم الإخراج بالكتابة فوق المساحة المحجوزة. S6

عند التدقيق والنقل الخلفي، يجب أيضًا تغطية المقيم المقابل لـ HTTP/Stream؛ فقط التحقق من ملف بناء جملة التكوين map لا يمكن إثبات أنه تم إصلاح الخلل.

6.3 CVE-2026-97205: تعيين حد الأمان لعدد العمليات غير المتزامنة 8 بت

تمت إضافة المنبع في src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

وأضف إدخالات مماثلة لقراءة الملفات غير المتزامنة وانتظار ذاكرة التخزين المؤقت وتصفية الإخراج وتشغيل الخيط:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

التركيز على المراجعة: يجب تغطية جميع مسارات التعليمات البرمجية الفعلية التي ستضيف r->main->blocked. لا يمكنك فقط كتابة ثابت العتبة في ملف الرأس. يحتاج Backport أيضًا إلى التحقق من التنسيق الكامل للرد الاحتياطي المتزامن ورد الاتصال غير المتزامن وإرجاع الأخطاء لضمان عدم حدوث حالة توقف تام أو تسرب مرجعي بسبب الرفض المباشر للمهام. S7

6.4 CVE-2026-95101: الحفاظ على حالة skip بشكل منفصل للإطارات غير المعروفة

يضيف المنبع حقل skip في بنية حالة المحلل اللغوي HTTP/3 ويقوم بفصل الحالة:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

المفتاح ليس “تعطيل إطارات HTTP/3 غير المعروفة”، ولكن التأكد من أنه عبر القراءات المتعددة، يتم دائمًا إدارة عدد البايتات التي تم تخطيها وطول الحمولة النافعة DATA بواسطة حالات مستقلة. يجب أن تركز المراجعات على تقسيم المخزن المؤقت غير المعروف للإطارات والاتساق النهائي لـ client_max_body_size. S8

6.5 CVE-2026-97629: مزامنة مجموعة فتحات المفاتيح TLS الكاملة

توجد التغييرات الأولية في src/event/ngx_event_openssl.c:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

تحتوي الصورة الأصلية على ثلاث فتحات رئيسية، ولكن تم نسخ أول اثنتين فقط. بدلاً من ذلك، قم بالمزامنة بناءً على العدد الفعلي لعناصر المصفوفة للتأكد من أن مجموعة مفاتيح التصويت Worker متوافقة مع الذاكرة المشتركة. عند المراجعة، تأكد أيضًا من أن تخصيص المصفوفة والتهيئة والقفل المشترك ومنطق التدوير متسق، بدلاً من مجرد التحقق من تعديل طول memcpy مرة واحدة. S9

6.6 لماذا لا ينصح بتطبيق أجزاء التصحيح المتناثرة فقط؟

تمتد هذه التعديلات الخمسة إلى src/http وsrc/stream وsrc/http/v3 وsrc/event على التوالي، وقد تحتوي الإصدارات الأقدم على منافذ خلفية أمنية وامتدادات غير رسمية. يجب أن يشكل Backporting مصفوفة الفحص التالية:

تحقق من الكائن	ما يجب تأكيده
مصدر التصحيح	التقديم الرسمي، مطابقة الإصدار المستهدف، التصحيح الكامل والتحقق من التوقيع
مجموعة التصحيح الأصلية	لا يتعارض مع التعديلات التاريخية مثل CVE-2026-42533، ومنفذ التوزيع الخلفي، وما إلى ذلك.
مسار الكود	تمت تغطية البرنامج النصي HTTP + Stream، AIO/الخيط، HTTP/3، تذكرة OpenSSL
المترجمة متوافقة	OpenSSL، PCRE، وحدة ABI، الوحدة الديناميكية وتبعيات الارتباط متسقة
الانحدار الوظيفي	إعادة كتابة alias، السجل الديناميكي، SSI/AIO، تحميل HTTP/3، استئناف جلسة mTLS
وقت التشغيل	تعمل جميع Worker/Pods على تشغيل إصدارات جديدة تم التحقق منها، ولا توجد صور قديمة متبقية

بالنسبة للفرق التي تحتفظ بإصداراتها الخاصة، يوصى بالاحتفاظ بمعرفات التصحيح القابلة للتدقيق وإصدارات الحزمة وسجلات البناء وتقارير الانحدار لكل CVE؛ بالنسبة للتشغيل والصيانة العادية، فإن الحل الأكثر أمانًا هو تثبيت التحديثات الأمنية الكاملة الخاصة بالمورد.

7. التراجع التاريخي عن الضعف والفروع القديمة والمنتجات الأخرى

7.1 NGINX الثغرة الأساسية تستحق التأكيد المتزامن من مايو إلى سبتمبر 2026

العديد من مثيلات NGINX التي لم يتم تحديثها لفترة طويلة لا تتأثر فقط بالمشكلة الجديدة في أكتوبر. فيما يلي عقد الإصلاح التمثيلية في المستقبل القريب: S1S2

مكافحة التطرف العنيف	الإصدار الأول للإصلاح	المخاطر والشروط الرئيسية التي تتطلب التدقيق
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0، 13 مايو	rewrite التقاط التعبير العادي المجهول ومنطق الاستبدال يؤدي إلى تجاوز سعة الكومة، RCE المحتمل؛ هناك تقارير عامة عن محاولات هجوم في البرية
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1، 22 مايو	يؤدي تداخل التقاط التعبير العادي وتقدير الطول في rewrite إلى تجاوز السعة
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2، 17 يونيو	HTTP/2 تكوين محدد لـ upstream أو gRPC، تؤدي حالة رأس الطلب الكبيرة إلى تجاوز سعة المخزن المؤقت
CVE-2026-42530	Mainline 1.31.2، 17 يونيو	HTTP/3 الاستخدام بعد الاستخدام؛ النطاق الرسمي المتأثر بالعلامة 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3، 15 يوليو	يؤدي تقييم متغير التقاط map + regex إلى تجاوز سعة الكومة، وتكون التصحيحات اللاحقة مرتبطة بالانحدار مع CVE-2026-93479 في أكتوبر
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3، 15 يوليو	ngx_http_slice_module تسرب محتوى الذاكرة في ظل ظروف تحديث متغير وذاكرة التخزين المؤقت المحددة
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3، 15 يوليو	يرتبط SSI بـ UAF؛ ليس نفس سبب root مثل ثغرة العد AIO في أكتوبر
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6، 15 سبتمبر	تجاوز سعة الكومة المحدودة لمجموعة إصدار HTTP/3 + مجموعة إصدار OpenSSL المحددة، والتي تتجلى بشكل أساسي في صورة عطل/تلف محدود في الذاكرة

يجب أيضًا التحقيق في الثغرات الأمنية الأخرى مثل NGINX Core وHTTP/2 وcharset وSMTP التي تم الإعلان عنها في عام 2026 وفقًا للنشرات الأمنية الرسمية؛ يركز هذا الجدول عمدًا على الأحداث النموذجية الأكثر صلة بعمليات نشر الوكيل العكسي الحالية NGINX والتي لها آثار تتعلق بسلامة الذاكرة أو تكامل الطلب. ليست جميع التهديدات والتطرف العنيف في عام 2026. القائمة. S1

لماذا نولي اهتماما خاصا لـ CVE-2026-42945

هناك نشرات أمنية من الوكالات الحكومية تسجل أنشطة الاستغلال البرية ومعلومات كود الاستغلال العام لثغرة rewrite في مايو. لذلك، بالنسبة للمثيلات التي لم يتم تصحيحها لفترة طويلة من مايو حتى الوقت الحاضر والتي تحتوي على عمليات إعادة كتابة معقدة للتعبير العادي على الشبكة العامة، بالإضافة إلى إكمال الإصلاح، يجب أيضًا مراجعة التعطل غير الطبيعي لـ Worker وسجلات الوصول والتغييرات المشبوهة في ذلك الوقت. S23

“حدثت محاولة هجوم” لا تثبت تلقائيًا أن المهاجم قد نفذ الأوامر بشكل موثوق على كل هدف؛ عندما يتعلق الأمر بالاستجابة للحوادث، يجب التحقيق في مؤشرات التسوية وتعطل العمليات بشكل منفصل عن الدليل الحقيقي على تصعيد الامتياز أو استمراره.

معالجة 7.2 للإصدارات الأقدم ومنافذ التوزيع الخلفية

NGINX الفروع المختلفة لها دورات دعم خاصة بها وأوقات مختلفة لتقديم الثغرات الأمنية. لا يمكن طرح التصحيحات الخمس الجديدة لجميع الأشجار المصدرية المبكرة دون مراجعة.

المشهد	الإستراتيجية الموصى بها
أعلنت نسخة الإصدار عن تصحيحات أمنية كاملة	استخدام حزم البائعين وتوثيق إصدارات الحزمة الكاملة؛ تجنب الاستبدال بالثنائيات العارية غير المتوافقة
Debian 12 والإصدارات المتأثرة الأخرى التي لم يتم تغطيتها بعد بواسطة جميع التهديدات المشتركة (CVE) في هذه الدفعة	إرسال أوامر العمل الخاصة بالمخاطر، والحد من التعرض الخارجي، والتحقق من حالة المورد/ELTS؛ قم بترحيل أو استخدام سلسلة إصدار صيانة يمكن التحقق منها عند الضرورة
الفروع التاريخية التي انتهت بدعم المنبع	إعطاء الأولوية للانتقال إلى الإصدارات المدعومة؛ إذا كان النقل الخلفي على المدى القصير ضروريًا، فسيقوم المشرفون بتقييم التبعيات وتوافق التصحيح، وكتابة اختبارات كاملة.
يأتي مع شوكة NGINX (OpenResty، Tengine، بوابة مخصصة)	حدد أولاً ما إذا كان مسار التعليمات البرمجية المقابل متضمنًا، ثم استخدم بيان الأمان الخاص بمسؤول صيانة الشوكة. لا يمكن أن يكون مكافئًا بشكل مباشر للإصدار الأولي.
تؤدي تصحيحات الأمان إلى تغييرات في وظائف الأعمال	اعتماد عمليات الطرح المرحلية، وتبديل حركة المرور بين الإصدارات، وتكييف التكوين؛ ليس من المناسب استعادة النسخة غير الثابتة من الشبكة العامة دون عزلها.

7.3 معالجة منفصلة لـ njs وIngress وNGINX Core

• njs: بالإضافة إلى البرنامج الرئيسي NGINX، تحتاج أيضًا إلى التحقق من إصدار وحدة JavaScript NGINX نفسها. يعمل njs 1.0.2 على إصلاح مشكلة استنفاد الذاكرة في تحليل XML لشهر أكتوبر 2026 ومشكلة عدم تناسق التحقق من صحة XML مع سمات مرجع الكيان. بالنسبة لعمليات النشر المرتبطة بالتحقق من توقيع XML باستخدام nginx-saml، يجب عليك قراءة تعليمات njs الرسمية لسيناريوهات البرنامج الإضافي. S20
• F5 NGINX Plus / NGINX وحدة التحكم في الدخول: بالإضافة إلى ذلك، قد تحتوي كل من وحدة التحكم وGateway Fabric على نشرات أمان إضافية وإصدارات حزم مختلفة وثغرات أمنية فريدة في السياسة. ترقية طبقة واحدة لا يعني تحديث طبقة أخرى تلقائيًا. S19
• مجتمع Kubernetes ingress-nginx: أعلن مسؤولو Kubernetes بالفعل أن وحدة التحكم توقفت عن الصيانة في مارس 2026، ولا يمكن الخلط بين مستودعها ووحدة التحكم F5. يجب على الشركات المتأثرة التخطيط للترحيل السلس والتحقق من التعليقات التوضيحية للدخول والاختلافات الدلالية Gateway API بدلاً من انتظار إصدار أمان جديد. S21

8. معايير القبول ومتابعة عمليات التفتيش

يوصى باستخدام القائمة التالية كشروط قبول لتغيير أوامر العمل:

مشروع	معايير التأهيل	الأدلة التي يمكن الاحتفاظ بها
تغطية الأصول والبوابة	تم جرد كافة المثيلات الخارجية والمتصلة بشكل مباشر والتي يمكنها تجاوز CDN.	اسم المجال، LB، IP، قائمة Pod/container
مصدر الحزمة ونطاق الإصلاح	استخدم الإصدارات المؤكدة لتغطية جميع التهديدات والتطرف العنيف المعمول بها	الاستشارات الأمنية الأولية، USN/DSA، إصدار الحزمة، ملخص الصورة
خروج العملية القديمة	تم استبدال جميع حاويات master/worker/الحاويات القديمة	PID/وقت البدء، وحالة النشر المتداول، وتشغيل الصورة
تدقيق التكوين	تمت إزالة المجموعات عالية الخطورة أو تغطيتها بالتصحيحات، وتم التحقق من علاقات الميراث	ملخص منقح وسجل التدقيق لـ nginx -T
TLS/mTLS	تمرير الشهادات الموثوقة؛ يتم رفض الشهادات غير الصالحة أو المفقودة؛ استئناف الجلسة لا يتجاوز المصادقة	اختبار الترخيص السلبي/الإيجابي، نتائج اختبار TLS الخاضعة للرقابة
نص الطلب HTTP/3	تمكين المسار الثابت؛ يتصرف نص الطلب المنبع والاختناق بشكل صحيح	HTTP/3، تحميل الوكيل، اختبار انحدار حد الحجم
SSI/AIO	الوظيفة تلبي المتطلبات، Worker لا يوجد بها إحباط غير طبيعي	مراقبة انحدار الأعمال والتعطل ومعدل الأخطاء
مراقبة التشغيل والصيانة	لا يوجد استثناء واضح 5xx، SIGSEGV، يتم إنهاء العملية بشكل متكرر	مؤشرات الخدمة والسجلات قبل وبعد التغييرات
استراتيجية التراجع	إذا كان التراجع ضروريًا، فقم أولاً بالحد من التعرض والحفاظ على الحدود الأمنية	أوامر التغيير، وتدفقات الطوارئ، وخطط الحجر الصحي
دورة الحياة اللاحقة	تحديد اشتراكات النشرات الأمنية وتكرار تحديث الحاوية وخطط ترحيل الفروع	ترقية دفتر الأستاذ والشخص المسؤول وتاريخ التدقيق التالي

8.1 ما الذي يجب التركيز عليه في السجلات وحالة التشغيل؟

استكشاف الأخطاء وإصلاحها على الخوادم التي تم الكشف عنها لفترة طويلة worker process exited on signal 、 SIGSEGV ، وطفرات فشل الطلب، وتجميع الوصول غير الطبيعي إلى المصدر، ونجاح استئناف/مصادقة جلسة TLS غير المتوقع، والسلوك غير الطبيعي لجسم طلب الواجهة الخلفية. لا يمكن استخدام هذه المؤشرات إلا كأدلة تحقيق وليست أدلة كافية لإثبات مباشرة أنه تم استغلال نوع معين من مكافحة التطرف العنيف. ;إن عدم وجود السجلات ذات الصلة لا يثبت أنه لم يكن هناك هجوم.

8.2 صياغة استنتاج المخاطر النهائي الموصى به

يجب أن يستخدم تقرير القبول لبيئة الإنتاج التعبير الدقيق التالي:

تم تحديد مدخل الخدمة الخارجية NGINX ومصدر حزمة البرامج. تمت ترقية جميع المثيلات القابلة للتطبيق إلى إصدار الأمان الرسمي الأولي، أو تم إكمال المنفذ الخلفي الذي أكده بائع الإصدار؛ تم استبدال Worker القديم والحاويات القديمة. الاسم المستعار/إعادة الكتابة/الخريطة، AIO/SSI، نص طلب HTTP/3 وTLS تذكرة الجلسة/mTLS تم تدقيق التكوينات ذات الصلة واجتازت اختبارات الانحدار الوظيفية والمصادقة وتكامل الطلب. بالنسبة للمثيلات التي لم تكتمل الترقية بعد، قم بالإضافة إلى ذلك بتسجيل مناطق التعرض وإجراءات التعويض والأشخاص المسؤولين والمواعيد النهائية للإكمال.

إذا كان التصحيح الخاص بـ Debian 12 أو الإصدارات الأخرى لا يزال غير مكتمل، فليس من المناسب الحكم على نموذج القبول بأكمله بأنه “مكتمل”؛ يجب تسجيل CVE الذي لم يتم حله، وما إذا كان هناك تكوين مشغل مطابق، وحالة العزل ومسار الترقية النهائي بوضوح.

---

ملحق: المصادر والروابط المذكورة

الوصف: أرقام [Sx] الموجودة في النص تتوافق بشكل موحد مع هذا القسم. فيما يلي الأولوية لإعلانات أمان المشروع الأولية، والتزامات التعليمات البرمجية، وإعلانات إصدار الموردين، ومعلومات وكالة الأمن القومي. يتم وصف مدى خطورة نقاط الضعف المذكورة وفقًا لمعايير التصنيف الخاصة بكل مؤسسة إصدار؛ تاريخ التحقق من البيانات هو 27 أكتوبر 2026.

S1 — نشرة الأمن الرسمية NGINX Open Source

• https://nginx.org/en/security_advisories.html

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

S2 - سجل إصدار الإصدار الرسمي NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

قم بتأكيد 1.30.6 / 1.31.7 لـ 2026-10-14، و1.31.8 لـ 2026-10-21، والمراحل الهامة لإصدار الأمان من مايو إلى سبتمبر.

S3 - وكالة الأمن السيبراني في سنغافورة: F5 NGINX ثلاث نقاط ضعف خطيرة

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

وصف نتائج CVSS v4.0 9.2 وشروط التكوين المطلوبة وتوصيات التخفيف المؤقتة لـ CVE-2026-15176 وCVE-2026-93479 وCVE-2026-97205.

S4 - NHS England: F5 NGINX استشارات عالية المخاطر

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

يصف تأثير DoS / RCE المحتمل لقضايا سلامة الذاكرة، والقيود مثل إيقاف تشغيل ASLR أو تجاوزه.

S5 - التزام المصدر الرسمي: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

يتوافق مع التحقق من حالة alias وr->uri_changed في ngx_http_map_uri_to_path().

S6 - التزام المصدر الرسمي: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

يتوافق مع طول البرنامج النصي HTTP/Stream ومنطق تخصيص المخزن المؤقت المحجوز.

S7 - التزام المصدر الرسمي: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

يتوافق مع عتبة العد r->main->blocked NGX_HTTP_MAX_BLOCKED 250 والمسار الاحتياطي غير المتزامن.

S8 - التزام المصدر الرسمي: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

فصل الحالة المطابق للطول المتبقي للإطار غير المعروف HTTP/3 وطول نص الطلب DATA.

S9 - التزام المصدر الرسمي: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

يتوافق مع جميع فتحات المفاتيح أثناء مزامنة تذكرة جلسة TLS.

S10 - F5: إعلان البائع CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

قم بإدراج عوامل التشغيل مثل alias وrewrite و$request_filename وسجلات الوصول.

S11 - F5: إعلان بائع CVE-2026-93479

• https://my.f5.com/manage/s/article/K000162607

قم بإدراج خريطة التقاط التعبير المنطقي ومسار root وتسجيل شروط التقييم المتغيرة.

S12 - وثائق وحدة NGINX الرسمية TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

الوصف ssl_session_cache، ssl_session_tickets، ssl_session_ticket_key ومصادقة شهادة العميل وتعليمات أخرى.

S13 — استشارة أمنية: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

توفير الإصدار الثابت لحزمة البرامج الكاملة ونطاق التوزيع Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — استشارة أمنية: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

قم بتأكيد حزمة إصلاح الأمان 1.26.3-3+deb13u10 لـ Debian 13 / trixie، وقم بتسجيل اقتران المنفذ الخلفي لـ CVE-2026-93479.

S15 — تتبع الضعف: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

يُستخدم للتحقق من حالة إصلاح التوزيع لـ Debian 12 / bookworm وDebian 13 / trixie. قد تتغير هذه الحالة مع التحديثات الأمنية المستقبلية.

S16 — تتبع الضعف: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

تأكيد إضافي للحالة الأمنية لثغرة HTTP/3 على فروع Debian المختلفة.

S17 — استشارة أمنية: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

فهم تكميلي للعلاقة بين ثغرة انحدار أكتوبر وإصلاح CVE-2026-42533 لشهر يوليو.

S18 — وثيقة وحدة الوكيل العكسي الرسمية NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

الاستعلام عن الدلالات والقيم الافتراضية للتكوينات مثل proxy_request_buffering، client_max_body_size، alias، aio، إلخ.

S19 — NGINX Plus ملاحظات الإصدار الرسمية

• https://docs.nginx.com/nginx/releases/

قائمة Plus بفروع CR/LTS وإصداراتها وتصحيحاتها وتذكيرات توافق الترقية.

S20 — NGINX JavaScript / njs النشرة الأمنية الرسمية

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

يحتوي على njs 1.0.2 لشهر أكتوبر 2026 والتحقق من صحة XML ذي الصلة ومشكلات استنفاد الذاكرة.

S21 — Kubernetes: تعليمات التقاعد الرسمية لمجتمع ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

لاحظ أن المشروع أوقف الإصدارات الجديدة وإصلاحات الأمان في مارس 2026، ويوصى بترحيل وحدة التحكم التي تمت صيانتها أو Gateway API.

S22 — التحكم الرسمي في الخدمة NGINX وتعليمات الترقية الثنائية عبر الإنترنت

• https://nginx.org/en/docs/control.html

التمييز بين إعادة تحميل التكوين وإعادة التشغيل وأساليب ترقية الملفات القابلة للتنفيذ عبر الإنترنت لقبول تبديل العملية.

S23 - إشعار الأمن الحكومي: مايو 2026 NGINX يعيد كتابة الثغرة الأمنية

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

تقديم خلفية المخاطر التاريخية واقتراحات التحديث الأمني لـ CVE-2026-42945؛ يجب أن تستند الأحكام المتعلقة بالاستغلال غير المشروع إلى إعلان الوكالة في ذلك الوقت والأدلة الإضافية للحادث.

S24 — F5: إعلانات الموردين CVE-2026-95101 وCVE-2026-97629

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

يغطي مخاطر HTTP/3 طلب حقن الجسم والتدوير التلقائي لمفتاح التذكرة TLS على التوالي.

S25 - F5: إعلان بائع CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

الوصف SSI/AIO شروط التشغيل ومخاطر تلف الذاكرة المحتملة.

التحديث الأمني NGINX: فحوصات التكوين والترقيات والتحقق