گزارش اثبات آسیب‌پذیری CVE-2026-42945

اطلاعات آسیب‌پذیری

عنوان: سرریز بافرheap در ماژول ngx_http_rewrite_module NGINX منجر به اجرای کد از راه دور

شناسه: CVE-2026-42945

وضعیت مشاوره: Advisory / Patch Available / Active Exploitation in Wild

امتیاز:  CVSS: 9.2 (Critical)

محصول: NGINX Open Source و NGINX Plus (F5)

محصول / نسخه‌های آسیب‌پذیر

در نسخه‌های زیر:

• NGINX Open Source نسخه‌های 0.6.27 تا 1.30.0
• NGINX Plus نسخه‌های R32 تا R36
• NGINX Instance Manager نسخه‌های 2.16.0 تا 2.21.1
• F5 WAF for NGINX نسخه‌های 5.9.0 تا 5.12.1
• NGINX App Protect WAF نسخه‌های 4.9.0 تا 4.16.0 و 5.1.0 تا 5.8.0
• NGINX Gateway Fabric نسخه‌های 1.3.0 تا 1.6.2 و 2.0.0 تا 2.5.1
• NGINX Ingress Controllerنسخه‌های 3.5.0 تا 3.7.2, 4.0.0 تا 4.0.1, 5.0.0 تا 5.4.1

محیط‌های درگیر

• کلیه سازمان‌هایی که از NGINX به عنوان وب‌سرور، پراکسی معکوس، API Gateway یا Ingress Controller استفاده می‌کنند
• سرورهای میزبان‌شده روی پورت‌های 80 و 443 (پورت‌های پیش‌فرض HTTP/HTTPS) که در معرض اینترنت قرار دارند
• محیط‌های ابری، کانتینرهای Kubernetes با NGINX Ingress
• سرورهای مجازی که NGINX روی آن‌ها اجرا می‌شود

کامپوننت‌های آسیب‌پذیر

• ماژول ngx_http_rewrite_module، مسئول پردازش دستورات rewrite، if و set
• تابع ngx_http_script_start_args_code، تنظیم پرچم سراسری is_args در ساختار ngx_http_request_t
• تابع ngx_http_script_complex_value_code، ایجاد زیرموتور جدید با مقدار is_args = 0
• توابع ngx_http_script_copy_capture_len_code و ngx_http_script_copy_capture_code، اعمال ناهماهنگ escaping بین دو مرحله محاسبه طول و کپی داده

ریشه مشکل (Root Cause Analysis)

ریشه اصلی این آسیب‌پذیری به یک عدم تطابق حالت (State Mismatch) در موتور اسکریپت ngx_http_rewrite_module  ماژول NGINX بازمی‌گردد.

موتور اسکریپت NGINX برای پردازش دستورات rewrite و set از یک پردازش دو مرحله‌ای استفاده می‌کند:

مرحله اول محاسبه طول بافر مورد نیاز، و مرحله دوم کپی کردن داده‌ها در بافر تخصیص‌یافته روی heap

نقص اول به نحوه مدیریت یک پرچم سراسری به نام is_args در ساختار ngx_http_request_t برمی‌گردد.

وقتی یک دستور rewrite با رشته جایگزین حاوی کاراکتر “?” مثلاً:

rewrite ^/api/(.*)$ /internal?migrated=true;

پردازش می‌شود، تابع ngx_http_script_start_args_code این پرچم را روی 1 تنظیم می‌کند تا نشان دهد که query string در حال پردازش است. اما این پرچم هرگز به حالت اولیه بازنشانی نمی‌شود.

نقص دوم در نحوه کپی نشدن مقدار is_args به زیرموتورهای جدید هنگام پردازش دستورات بعدی مثل

set $original_endpoint $1;

است. در مرحله محاسبه طول برای دستور set، یک زیرموتور جدید با ngx_memzero مقداردهی اولیه می‌شود و در نتیجه is_args آن 0 است. اما در مرحله کپی داده‌ها، از موتور اصلی استفاده می‌شود که is_args آن همچنان 1 است. در نتیجه در مرحله محاسبه طول، منطق escaping (تبدیل کاراکترهایی مثل “+” به “%2B”) اجرا نمی‌شود و طول خام (raw) داده محاسبه می‌گردد اما در مرحله کپی، منطق escaping اجرا می‌شود و هر کاراکتر “+” به 3 بایت “%2B” تبدیل می‌شود. در نتیجه به اندازه (3 – 1) ضرب در “تعداد کاراکترهای قابل escaping بایت” بیشتر از ظرفیت بافر روی heap نوشته شده و Heap-based Buffer Overflow رخ می‌دهد.

