آسیب‌پذیری‌های 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 آزاد کردن اینها خطوط پایه شاخه جداگانه هستند. تعداد آنها را در بین شعب مقایسه نکنید. S1 S2
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 هنوز تحت تأثیر قرار دارد. هر CVE را بررسی کنید. توصیه 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 چرخش کلید بلیط جلسه. وجود یک دستورالعمل به تنهایی قابلیت بهره برداری را ایجاد نمی کند. مسیر درخواست و دامنه پیکربندی را ارزیابی کنید. S1 S3 S4
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 ، محدودیت های نرخ و تغییرات پیکربندی فقط برخی شرایط را پوشش می دهند و نمی توانند جایگزین وصله های رسمی شوند. S3 S4 S8 S12

1. بررسی اجمالی آسیب پذیری و قضاوت ریسک

NGINX 1.30.6 (Stable) و 1.31.7 (Mainline) را در 14 اکتبر 2026 منتشر کرد و پنج مشکل امنیتی را برطرف کرد. سه مورد شامل سرریز پشته یا استفاده بدون استفاده و دریافت امتیاز F5 CVSS v4.0 از 9.2 / بحرانی است. دو مورد دیگر بر یکپارچگی درخواست HTTP/3 و تأیید اعتبار گواهی مشتری TLS تأثیر می‌گذارند. S1S2S3

سیستم های رتبه بندی را متمایز کنید: nginx.org هر پنج مشکل را به عنوان medium فهرست می کند، در حالی که F5 CVSS v4.0 و برخی آژانس های امنیت ملی این سه مشکل حافظه را به عنوان بحرانی طبقه بندی می کنند. این بدان معنا نیست که هر پنج مورد اجازه اجرای بدون قید و شرط کد از راه دور را می دهند. پیکربندی، دسترسی به ترافیک و شرایط خارج از کنترل مهاجم مهم است. خرابی حافظه و RCE قابل اعتماد سطوح مختلف شواهد هستند. S1S3S4

CVE	مسائل فنی و شرایط معمولی ماشه	تاثیر اصلی	ارزیابی و دفع
CVE-2026-15176	نقشه برداری مسیر alias + تغییر rewrite URI + ارزیابی $request_filename	سرریز بافر هیپ، خرابی Worker؛ بالقوه RCE تحت شرایط خاص	F5 CVSS v4.0 9.2; عیب یابی را در اولویت قرار دهید
CVE-2026-93479	ارزیابی اسکریپت HTTP/Stream، به ویژه ضبط regex 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 / هواپیمای مدیریتی با استفاده از گواهی مشتری به عنوان تنها یا اصلی احراز هویت ورودی	Session Ticket و پیکربندی حافظه پنهان مشترک CVE-2026-97629	P0: فوراً مرز احراز هویت را تأیید کنید و به‌روزرسانی کنید
ارائه بارگذاری خارجی HTTP/3، رابط تغییر وضعیت، کلاس تراکنش API	CVE-2026-95101، به خصوص بدنه درخواست به باطن پروکسی شده است	P0/P1: بر اساس اهمیت کسب و کار ترتیب دهید
SSI صفحه پویا یا فایل ناهمزمان I/O	CVE-2026-97205	P1: شرایط ترکیب را تأیید کنید و در اسرع وقت تعمیر کنید
فقط صفحات ثابت + پراکسی معکوس ساده HTTP/1.1/2	پیکربندی و نسخه هنوز باید بررسی شوند، اما برخی از شرایط CVE ممکن است وجود نداشته باشد	P1: در پنجره ارتقاء امنیت اضطراری گنجانده شده است
از انجمن بازنشسته Kubernetes ingress-nginx استفاده کنید	این پروژه حفظ امنیت را متوقف می کند و خطرات به این پنج CVE محدود نمی شود	یک برنامه مهاجرت کنترلر جداگانه تهیه کنید

