تحديث NGINX الأمني في أكتوبر 2026: عالج المسارات الخمسة

يعالج NGINX Open Source 1.30.6 stable و1.31.7 mainline، الصادران في 14 أكتوبر 2026، خمس ثغرات في URI rewriting وscript evaluation وأجسام طلبات HTTP/3 وTLS session tickets وasynchronous file I/O. الإجابة التشغيلية ليست ترقيع الميزة الظاهرة فقط: احصر الـbinary الحقيقي وbuild flags، وافحص effective configuration، وحدّث كل instance تستقبل حركة إلى build مصححة من upstream أوالمورد، واختبر Canary ببروتوكولات الإنتاج، ثم تحقق من كامل Fleet من خارج Load Balancer.

هذا دليل ترقيع دفاعي مبني على صفحة أمان NGINX الرسمية وأخبار الإصدار وCommunity Blog، وتم التحقق منها في 26 أكتوبر 2026. يصنف NGINX المسائل الخمس بدرجة medium. هذا التصنيف حقيقة منشورة من المورد؛ أما أولوية البيئة نفسها فهي تحليل هندسي يعتمد على التعرض للإنترنت والوحدات المفعلة والإعدادات وأثر worker crash أوrequest injection أوsession forgery. لا تدعي المصادر الرسمية المذكورة استغلالًا واسعًا في الواقع، لذلك لا يعامل هذا الدليل محاولات المسح أوالوصول النظري كاختراق مؤكد.

الخلاصة أولًا

بالنسبة إلى NGINX Open Source من upstream، حدّث stable إلى 1.30.6 أوأحدث، وmainline إلى 1.31.7 أوأحدث. صدر mainline 1.31.8 في 21 أكتوبر وهو أيضًا بعد حد الإصلاح. وإذا أضافت Linux distribution أوappliance backport دون تغيير رقم upstream الظاهر، فاعتمد security advisory وpackage revision الخاصة بالمورد بدل رفض build مصححة بسبب version string وحدها.

تحتاج الاستجابة الآمنة إلى خمس بوابات: أثبت أي Binary تخدم الطلبات؛ اربط التعرض بالميزات من rendered configuration وbuild flags؛ ابن أوثبت artifact مصححة؛ اختبر Canary بالبروتوكولات التي تقدمها الخدمة؛ وسجل دليلًا خارجيًا أن كل endpoint تستخدم artifact المقصودة.

ما الذي أصلحه إصدار 14 أكتوبر؟

يعرض الجدول نطاقات NGINX وأسماء المسائل المنشورة. العمود الأخير Checklist استكشافية للمشغل وليس إثباتًا أن الإعداد قابل للاستغلال. لا تؤجل التحديث لأن بحثًا نصيًا سريعًا لم يجد تطابقًا: قد تجعل includes وtemplates وgenerated configuration وingress controllers وإعدادات المورد effective configuration مختلفة عن الملف الذي راجعته.

احصر الـartifact التي تخدم الطلبات

ابدأ بالـprocess وimage التي تستقبل الطلبات فعلًا، لا بتعريف الحزمة في Infrastructure as Code.

nginx -v
nginx -V 2>&1
nginx -T 2>&1 > /tmp/nginx-effective.conf
sha256sum "$(command -v nginx)"

يعرض version command إصدار upstream. ويعرض capital-V معاملات compiler والوحدات. أما capital-T فيختبر ويطبع كامل الإعدادات مع includes، وهي المادة الصحيحة لمراجعة التعرض. احم هذا الناتج لأنه قد يحتوي أسماء hosts داخلية ومسارات شهادات وبيانات تشغيل حساسة.

في Containers، سجل immutable image digest مع binary digest. وفي Kubernetes، افحص كل workload وDaemonSet تنهي أوتمرر HTTP، لا Deployment اسمها nginx فقط. افحص ingress controllers وsidecars وAPI gateways وcaching tiers وbase images وmaintenance hosts. لا تصبح Fleet مصححة إلا عندما تعجز artifact القديمة عن استقبال حركة بعد rescheduling أوrollback.