به طور کلی موتور NGINX فکر می‌کند بافری به اندازه x نیاز دارد، اما در عمل x + y بایت در آن می‌نویسد. این y مازاد می‌تواند ساختارهای مجاور heap (مانند ngx_pool_t شامل pointer به تابع cleanup) را بازنویسی کند و در نهایت به اجرای کد (RCE) منجر شود.

بخش آسیب‌پذیر

رفتار ناامن سیستم:

پردازش دو مرحله‌ای ناهماهنگ در موتور ngx_http_rewrite_module، که در آن مرحله محاسبه طول از یک زیرموتور با is_args = 0 و مرحله کپی از موتور اصلی با is_args = 1 استفاده می‌کند. این رفتار ناامن باعث می‌شود هر مهاجمی با دسترسی شبکه (بدون نیاز به احراز هویت)، با ارسال یک درخواست ساده حاوی کاراکترهای قابل escape (مثل +، & و %)، بافر heap را سرریز کرده و در صورت فراهم بودن شرایط، کد خود را روی سرور اجرا کند.

نحوه سوءاستفاده مهاجم:

• مهاجم یک اسکن ساده روی پورت‌های 80 و 443 یا شناسایی زیردامنه‌های مرتبط انجام می‌دهد
• مهاجم یک درخواست GET به مسیری که پیکربندی آسیب‌پذیر آن را پوشش می‌دهد، همراه با تعداد زیادی کاراکتر + ارسال می‌کند (مثل /api/+++++++++++)
• سرور NGINX در مرحله اول طول خام URI را محاسبه کرده و بافری به آن اندازه روی heap تخصیص می‌دهد
• در مرحله بعدی، هر کاراکتر “+” به “%2B” تبدیل شده و سرریز بافر رخ می دهد
• در حالت ساده، پردازه (process) غیرفعال شده (Denial of Service) و پردازه مادر, آن را دوباره اجرا می‌کند
• در سیستم‌هایی که ASLR غیرفعال است، مهاجم با کنترل دقیق heap و تزریق یک payload در بدنه درخواست‌های POST، می‌تواند pointer تابع cleanup در ساختار ngx_pool_t را بازنویسی کرده و هنگام بسته شدن اتصال (فراخوانی ngx_destroy_pool)، کد خود را با دسترسی process اجرا کند
• مهاجم می‌تواند از این دسترسی برای نصب backdoor یا حرکت جانبی در شبکه داخلی استفاده کند

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری یک نقطه ورود اولیه (Initial Access) بسیار قدرتمند و در صورت فراهم بودن شرایط (ASLR غیرفعال) یک ابزار اجرای کد از راه دور (Remote Code Execution) کامل در زنجیره حمله محسوب می‌شود. با توجه به نمره CVSS 9.2 (بحرانی)، ماهیت شبکه‌ای، عدم نیاز به احراز هویت، و حدود ۱۸ سال حضور در کد NGINX (از 2008 تا 2026)، مهاجم می‌تواند از راه دور و بدون نیاز به هرگونه تعامل با کاربر، کنترل کامل NGINX را در دست گیرد. NGINX به عنوان قلب تپنده بسیاری از زیرساخت‌های وب مدرن، دسترسی مستقیم به ترافیک HTTP، نشست‌های کاربران، و در بسیاری از پیاده‌سازی‌ها به API های داخلی و میکروسرویس‌ها دارد. موفقیت در بهره‌برداری از این آسیب‌پذیری در حالت RCE عملاً به معنای نقض کامل محرمانگی (Confidentiality) و یکپارچگی (Integrity) کل سرویس وب و تمام برنامه‌های تحت وب پشت آن است.

پیش‌نیازهای بهره‌برداری (Prerequisites)