P0/P1 پیشنهادات دفع عملیات و نگهداری است که در این مقاله برای قرار گرفتن در معرض شبکه عمومی و حساسیت صدور گواهینامه ارائه شده است. این یک طبقه بندی رسمی CVSS نیست، و همچنین نباید جایگزین دارایی داخلی شرکت و ارزیابی ریسک تغییر کند.

1.2 مرز ضربه و مجوزهای حمله

آسیب‌پذیری‌های اصلی در این دسته عمدتاً در صفحه داده NGINX قرار دارند: نقطه ورود حمله اتصال و درخواست مشتری است و تأثیر واقعی معمولاً در فرآیند Worker رخ می‌دهد. اگر شرایط قابل بهره برداری برای تخریب حافظه برآورده شود، مجوز اجرای کد عموماً توسط کاربر در حال اجرا، محدودیت های کانتینر، قابلیت لینوکس، نصب و مجوزهای شبکه 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 بالقوه وجود دارد. هسته اصلی وصله upstream این است که از تکمیل نگاشت مسیر URI بازنویسی شده در زمینه alias که دیگر معتبر نیست، به جای گسترش یک بافر خاص، خودداری کنیم. S5S10

2.3 CVE-2026-93479: عدم تطابق بین “فضای رزرو شده” و طول متغیر واقعی در ارزیابی اسکریپت

ماژول‌های HTTP و Stream NGINX دارای ارزیاب‌های اسکریپت هستند که رشته‌های تحت اللفظی و مقادیر متغیر را به رشته نتیجه متصل می‌کنند. مثال‌های کاربردی شامل مسیرهای root سند HTTP، مسیرهای ورود به سیستم دسترسی و عبارات متغیر در Stream است.

تنظیمات خاصی از map + عبارات منظم اجازه می دهد تا مقادیر گرفته شده توسط عبارات دیگر قبل از ارزیابی متغیر نتیجه map خوانده شوند. در ترکیب با روش اجرای اسکریپت با طول رزرو شده، پیاده‌سازی قدیمی فضای رزرو شده len را از قبل در ذخیره‌کننده طول ارزیابی‌شده شمارش می‌کند، به طوری که محاسبات نشانگر نوشتن بعدی دیگر با مرز بافر سازگار نیست. در یک دنباله ارزیابی متغیر خاص، نوشتن رشته های بعدی ممکن است ناحیه رزرو شده را بازنویسی کند و باعث سرریز پشته شود. S6

عناصر مشارکتی	چرا ارزش توجه دارد
regex در map	ارزیابی متغیر ضبط ممکن است چرخه زندگی مستقل و رفتار ذخیره سازی داشته باشد
کپچرهای ناشناس مانند $1، $2 و غیره.	به راحتی توسط سایر عبارات یا عبارات معمولی بازنویسی می شود و ردیابی مالکیت را دشوار می کند
متغیرها در root	اجرای اسکریپت و رزرو بافر هنگام راه اندازی مسیر ساختن
log_format/مسیر ورود به سیستم پویا	همین نوع ارزیابی ممکن است بعداً در درخواست انجام شود
عبارات اسکریپت در stream	اصلاح upstream ngx_stream_script_run() را نیز اصلاح می کند. شما نمی توانید فقط ماژول HTTP را بررسی کنید.

رابطه رگرسیونی مهم: کد مربوط به این آسیب پذیری مربوط به تغییرات قبلی است که CVE-2026-42533 را رفع کرده است. DSA رسمی برای Debian 13 به وضوح بیان می کند که کد آسیب دیده از طریق یک بکپورت امنیتی قبلی به بسته trixie وارد شده است. بنابراین، «وصله آسیب‌پذیری ژوئیه map نصب شده است» به این معنی نیست که CVE-2026-93479 اکتبر تحت پوشش قرار گرفته است. زنجیره تعمیر کامل امنیتی باید بررسی شود. S6S14S17