تضم الأدلة المفيدة endpoint وworkload وimage digest وNGINX version وbinary digest وpackage revision وeffective-config digest ووقت الرصد. لا تستنتج حالة vendor package من nginx -v وحدها؛ سجل advisory للمورد ورقم الحزمة الدقيق الذي يثبت الـbackport.

ارسم التعرض دون اعتباره بديلًا للتحديث

راجع effective configuration بمسار للقراءة فقط:

grep -nE '(^|[[:space:]])(alias|rewrite|listen.*quic|ssl_session_ticket_key|aio|ssi)[[:space:]]' /tmp/nginx-effective.conf

في CVE-2026-15176، أعط الأولوية لـlocations التي يتفاعل فيها URI rewriting مع alias path resolution. وفي CVE-2026-93479، راجع expressions التي تحتوي variables وتصنعها templates. وفي CVE-2026-95101، حدد QUIC listeners وهل يصل HTTP/3 إلى الحافة العامة وهل تمر request bodies إلى upstream. وفي CVE-2026-97629، احصر ticket configuration وتوزيع المفاتيح وقرارات المصادقة التي تعتمد على TLS session. وفي CVE-2026-97205، ابحث عن AIO وSSI بما يشمل inherited directives وgenerated includes.

تساعد هذه المراجعة على ترتيب Rollout وتحديد نطاق التحقيق، لكنها لا تجعل Binary قديمة آمنة. وقد تتراجع configuration workarounds عند reload أوتغيير template، بينما تزيل build المصححة الخلل المعروف من مصدره.

اختر الـartifact المصححة

لا تنسخ Binary إلى Container قديمة وقت التشغيل. أعد بناء Image، وثبت digest الجديدة، وافحصها وأثبت provenance، ثم انشر عبر المسار المعتاد. بذلك يصبح Rollback وFleet reconciliation موثوقين. وعند البناء من source، تحقق من التنزيل والتوقيع، وأعد إنتاج الوحدات وflags المطلوبة، وشغل اختبارات الوظيفة والأمان. قد تكون Binary حذفت module متوقعة آمنة من CVE لكنها تكسر الإنتاج.

اختبر Canary

قبل الحركة، شغل فحوص syntax والإعداد:

nginx -t
nginx -T > /secure-review/nginx-effective-after.conf
nginx -V 2>&1

قارن الإعداد قبل التحديث وبعده دلاليًا. قد تغير package upgrade defaults أوmodule availability أوTLS behavior حتى لو لم تتغير الملفات المحلية.

وجه جزءًا محدودًا من الحركة إلى artifact المصححة. اختبر طلبات HTTP/1.1 وHTTP/2 والuploads والredirects والملفات عبر alias؛ وتفاوض HTTP/3 وQUIC مع request bodies عند التفعيل؛ وTLS full وresumed sessions؛ وSSI وstatic-file reads؛ وupstream timeouts والheaders وbody streaming؛ وgraceful reload وworker drain وrollback إلى artifact مصححة أخرى.

راقب customer errors وupstream resets وخروج workers وفشل reload وlatency وhandshake failures والحركة حسب البروتوكول. نجاح nginx -t يثبت syntax، ولا يثبت صحة routing أوTLS resumption أوHTTP/3.

انشر دون ترك ذيل ضعيف

في Virtual Machines، استبدل الحزم حسب failure domains صغيرة وتحقق من running binary. وفي Containers، انشر digest مثبتة وامنع ReplicaSets القديمة من الحركة. وفي node-local proxies، طابق كل Node. وفي autoscaling groups، حدّث launch image قبل إنهاء آخر instance قديمة؛ وإلا قد يعيد Scaling إنشاء build ضعيفة.

لا يكتمل النشر عندما تصبح Pods الجديدة Ready. يكتمل عندما تختفي digest القديمة من templates القابلة للجدولة وworkloads العاملة وstandby pools وrollback manifests.

تحقق من خارج الحافة

يجب أن يثبت external verification السلوك وملكية artifact دون نشر diagnostic endpoint عامة. اربط synthetic request ID بسجلات load balancer وNGINX، ثم اربط instance التي خدمت الطلب بـbinary أوimage digest المسجلة.