• دسترسی شبکه مهاجم به پورت‌های 80 یا 443 سرویس NGINX روی سرور هدف
• استفاده از نسخه آسیب‌پذیر NGINX
• عدم اعمال پچ امنیتی
• وجود یک پیکربندی خاص مانند:

location ~ ^/api/(.*) $ {

rewrite ^/api/(.*)$ /internal?migrated=true;

set $original_endpoint $1;

}

• نبود محدودیت دسترسی مبتنی بر IP (بدون IP whitelist)
• قرار داشتن رابط آسیب‌پذیر در معرض اینترنت یا شبکه داخلی قابل دسترس برای مهاجم
• غیرفعال بودن ASLR در سطح سیستم‌عامل برای اجرای کد از راه دور (RCE)

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

• موتور اسکریپت NGINX باید در هر دو مرحله محاسبه طول و کپی داده از یک مقدار ثابت is_args استفاده کند
• پرچم is_args باید پس از پردازش هر دستور rewrite (نه به صورت سراسری) بازنشانی شود
• تابع ngx_http_script_complex_value_code باید مقدار is_args را از موتور اصلی به زیرموتور جدید کپی کند، نه اینکه آن را به 0 مقداردهی اولیه کند
• استفاده از capture‌ های بدون نام ($1, $2) در دستورات set باید ممنوع شود، یا حداقل با همان منطق escaping در هر دو مرحله پردازش گردند
• مستندات امنیتی NGINX باید به وضوح نسبت به خطرات ترکیب ? در rewrite و capture‌ های بدون نام هشدار دهند
• ASLR باید به طور پیش‌فرض در تمام سیستم‌های لینوکسی فعال باشد

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

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

• به‌روزرسانی فوری NGINX به نسخه‌های تصحیح‌شده
• فعال‌سازی اجباری ASLR در سطح سیستم‌عامل
• پایش مداوم لاگ‌های دسترسی NGINX برای شناسایی درخواست‌های حاوی +، & و % در مسیرهای منطبق با الگوی آسیب‌پذیر

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک:

• انجام اسکن کامل پیکربندی NGINX در تمام سرورها با استفاده از ابزار اسکنر اختصاصی (مثل scan-nginx-rift.sh)
• پیاده‌سازی قوانین تشخیص نفوذ (WAF / IDS) برای شناسایی الگوهای حمله
• کاهش سطح حمله با حذف یا اصلاح پیکربندی‌های آسیب‌پذیر حتی پس از پچ
• فعال‌سازی و تقویت لاگ‌برداری تفصیلی از رفتارهای NGINX و ارسال لاگ‌ها به سیستم SIEM
• اطمینان از اجرای فرآیندهای NGINX با کمترین دسترسی ممکن (غیر از root) و استفاده از SELinux یا AppArmor

اقدامات بلندمدت برای کاهش ریسک:

• استقرار راهکارهای خودکار به‌روزرسانی امنیتی (Patch Management) برای اعمال سریع وصله‌های NGINX
• پیاده‌سازی فرآیندهای منظم بازبینی پیکربندی NGINX (Configuration Audit) به عنوان بخشی از CI/CD
• استفاده از ابزارهای تحلیل پیکربندی ایستا در چرخه توسعه زیرساخت (IaC) برای شناسایی الگوهای آسیب‌پذیر قبل از استقرار
• اجرای دوره‌ای تست نفوذ (Penetration Testing) با تمرکز بر وب‌سرورها و API Gateway ها
• تدوین و اجرای سیاست‌های هاردنینگ NGINX بر اساس راهنمای CIS Benchmarks

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده:

• وجود درخواست‌های GET به مسیرهایی با تعداد غیرعادی کاراکتر
• الگوهای URI حاوی %2B در لاگ‌های دسترسی
• افزایش ناگهانی خطاهای 502 Bad Gateway یا 504 Gateway Timeout
• مشاهده درخواست‌های متعدد و پشت سر هم به یک مسیر خاص از یک منبع واحد در بازه زمانی کوتاه
• گزارش‌های مانیتورینگ حاکی از بازآفرینی مکرر فرآیندها (افزایش ناگهانی تعداد restartها)
• وجود درخواست‌های POST با بدنه غیرعادی حاوی الگوهای تکراری (تلاش برای heap spraying)