خطر احتمالی RCE در اینجا مربوط به محیط حفاظت از حافظه است و نباید ادعا کرد که map regex به تنهایی می تواند توسط مهاجمان ناشناس مورد سوء استفاده قرار گیرد. S11

2.4 CVE-2026-97205: AIO تعداد عملیات ناتمام بسته بندی باعث استفاده پس از رایگان می شود

این آسیب‌پذیری به سادگی «SSI را روشن کنید و UAF را دریافت خواهید کرد» نیست. کلید در تعداد مراجع عملیات ناهمزمان است که توسط درخواست اصلی نگهداری می شود.

NGINX از r->main->blocked برای ردیابی پردازش ناهمزمان که هنوز تکمیل نشده است استفاده کنید، در اجرای قدیمی تعداد آن 8 بیت بود. برخی از مسیرها قبل از افزایش تعداد، بررسی حد بالایی را انجام ندادند. هنگامی که همان درخواست اصلی 256 عملیات معوق را جمع آوری می کند، ممکن است شمارش از 255 به 0 برسد. فرآیندهای بعدی به اشتباه معتقدند که هیچ عملیات ناهمزمانی وجود ندارد که مانع از انتشار درخواست شود، در نتیجه مخزن حافظه درخواستی که هنوز توسط کار به آن ارجاع داده می شود، آزاد می شود. S7

فرآیند شکست را می توان به موارد زیر تقسیم کرد:

1. با فعال بودن مسیر I/O/thread ناهمزمان، صفحه 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 Session Ticket را از طریق حافظه پنهان مشترک تولید و بچرخاند، و به چندین Worker اجازه می‌دهد تا یک دسته از بلیط‌ها را پردازش کند.

منطق همگام سازی مربوطه، 3 اسلات کلید را برای هر Worker اختصاص می دهد، و فراخوان رمزگشایی نیز از این شکاف ها عبور می کند. اما پیاده سازی قدیمی هر بار فقط 2 اسلات کلید را از حافظه مشترک کپی می کند که در نتیجه نام کلید، کلید 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 گزارش‌هایی از فعالیت‌های بهره‌برداری در طبیعت دارد. نباید مستقیماً این واقعیت تاریخی را استنتاج کرد به این معنی که هر پنج CVE در ماه اکتبر با موفقیت در مقیاس بزرگ مورد بهره برداری قرار گرفته اند. 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 دامنه تاثیر بالادست پنج CVE

محدوده‌های زیر بر اساس متن اصلی بولتن امنیتی nginx.org فهرست شده‌اند و باید در ارتباط با «شاخه در حال اجرا فعلی» و «مسیر پیکربندی واقعی» درک شوند:

CVE	برچسب‌های بالادستی نسخه‌ها را تحت تأثیر قرار دادند	نسخه ثابت با برچسب رسمی
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) این پنج CVE را پوشش می دهد و بسته ثابت nginx را برای Debian 13 / trixie به صورت زیر شناسایی می کند:

1.26.3-3+deb13u10

با این حال، تا زمان تأیید این گزارش، 1.22.1-9+deb12u10 برای Debian 12 / bookworm همچنان توسط ردیاب امنیتی Debian به عنوان آسیب‌پذیر علامت‌گذاری شده است. بنابراین:

• Debian 13 فقط به روز رسانی کنید و طبق DSA-6575-1 بپذیرید.
• Debian 12 باید اصلاحات امنیتی ارائه شده توسط ردیاب امنیتی فعلی یا فروشنده ELTS را یک به یک بررسی کند. قبل از تایید رفع مشکل در اعلامیه، اعلام نکنید که هر پنج مورد بر اساس موفقیت apt upgrade رفع شده اند.
• بسته منبع Debian ممکن است دارای یک مجموعه وصله مستقل از شماره نسخه nginx.org باشد. برای ساخت‌های سفارشی، باید مجموعه اصلاح بسته کد منبع کامل را بررسی کنید، و نمی‌توانید فقط یک commit بالادستی را کپی کنید و آن را کامل در نظر بگیرید.

