شرکت F5 وصله‌های اضطراری برای چند آسیب‌پذیری انجینکس منتشر کرده است. سه مورد از این باگ‌ها به مهاجم بدون احراز هویت اجازه می‌دهند پروسه کاری NGINX را از کار بیندازد. البته این کار فقط با پیکربندی خاصی ممکن است. در شرایط خاص حتی اجرای کد هم ممکن است.
انجینکس در بسیاری از سرورهای وب، هاست‌ها و پروکسی‌های معکوس ایران کار می‌کند. بنابراین این خبر برای مدیران سرور و شرکت‌های میزبانی اهمیت زیادی دارد. در این مطلب توضیح می‌دهیم مشکل چیست، کدام نسخه‌ها امن‌اند و همین امروز چه باید کرد.
آسیب‌پذیری انجینکس این بار چه می‌گوید؟
طبق گزارش بلیپینگ کامپیوتر، F5 این وصله‌ها را خارج از چرخه معمول به‌روزرسانی منتشر کرده است. شناسه سه باگ اصلی CVE-2026-15176، CVE-2026-93479 و CVE-2026-97205 است.
نتیجه سوءاستفاده موفق، سرریز حافظه هیپ یا خطای use-after-free در پروسه کاری NGINX است. در نتیجه، پروسه از کار می‌افتد یا دوباره راه‌اندازی می‌شود. اما F5 هشدار داده که اگر ASLR غیرفعال باشد یا مهاجم آن را دور بزند، اجرای کد هم ممکن است.
نکته مهم این است که این باگ‌ها روی همه سرورها فعال نیستند. در واقع هر کدام به نسخه خاص و پیکربندی خاصی نیاز دارد. با این حال، چون مهاجم برای حمله به هیچ رمز عبوری نیاز ندارد، نباید ارتقا را عقب انداخت.
سه باگ اصلی و شرط فعال شدن آن‌ها
طبق گزارش سایبرسکیوریتی نیوز، F5 این سه مشاوره امنیتی را در ۱۴ اکتبر ۲۰۲۶ منتشر کرد. هر سه آسیب‌پذیری انجینکس در بخش داده یا Data Plane قرار دارند، یعنی همان بخشی که ترافیک کاربران را پردازش می‌کند.
اولین باگ، CVE-2026-97205، یک خطای use-after-free در ماژول ngx_http_core_module است. این خطا وقتی رخ می‌دهد که ورودی و خروجی ناهمگام فایل یا AIO فعال باشد. همچنین باید NGINX یک صفحه SSI با دستور include virtual را پردازش کند.
دومین باگ، CVE-2026-93479، سرریز حافظه هیپ در دستور map است. این مشکل به عبارت‌های منظم یا regex مربوط است. برای مثال، اگر دستور root یا قالب لاگ از متغیرهای capture قبل از متغیر خروجی map استفاده کند، خطر ایجاد می‌شود.
سومین باگ، CVE-2026-15176، هم سرریز هیپ در ngx_http_core_module است. این باگ زمانی فعال است که در یک بلوک location، دستور alias کنار rewrite بیاید. علاوه بر آن، باید دستور set یا return به متغیر $request_filename اشاره کند. اگر این متغیر در log_format هم باشد، همین خطر وجود دارد.
چرا F5 «بحرانی» می‌گوید و nginx.org «متوسط»؟
اینجا یک تفاوت جالب وجود دارد. طبق سایبرسکیوریتی نیوز، F5 هر سه باگ را در CVSS نسخه ۳.۱ با امتیاز ۸.۱ «بالا» ارزیابی کرده است. همچنین در CVSS نسخه ۴ امتیاز ۹.۲ و سطح «بحرانی» به آن‌ها داده است.
اما در صفحه مشاوره‌های امنیتی nginx.org شدت همین سه مورد «متوسط» ثبت شده است. دلیلش احتمالاً شرط‌های پیکربندی است. یعنی سرور پیش‌فرض معمولاً در معرض خطر نیست.
پس کدام را جدی بگیریم؟ پاسخ ساده است. اگر پیکربندی شما شامل AIO، SSI، alias یا map با regex است، باید آن را بحرانی فرض کنید. در غیر این صورت هم ارتقا را در اولین فرصت انجام دهید.
همچنین F5 تا امروز گزارشی از سوءاستفاده فعال از این باگ‌ها نداده است. با این حال، بلیپینگ کامپیوتر یادآوری می‌کند که CISA از نوامبر ۲۰۲۱ تاکنون هشت آسیب‌پذیری محصولات F5 را در فهرست سوءاستفاده‌شده‌ها قرار داده است. چهار مورد از آن‌ها در حملات باج‌افزاری هم به کار رفته‌اند.
کدام نسخه‌ها در برابر آسیب‌پذیری انجینکس امن‌اند؟
طبق جدول nginx.org، نسخه‌های 1.31.7 به بعد در شاخه mainline و 1.30.6 به بعد در شاخه stable امن هستند. دامنه نسخه‌های آسیب‌پذیر این‌گونه است:
- CVE-2026-15176: نسخه‌های 0.1.29 تا 1.31.6
- CVE-2026-97205: نسخه‌های 0.8.11 تا 1.31.6
- CVE-2026-93479: نسخه‌های 1.31.2 تا 1.31.6 و 1.30.0 تا 1.30.5
علاوه بر این سه مورد، همین نسخه‌ها دو باگ متوسط دیگر را هم رفع می‌کنند. یکی CVE-2026-95101 است که به تزریق بدنه درخواست در HTTP/3 مربوط است. دیگری CVE-2026-97629 است که به جعل نشست هنگام استفاده از TLS session tickets مربوط می‌شود.
در محصولات تجاری هم وضعیت مشابه است. طبق سایبرسکیوریتی نیوز، کاربران NGINX Plus باید به 37.0.5.1 یا 37.1.0.1 ارتقا دهند. همچنین نسخه‌های اصلاح‌شده برای NGINX Instance Manager، F5 WAF for NGINX، NGINX Gateway Fabric و NGINX Ingress Controller منتشر شده است.
راهکار موقت اگر امروز نمی‌توانید ارتقا دهید
گاهی ارتقای فوری ممکن نیست. برای مثال، شاید بسته جدید هنوز در مخزن توزیع لینوکس شما نیامده باشد. در این حالت F5 چند راهکار موقت برای کاهش خطر آسیب‌پذیری انجینکس پیشنهاد کرده است:
- برای CVE-2026-97205، یکی از دو قابلیت AIO یا SSI را غیرفعال کنید.
- برای CVE-2026-93479، به جای capture بی‌نام از capture نام‌دار استفاده کنید و آن را فقط داخل همان بلوک به کار ببرید.
- برای CVE-2026-15176، از alias داخل بلوک location و متغیر $request_filename تا حد امکان پرهیز کنید.
البته این راهکارها هزینه هم دارند. مثلاً خاموش کردن AIO ممکن است سرعت ارسال فایل‌های بزرگ و پخش ویدئو را زیر بار سنگین کم کند. بنابراین آن‌ها را فقط پل موقتی تا ارتقای کامل بدانید.
چک‌لیست فوری برای مدیران سرور
اگر مسئول سرورهای وب یا پروکسی هستید، برای مهار آسیب‌پذیری انجینکس این مراحل را به ترتیب انجام دهید:
- ابتدا با دستور nginx -v نسخه نصب‌شده را روی همه سرورها بررسی کنید.
- سپس با nginx -T کل پیکربندی فعال، همراه با فایل‌های include شده، را ببینید.
- در خروجی دنبال aio، ssi، alias، $request_filename و map با regex بگردید.
- در مرحله بعد، به 1.31.7 یا 1.30.6 یا نسخه اصلاح‌شده محصول خود ارتقا دهید.
- پیش از بارگذاری دوباره، با nginx -t درستی نحو پیکربندی را بسنجید.
- در نهایت، لاگ خطا را برای ری‌استارت‌های غیرعادی پروسه کاری پایش کنید.
اگر از وردپرس روی NGINX استفاده می‌کنید، این فرصت خوبی برای مرور کل لایه‌های امنیتی است. پیش‌تر درباره آسیب‌پذیری وردپرس 7.1.2 هم نوشته بودیم که همین منطق به‌روزرسانی سریع را دنبال می‌کند.
در نهایت، یادتان باشد که وجود نسخه آسیب‌پذیر به تنهایی به معنی آسیب‌پذیر بودن سرور نیست. اما چون تشخیص دقیق پیکربندی در سرورهای زیاد زمان‌بر است، ساده‌ترین و امن‌ترین راه همان ارتقای فوری است.
بدون دیدگاه