اختبر كل بروتوكول وhostname معلنة. عند تفعيل HTTP/3، تحقق أن الاستجابة تفاوضت عليه فعلًا ولم تسقط بصمت. مرر body غير مؤذية عبر proxy path نفسها المستخدمة في uploads. ولـTLS resumption، قارن full handshake بـresumed session وتحقق من سياسة المصادقة المقصودة. أبق fleet attestations داخلية؛ إعلان patch version الدقيقة يزيد reconnaissance وهو أضعف من inventory evidence موقعة.

التحقيق: المحاولة ليست اختراقًا

يستحق النظام الضعيف والمعرض مراجعة logs وintegrity، لكن لا تسم scan عادية استغلالًا ناجحًا. احتفظ بسجلات load balancer وWAF وNGINX؛ وworker crashes وcore dumps وrestart history؛ وconfiguration وimage digests؛ وسجلات توزيع ticket keys؛ وupstream logs لاختلافات body؛ وأحداث deployment وscaling وrollback.

Crash قريب من crafted request دليل للتحقيق، لا إثبات تلقائي لـcode execution. ولا تثبت upstream body غير عادية وحدها HTTP/3 injection. اربط request ID والبروتوكول وedge instance ورصد upstream وprocess telemetry. وإذا ظهرت compromise indicators، دوّر الأسرار، واستبدل instances من Images موثوقة، وحدد downstream access واتبع incident-response plan. يمنع الترقيع المسارات المعروفة؛ لكنه لا يمحو الأدلة ولا يعكس اختراقًا سابقًا.

أفضل الممارسات

• حدّث إلى إصدار ثابت ومدعوم حتى إن بدت الميزة المعنية معطلة.
• عامل rendered configuration وlive build كدليل لا repository intent.
• ثبت Container images بالـdigest واحتفظ بـSBOM أوprovenance.
• اختبر HTTP/3 وTLS resumption صراحة عند تقديمهما.
• اجعل rollback artifacts مصححة وطابق standby instances.
• افصل حقائق المورد عن تحليل المخاطر المحلي واستنتاج الحادث.

Anti-patterns

• فحص نسخة NGINX على Laptop الإداري فقط.
• البحث في ملف إعداد واحد مع تجاهل includes وgenerated config.
• اعتبار WAF rule أوتعطيل ميزة إصلاحًا دائمًا.
• تعديل Container عاملة بدل نشر immutable image.
• إعلان النجاح عندما تصبح أول Canary Ready.
• افتراض أن scan تثبت الاختراق أوأن غياب crash يثبت الأمان.
• رفض vendor backport لأن upstream label لم تتغير.

خلاصة التنفيذ

1. جمّد Inventory للـendpoints وworkloads.
2. سجل version وflags وeffective configuration وartifact digests.
3. اربط عائلات الميزات الخمس ورتب الحواف المعرضة.
4. اختر NGINX 1.30.6+ أو1.31.7+ أوvendor-confirmed fixed build.
5. ابن replacement ثابتة مع attestation.
6. شغل اختبارات syntax والبروتوكول وTLS والتطبيق.
7. اختبر Canary وراقب ثم توسع حسب failure domain.
8. احذف artifact القديمة من workloads وtemplates ومسارات rollback.
9. تحقق من كل public endpoint وطابق Fleet.
10. راجع الأدلة دون خلط المحاولة بالاختراق المؤكد.

اقرأ أيضًا: تحديث Apache Tomcat الأمني في أكتوبر 2026، وتحديث Node.js الأمني في أكتوبر 2026، وتطبيق Default Deny في Kubernetes، ومركز Cloud وDevOps وKubernetes.

المراجع الأساسية

• NGINX security advisories
• NGINX news: 1.30.6 stable and 1.31.7 mainline
• NGINX Community Blog: NGINX 1.31.7
• NGINX command-line parameters
• NGINX controlling processes
• NGINX HTTP/3 module
• Wikimedia Commons — Racks Amravati Data Center
• Creative Commons Attribution-ShareAlike 4.0

إعداد: Noor Yasser