تمایز فوق بر اساس سوابق ردیابی DSA و CVE است. S14S15S16

3.5 NGINX Plus، njs و کنترل کننده ورودی

محصولات / اجزاء	نکات کلیدی انتخاب و تأیید امنیت
NGINX Plus (نسخه تجاری)	لطفاً به اطلاعیه و دستورالعمل ارتقاء شعبه پلاس مربوط به F5 مراجعه کنید. آخرین CR در زمان تأیید PLS.37.2.0.1 است و ساخت امنیتی LTS PLS.37.0.7.1 است. نسخه پلاس و بکپورت همراه آن را نمی توان مستقیماً با آستانه 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 / Fabric Gateway	هسته NGINX یک زنجیره توزیع نرم افزار مرتبط اما مستقل است. آسیب پذیری های مربوطه را با کنترلرها، تصاویر و یادداشت های انتشار مربوطه برطرف کنید. شما نمی توانید فقط یک باینری NGINX را در Pod جایگزین کنید.
انجمن Kubernetes kubernetes/ingress-nginx	این پروژه در مارس 2026 از رده خارج شد و دیگر تعمیر و نگهداری امنیتی جدیدی را ارائه نخواهد کرد. شما باید به جای اشتباه گرفتن شماره انتشار آن با کنترلر ورودی F5 NGINX به یک کنترلر نگهداری شده یا Gateway API برنامه ریزی کنید. S21

3.6 در واقع کدام پچ را باید انتخاب کنید؟

فرم استقرار	شیوه های توصیه شده	اثبات تعمیر
بسته رسمی DEB/RPM nginx.org	به نسخه ثابت شاخه بالادست ارتقا دهید	nginx -v/-V، منبع بسته، اعلامیه امنیتی رسمی
مخزن رسمی Ubuntu/Debian	بسته های امنیتی فروشنده را نصب کنید	نسخه کامل بسته + فروشنده USN/DSA + وضعیت CVE
RHEL/Alma/Rocky/SUSE/توزیعات دیگر	با توجه به بولتن های امنیتی توزیع خاص و نسخه های بسته ارتقا دهید	CSAF/اعلامیه فروشنده مربوطه، نسخه Ubuntu/Debian قابل اعمال نیست
تصاویر کانتینر رسمی یا سفارشی	تصویر تعمیر تایید شده را دوباره بسازید یا بکشید و آن را به صورت چرخشی جایگزین کنید	خلاصه تصویر، ساخت SBOM، اجرای شناسه تصویر غلاف/کانتینر
NGINX، OpenResty، Tengine خودکامپایل شده یا نسخه های وصله شده با ماژول های شخص ثالث	استفاده از نسخه امنیتی کامل نگهدارنده را در اولویت قرار دهید. در صورت لزوم، پچ‌پورت‌های بازبینی شده را برای درخت منبع هدف انجام دهید	پنج رفع آسیب‌پذیری، سازگاری ABI/ماژول، واحد و رگرسیون تجاری

OpenResty و Tengine سیستم های انتشار متفاوتی هستند. این جدول فقط روش تأیید را توضیح می دهد. به این معنی نیست که همه نسخه‌های آن همزمان با استاندارد NGINX تحت تأثیر قرار می‌گیرند، و همچنین نمی‌توان وصله کد بالادستی را بدون قید و شرط اعمال کرد.

4. فرآیند تعمیر رسمی

4.1 موجودی نمونه های واقعی دریافت ترافیک خارجی

حداقل برای هر ورودی جمع آوری کنید:

• نام دامنه، توازن بار/CDN/لینک پروکسی لبه، روش قرار گرفتن در معرض سایت مبدا و پروتکل شبکه استفاده شده است.
• محصولات NGINX (Open Source، Plus، Ingress، و غیره)، نسخه کامل، منبع مخزن بسته، خلاصه تصویر.
• nginx -V ماژول های ساختمان و پارامترهای کامپایل را نمایش می دهد. آیا ماژول‌های دینامیک njs، Lua، OpenResty و شخص ثالث وجود دارد.
• اجرای واقعی master/worker PID، واحد سرویس/کانتینر/پاد، Replica و Worker Node.
• پیکربندی های موثر واقعی http/stream، server، location، include.
• فعال کردن HTTP/3، mTLS، SSI/AIO، مسیر گزارش پویا، پیچیده map و ضبط regex.

فقط /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

این فقط مکان یاب مسیر نامزد است، نه یک ابزار تعیین خودکار CVE قابل اعتماد:

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 تغییر دهد.
• هنگامی که URI بازنویسی شده است اما تطبیق موقعیت صحیح هنوز تکمیل نشده است، از استفاده از $request_filename خودداری کنید.
• منابع متغیر غیرمستقیم را در 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 Session Ticket را خاموش کند و در نتیجه مسیر جعل بلیط که در این آسیب پذیری توضیح داده شده است را حذف کند. با این حال، ممکن است بر عملکرد از سرگیری جلسه تأثیر بگذارد. شما نمی توانید فقط تأیید گواهی مشتری 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/Dynamic استفاده نمی کند”	این نقص در مسیر هسته یا تجزیه پروتکل NGINX رخ می دهد و به اجرای PHP متکی نیست.
”باز کردن WAF/Cloudflare کافی است”	نمی‌توان ثابت کرد که WAF تمام نقص‌های حافظه وابسته به پیکربندی NGINX یا نقص‌های از سرگیری TLS را مسدود می‌کند.
”از قبل ASLR باز شده است”	فقط استفاده از کاهش دشواری؛ DoS با تزریق درخواست هنوز امکان پذیر است
”HTTP/3 در معرض شبکه عمومی نیست، بنابراین اصلا نیازی به ارتقا نیست”	چهار CVE دیگر هنوز نیاز به ارزیابی مستقل دارند. و ممکن است ارتباط مستقیمی با ریشه های پنهان وجود داشته باشد
”آسیب‌پذیری ژوئیه map رفع شد”	اکتبر CVE-2026-93479 شامل مسائل مربوط به رگرسیون ارزیابی اسکریپت بعدی است
”غیرفعال کردن کش همه مشکلات را حل می کند”	فقط برخی از حافظه پنهان TLS یا سناریوهای AIO را تحت تأثیر قرار می دهد و نام مستعار، اسکریپت، HTTP/3 را پوشش نمی دهد

6. ایده های پیاده سازی پچ رسمی و نکات بررسی

این بخش به دنبال رفع اصلاحات بالادستی NGINX در اکتبر 2026 است. قطعه‌ها تغییرات نماینده را برای بررسی وصله نشان می‌دهند. آنها اصلاحات کامل و مستقل نیستند. برای ساخت‌های سفارشی، commit‌های کامل، کدهای اطراف و تست‌ها را مرور کنید و نسخه‌ای با پشتیبانی کامل را ترجیح دهید. S5S6S7S8S9

6.1 CVE-2026-15176: URI برای گنجاندن شرایط رد نقشه مسیر alias بازنویسی شده است

commit بالادستی 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: تمایز صحیح بین طول داده خروجی و طول رزرو شده

commit بالادست 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 بیتی تنظیم کنید

Upstream اضافه شده در 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/thread، HTTP/3، OpenSSL بلیط همه پوشش داده شده است
سازگار کامپایل شده است	OpenSSL، PCRE، ماژول ABI، ماژول پویا و وابستگی های پیوند سازگار هستند
رگرسیون عملکردی	بازنویسی alias، گزارش پویا، SSI/AIO، آپلود HTTP/3، از سرگیری جلسه mTLS
زمان اجرا	همه Worker/Pods بیلدهای تایید شده جدید را اجرا می کنند، هیچ تصویر قدیمی باقی نمی ماند