منابع پیشنهادی برای مانیتورینگ و پایش:

• لاگ‌های دسترسی NGINX – /var/log/nginx/access.log برای تحلیل الگوهای URI غیرعادی
• لاگ‌های خطای NGINX – /var/log/nginx/error.log برای جستجوی خطاهای مرتبط با فرآیند (مثلworker process … exited on signal)
• سیستم‌های SIEM (مانند Splunk، ELK، QRadar) برای جمع‌آوری و تحلیل مرکزی لاگ‌ها
• راهکارهای WAF با قوانین اختصاصی برای شناسایی الگوی درخواست حاوی کاراکتر “+” و مسیر آسیب‌پذیر
• نظارت بر تعداد restart های فرآیند nginx: worker process
• ابزارهای اسکن آسیب‌پذیری

واکنش به حادثه (Incident Response)

• ایزوله‌سازی فوری سرور NGINX آسیب‌دیده از شبکه (قطع ترافیک ورودی یا تغییر مسیر به سرور پشتیبان) جهت جلوگیری از ادامه نفوذ و حرکت جانبی
• جمع‌آوری و حفظ لاگ‌های دسترسی و خطای NGINX، لاگ‌های سیستمی (syslog)، و در صورت امکان memory dump از فرآیند worker
• شناسایی الگوهای rewrite/set آسیب‌پذیر و مستندسازی آن‌ها
• جستجو در لاگ‌ها برای یافتن درخواست‌های حاوی “+”، “%2B” و یا الگوهای تکراری
• رمزهای عبور، توکن‌های API، کلیدهای SSH و هرگونه اعتبار دیگری که ممکن است از طریق سرور در معرض خطر قرار گرفته باشد
• اعمال پچ امنیتی (ارتقا به نسخه 1.30.1/1.31.0 یا نسخه پچ‌شده Plus) و اصلاح پیکربندی‌های آسیب‌پذیر
• اسکن کامل شبکه برای شناسایی سایر سیستم‌هایی که ممکن است مهاجم با استفاده از این سرور به آن‌ها دسترسی یافته باشد
• مستندسازی کامل حادثه (زمان وقوع، نشانه‌ها، اقدامات انجام‌شده، درس‌آموخته‌ها) و گزارش به مدیریت ارشد و تیم واکنش سریع (CSIRT)

جریان حمله (Attack Flow)

در نمودار زیر (شکل ۱)، جریان کلی بهره‌برداری از این آسیب‌پذیری برای اجرای کد از راه دور نشان داده شده است. در این سناریو، مهاجم با ارسال یک درخواست GET ساده حاوی “+” به یک Endpoint آسیب‌پذیر و سپس یک درخواست POST حاوی payload، باعث سرریز heap شده و کنترل worker process NGINX را به دست می‌گیرد.

شکل 1: جریان اجرای آسیب پذیری

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte، این آسیب‌پذیری را در محیط ایزوله و کنترل‌شده با استفاده از نسخه آسیب‌پذیر بررسی و اجرا کرده است

• • این آزمایشگاه شامل Docke نسخه آسیب‌پذیر NGINX (کامیت 98fc3bb78) است راه اندازی شده است و سرویس روی پورت 19321 اجرا شده است
  • با استفاده از اسکریپت discover-addresses-complete.sh آدرس های heap و libc در حافظه کشف می شود
  • اجرای کامل اکسپلویت و اجرای فرمان نوشتن متن “VULNERABLE” در فایل /tmp/hacked.txt
  • این اثبات مفهوم صرفاً توصیفی و آموزشی بوده و شامل تغییرات مخرب نمی‌شود

شکل 2: اجرای POC

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی از محتوای آن ممنوع است.

منابع

https://www.cve.org/CVERecord?id=CVE-2026-42945

https://nvd.nist.gov/vuln/detail/CVE-2026-42945

https://cwe.mitre.org/data/definitions/122.html

https://cwe.mitre.org/data/definitions/182.html

https://github.com/F2u0a0d3/CVE-2026-42945-nginx-rift-poc

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

GET /api/+++++++++++++++++++++++++++++++++++ HTTP/1.1
Host: target.com