Fortinet در ۹ ژوئن ۲۰۲۶ (۱۹ خرداد ۱۴۰۵) جزئیات یک آسیبپذیری بحرانی در FortiSandbox را منتشر کرد. این ضعف با شناسه CVE-2026-25089 و امتیاز CVSS 9.1 به مهاجم بدون احراز هویت اجازه میدهد با ارسال درخواست HTTP دستکاریشده به رابط وب، فرمان سیستمعامل اجرا کند. برای تجهیزی که وظیفه تحلیل فایل مشکوک و بدافزار را دارد، این فقط یک ایراد عادی در پنل مدیریت نیست؛ دسترسی مهاجم میتواند زنجیره تحلیل امنیتی، ارتباط با سایر محصولات Fortinet و اطلاعات موجود روی سامانه را درگیر کند.
هشدار رسمی Fortinet برای این آسیبپذیری راهکار موقت اعلام نکرده و مسیر اصلی را ارتقا به نسخه اصلاحشده میداند. بنابراین اگر FortiSandbox در شبکه دارید، تصمیم درست این نیست که موضوع را به پنجره نگهداری بعدی موکول کنید. ابتدا باید نسخه و سطح دسترسی Web UI را مشخص کنید، دسترسی غیرضروری را ببندید، شواهد را حفظ کنید و سپس ارتقا را با برنامه بازگشت انجام دهید.
پاسخ کوتاه: الان چه کار کنیم؟
- نسخه دقیق FortiSandbox، FortiSandbox Cloud یا PaaS را با فهرست آسیبپذیر تطبیق دهید.
- دسترسی Web UI از اینترنت و شبکههای کاربری را فوراً محدود کنید.
- قبل از ارتقا، لاگها، حسابهای مدیریتی، تغییرات تنظیمات و اتصالهای غیرعادی را بررسی و حفظ کنید.
- FortiSandbox 5.0 را به 5.0.6 یا بالاتر و شاخه 4.4 را به 4.4.9 یا بالاتر ارتقا دهید.
- اگر نشانه مشکوک وجود دارد، موضوع را صرفاً با نصب patch بسته تلقی نکنید و پاسخ به رخداد را شروع کنید.
بهروزرسانی ۲۱ جولای ۲۰۲۶ (۳۰ تیر ۱۴۰۵): ورود به CISA KEV
در بهروزرسانی ۱۶ جولای ۲۰۲۶ (۲۵ تیر ۱۴۰۵)، CISA دو آسیبپذیری FortiSandbox را به فهرست Known Exploited Vulnerabilities اضافه کرد: CVE-2026-25089 و CVE-2026-39808. این یعنی موضوع فقط یک advisory محصولی نیست؛ برای سازمانهایی که FortiSandbox یا FortiSandbox Cloud/PaaS دارند، باید مثل یک رخداد قابل پیگیری در برنامه vulnerability response دیده شود.
نکته مهم این است که Fortinet در صفحه PSIRT هر دو مورد، وضعیت Known Exploited را در زمان انتشار اولیه «No» ثبت کرده بود، اما اضافهشدن آنها به KEV یعنی شواهد بهرهبرداری فعال بعداً وارد چرخه ریسک شده است. بنابراین اگر فقط در زمان انتشار اولیه advisory را دیدهاید و آن را کماولویت گذاشتهاید، لازم است دوباره نسخه، مسیر دسترسی Web UI/API، لاگها و وضعیت ارتقا را بررسی کنید.
چرا CVE-2026-39808 کنار CVE-2026-25089 مهم است؟
CVE-2026-39808 هم از نوع OS command injection در FortiSandbox است، با CVSS 9.1 و مسیر سوءاستفاده از API endpoint. طبق advisory رسمی FG-IR-26-100، شاخه FortiSandbox 4.4.0 تا 4.4.8 باید به 4.4.9 یا بالاتر ارتقا پیدا کند. اگر سازمان چند نمونه FortiSandbox دارد، بررسی فقط یک appliance کافی نیست؛ نسخه و exposure هر نمونه باید جداگانه ثبت شود.
اقدام عملی بعد از KEV شدن
- FortiSandbox، FortiSandbox Cloud و FortiSandbox PaaS را در asset inventory جدا کنید و نسخه واقعی هر نمونه را از خود سامانه بخوانید.
- دسترسی Web UI و API را از اینترنت، شبکه کاربران و VLANهای عمومی حذف کنید و دسترسی مدیریتی را به jump host یا subnet مدیریتی محدود کنید.
- قبل از ارتقا، لاگ ورود مدیران، تغییرات configuration، درخواستهای غیرعادی HTTP و ارتباطهای outbound مشکوک را نگه دارید.
- اگر نسخه آسیبپذیر در معرض شبکه گسترده بوده، patch را پایان کار ندانید؛ مسیر پاسخ به رخداد در شبکه را هم کنار ارتقا اجرا کنید.
- بعد از ارتقا، health سامانه، ارسال sample، ارتباط با FortiGate/FortiAnalyzer و لاگگیری مرکزی را تست کنید.
برای تیمهایی که چند محصول Fortinet را همزمان نگه میدارند، این رخداد یک یادآوری جدی است: امنیت محصول امنیتی هم به تفکیک شبکه مدیریت، hardening دسترسی، لاگ خارج از تجهیز و برنامه تغییر کمریسک وابسته است.
کدام نسخههای FortiSandbox آسیبپذیرند؟
بر اساس advisory رسمی FG-IR-26-141، وضعیت نسخهها به این شکل است:
- FortiSandbox 5.0.0 تا 5.0.5: آسیبپذیر؛ ارتقا به 5.0.6 یا بالاتر.
- FortiSandbox 4.4.0 تا 4.4.8: آسیبپذیر؛ ارتقا به 4.4.9 یا بالاتر.
- FortiSandbox Cloud 5.0.4 و 5.0.5: آسیبپذیر؛ ارتقا به 5.0.6 یا بالاتر.
- FortiSandbox PaaS 5.0.4 و 5.0.5: آسیبپذیر؛ ارتقا به 5.0.6 یا بالاتر.
- FortiSandbox 5.2: طبق جدول Fortinet تحت تأثیر نیست.
نسخه را از خود تجهیز یا کنسول مدیریتی بخوانید؛ به CMDB یا فایل قدیمی داراییها اکتفا نکنید. در شبکههایی که چند FortiSandbox یا نمونه Cloud دارند، هر نمونه باید جداگانه کنترل شود.
چرا CVE-2026-25089 خطرناک است؟
نوع ضعف، OS Command Injection از طریق Web UI است. یعنی مهاجم لازم نیست ابتدا حساب مدیریتی داشته باشد؛ یک درخواست HTTP خاص میتواند ورودی را به فرمان سیستمعامل تبدیل کند. ترکیب سه عامل، ریسک را بالا میبرد: حمله از راه دور، نبود نیاز به احراز هویت و اجرای فرمان روی سامانهای که معمولاً به بخشهای حساس شبکه متصل است.
FortiSandbox برای دریافت نمونه از ایمیل، endpoint، فایروال یا سایر اجزای Security Fabric به شبکههای مختلف دسترسی دارد. به همین دلیل طراحی دسترسی آن باید محدود و مستند باشد. حتی اگر پنل مستقیماً روی اینترنت منتشر نشده باشد، دسترسی از یک VLAN بزرگ مدیریتی یا شبکه کاربری آلوده همچنان میتواند سطح حمله ایجاد کند.
چکلیست مهار فوری پیش از ارتقا
۱. مسیر دسترسی Web UI را مشخص کنید
بررسی کنید رابط مدیریتی از چه IPها، VLANها، VPNها و مسیرهای NAT قابل دسترسی است. دسترسی باید به jump host یا شبکه مدیریت محدود شود. اگر Web UI روی اینترنت دیده میشود، محدودسازی آن نباید تا پایان فرایند تغییر نسخه عقب بیفتد.
۲. از تنظیمات و شواهد نسخه پشتیبان بگیرید
قبل از ارتقا، backup معتبر تنظیمات تهیه کنید و زمان، checksum و محل نگهداری آن را ثبت کنید. لاگهای مدیریتی و امنیتی را نیز به محل جداگانه منتقل کنید تا اگر بعداً نشانهای از نفوذ پیدا شد، شواهد با rotation یا تغییرات پس از upgrade از بین نرود.
۳. حسابها و تغییرات مدیریتی را بازبینی کنید
حساب تازه، تغییر نقش، ورود از IP غیرمنتظره، تغییر policy، تنظیم DNS یا gateway و هر اتصال خروجی غیرعادی باید بررسی شود. نبود هشدار در داشبورد بهتنهایی به معنی سالم بودن سامانه نیست؛ باید لاگها و وضعیت واقعی تنظیمات با baseline قبلی مقایسه شوند.
۴. ارتباط FortiSandbox با سایر اجزا را مرور کنید
مسیرهای ارتباطی با FortiGate، FortiManager، FortiAnalyzer، ایمیل گیتوی، endpointها و مخازن فایل را فهرست کنید. اگر احتمال compromise وجود دارد، credentialها، API tokenها و کلیدهایی که FortiSandbox به آنها دسترسی داشته باید در دامنه بررسی قرار گیرند.
آیا patch بهتنهایی کافی است؟
اگر هیچ دسترسی مشکوکی دیده نشده، پنل مدیریت در یک شبکه محدود قرار داشته و لاگ کافی دارید، ارتقا همراه با بازبینی دسترسیها میتواند اقدام اصلی باشد. اما اگر Web UI از اینترنت قابل مشاهده بوده، لاگ ناقص است، حساب ناشناس وجود دارد یا اتصال خروجی غیرعادی دیده میشود، نصب نسخه جدید فقط آسیبپذیری را میبندد؛ اثر احتمالی نفوذ قبلی را پاک نمیکند.
در سناریوی مشکوک، ترتیب مناسب معمولاً شامل حفظ شواهد، containment، بررسی دامنه دسترسی، تعویض credentialهای در معرض خطر، ارتقا یا بازسازی سالم و سپس monitoring تقویتشده است. تصمیم برای rebuild باید با توجه به شواهد و نقش واقعی تجهیز گرفته شود.
برنامه ارتقای کمریسک
- Release Notes و مسیر upgrade مجاز برای نسخه فعلی را بررسی کنید.
- backup تنظیمات و برنامه rollback را قبل از تغییر آزمایش کنید.
- وابستگیهای Security Fabric و ارسال نمونه را ثبت کنید.
- پس از ارتقا، نسخه، health، دریافت و تحلیل نمونه، لاگ و ارتباط با محصولات متصل را تست کنید.
- محدودسازی Web UI را به حالت قبل برنگردانید؛ دسترسی مدیریتی محدود باید دائمی باشد.
این رخداد چه درس معماری دارد؟
محصول امنیتی مصون از آسیبپذیری نیست. اگر همه پنلهای فایروال، WAF، Sandbox و مدیریت مرکزی در یک VLAN بزرگ قرار گیرند، compromise یک میزبان مدیریتی میتواند مسیر حرکت جانبی به چند سامانه حساس ایجاد کند. شبکه مدیریت مستقل، trusted host، MFA، ثبت لاگ خارج از تجهیز و دسترسی از jump host باید بخشی از طراحی باشند، نه واکنش موقت بعد از انتشار CVE.
برای مرور این بخش میتوانید راهنمای طراحی و سختسازی امنیت شبکه و چکلیست واکنش به آسیبپذیریهای Fortinet را هم ببینید.
برای بررسی FortiSandbox یا معماری مدیریت امنیت نیاز به کمک دارید؟
اگر نسخه آسیبپذیر دارید، Web UI در معرض دسترسی گسترده بوده یا مطمئن نیستید patch برای وضعیت فعلی کافی است، میتوان دامنه بررسی، مسیر مهار و برنامه ارتقا را بدون ارسال اطلاعات حساس در پیام اول مشخص کرد.