برای تیم‌هایی که نسخه‌های خود را حفظ می‌کنند، توصیه می‌شود شناسه‌های پچ قابل بازرسی، نسخه‌های بسته، گزارش‌های ساخت و گزارش‌های رگرسیون را برای هر CVE نگه دارند. برای عملیات عادی و نگهداری، ایمن ترین راه حل نصب به روز رسانی های امنیتی کامل فروشنده است.

7. عقب نشینی آسیب پذیری های تاریخی، شاخه های قدیمی و سایر محصولات

آسیب‌پذیری هسته 7.1 NGINX که ارزش تأیید همزمان از مه تا سپتامبر 2026 را دارد.

بسیاری از نمونه‌های NGINX که برای مدت طولانی به‌روزرسانی نشده‌اند، نه تنها تحت تأثیر نسخه جدید در ماه اکتبر قرار می‌گیرند. گره های تعمیر نماینده در آینده نزدیک به شرح زیر هستند: S1S2

CVE	اولین نسخه تعمیر	خطرات و شرایط کلیدی که نیاز به حسابرسی دارند
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0، 13 مه	rewrite منطق ضبط و جایگزینی ناشناس regex باعث سرریز پشته، پتانسیل RCE می شود. گزارش های عمومی از تلاش برای حمله در طبیعت وجود دارد
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1، 22 مه	همپوشانی گرفتن regex و تخمین طول در rewrite منجر به سرریز می شود
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2، 17 ژوئن	HTTP/2 پیکربندی خاص برای بالادست یا 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 دارند و پیامدهای یکپارچگی درخواست یا ایمنی حافظه دارند. همه CVE های سال 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، باید نسخه خود ماژول جاوا اسکریپت NGINX را نیز بررسی کنید. njs 1.0.2 یک مشکل تحلیل XML در اکتبر 2026 و ناسازگاری اعتبار سنجی XML با ویژگی های مرجع موجودیت را برطرف می کند. برای استقرارهای مرتبط با تأیید امضای XML با استفاده از nginx-saml، باید دستورالعمل‌های رسمی njs را برای سناریوهای افزونه بخوانید. S20
• F5 NGINX Plus / NGINX Ingress Controller: به علاوه، کنترلر و Gateway Fabric ممکن است هر کدام دارای بولتن های امنیتی اضافی، نسخه های بسته بندی مختلف و آسیب پذیری های خط مشی منحصر به فرد باشند. ارتقاء یک لایه به معنای به روز رسانی خودکار لایه دیگر نیست. S19
• انجمن Kubernetes ingress-nginx: مقامات Kubernetes قبلاً اعلام کرده اند که کنترلر در مارس 2026 تعمیر و نگهداری را متوقف کرده است و انبار آن را نمی توان با کنترلر F5 اشتباه گرفت. کسب‌وکارهای تحت تأثیر باید به‌جای منتظر ماندن برای نسخه امنیتی جدید، مهاجرت روان را برنامه‌ریزی کنند و حاشیه‌نویسی‌های Ingress و تفاوت‌های معنایی Gateway API را تأیید کنند. S21

8. معیارهای پذیرش و بازرسی های بعدی

پیشنهاد می‌شود فهرست زیر به‌عنوان شرایط پذیرش تغییر سفارش‌های کاری استفاده شود:

پروژه	استانداردهای صلاحیت	شواهدی که می توان آنها را حفظ کرد
پوشش دارایی و پورتال	تمام نمونه های خارجی و متصل مستقیم که می توانند CDN را دور بزنند موجودی شده اند.	نام دامنه، LB، IP، فهرست پاد/کانتینر
منبع بسته و محدوده تعمیر	از نسخه های تایید شده برای پوشش همه CVE های قابل اجرا استفاده کنید	مشاوره امنیتی بالادست، 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 از سرگیری جلسه/رفتار احراز هویت بدنه موفقیت‌آمیز و غیرعادی. این شاخص ها فقط می توانند به عنوان سرنخ های تحقیق مورد استفاده قرار گیرند و شواهد کافی برای اثبات مستقیم اینکه یک CVE خاص مورد سوء استفاده قرار گرفته است نیستند. فقدان گزارش های مربوطه ثابت نمی کند که حمله ای صورت نگرفته است.

8.2 عبارت نتیجه گیری ریسک نهایی توصیه شده است

گزارش پذیرش برای محیط تولید باید از عبارت دقیق زیر استفاده کند:

ورودی سرویس خارجی NGINX و منبع بسته نرم افزاری شناسایی شده است. همه نمونه های قابل اجرا به نسخه امنیتی رسمی بالادستی ارتقا یافته اند یا بکپورت تایید شده توسط فروشنده انتشار تکمیل شده است. Worker قدیمی و ظروف قدیمی جایگزین شده اند. نام مستعار/بازنویسی/نقشه، AIO/SSI، بدنه درخواست HTTP/3 و TLS Session Ticket/mTLS مورد بررسی قرار گرفته و از صحت عملکرد و یکپارچگی درخواست مجدد عبور کرده است. برای نمونه‌هایی که هنوز ارتقا را تکمیل نکرده‌اند، به‌علاوه مناطق در معرض، اقدامات جبرانی، افراد مسئول و مهلت‌های تکمیل را ثبت کنید.

اگر وصله برای Debian 12 یا سایر نسخه‌ها هنوز ناقص است، قضاوت در مورد کل فرم پذیرش به عنوان “تکمیل” مناسب نیست. CVE حل نشده، اینکه آیا یک پیکربندی ماشه مربوطه وجود دارد، وضعیت جداسازی و مسیر ارتقای نهایی باید به وضوح ثبت شود.

---

پیوست: منابع و پیوندهای ذکر شده

توضیحات: اعداد [Sx] در متن به طور یکسان با این بخش مطابقت دارند. موارد زیر به اطلاعیه های امنیتی پروژه بالادستی، تعهدات کد، اعلامیه های انتشار تامین کننده و اطلاعات آژانس امنیت ملی اولویت می دهد. شدت آسیب‌پذیری‌های نقل‌شده با توجه به معیارهای رتبه‌بندی هر سازمان صادرکننده توصیف می‌شود. تاریخ تأیید داده ها 27 اکتبر 2026 است.

S1 — بولتن امنیتی رسمی NGINX Open Source

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

شامل نسخه های تحت تاثیر بالادست، شاخه های ثابت و سطوح شدت رسمی پنج CVE اکتبر است و همچنین آسیب پذیری های تاریخی را تا سال 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 انگلستان: 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

ضبط regex نقشه، مسیر root، و شرایط ارزیابی متغیر log را فهرست کنید.

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 تأیید کنید و ارتباط backport را برای 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/

شاخه‌ها، نسخه‌ها، وصله‌ها و یادآوری‌های سازگاری ارتقاء CR/LTS را فهرست کنید.

S20 — NGINX جاوا اسکریپت / njs بولتن رسمی امنیتی

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

شامل اکتبر 2026 njs 1.0.2 و اعتبار سنجی 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 - اطلاعیه امنیتی دولتی: آسیب‌پذیری بازنویسی NGINX مه 2026

• 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 Ticket را پوشش می دهد.

S25 — F5: CVE-2026-97205 اعلامیه فروشنده

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

توضیحات SSI/AIO شرایط محرک و خطرات احتمالی تخریب حافظه.

به روز رسانی امنیتی NGINX: بررسی پیکربندی، ارتقاء و تأیید