آسیب‌پذیری بحرانی VMware ESXi و vCenter | VMSA-2026-0006.1

اگر زیرساخت مجازی‌سازی سازمان شما بر پایه VMware ESXi، VMware vCenter، VMware vSphere Foundation یا VVF، VMware Cloud Foundation یا VCF اجرا می‌شود، هشدار امنیتی VMSA-2026-0006.1 از آن دسته Advisoryهایی نیست که بتوان بررسی آن را تا Maintenance Window عادی بعدی به تعویق انداخت.

Broadcom در این Advisory پنج آسیب‌پذیری را در محصولات VMware اعلام کرده است که سه مورد از آن‌ها در محدوده Critical قرار دارند. دو آسیب‌پذیری vCenter با امتیاز CVSS برابر 9.8 می‌توانند بدون نیاز به حساب کاربری معتبر، از طریق دسترسی شبکه به vCenter مورد سوءاستفاده قرار گیرند؛ یکی برای دور زدن احراز هویت و دیگری برای اجرای کد دلخواه.

آسیب‌پذیری بحرانی سوم با شناسه CVE-2026-47876 نیز یک ضعف در کارت شبکه مجازی VMXNET3 است که در شرایط مشخص می‌تواند به VM Escape منجر شود؛ یعنی مهاجمی که از قبل داخل یک ماشین مجازی دسترسی Administrator یا Root دارد، ممکن است بتواند از مرز ماشین مجازی عبور کرده و روی ESX Host کد اجرا کند.

نکته مهم‌تر اینکه Broadcom برای این مجموعه آسیب‌پذیری‌ها هیچ Workaround رسمی ارائه نکرده است. محدود کردن Management Network، استفاده از Jump Server، VPN، ACL و Firewall می‌تواند سطح حمله را کاهش دهد، اما آسیب‌پذیری را برطرف نمی‌کند. راهکار اصلی، نصب نسخه‌ها و Patchهای اصلاح‌شده‌ای است که Broadcom در Response Matrix رسمی اعلام کرده است.

آخرین وضعیت بررسی‌شده: ۱۴ اوت ۲۰۲۶ | آخرین Revision رسمی Advisory: VMSA-۲۰۲۶-۰۰۰۶.۱ مورخ ۳ اوت ۲۰۲۶

سطح: پیشرفته | مناسب برای: مدیران VMware، تیم‌های زیرساخت و امنیت، مدیران دیتاسنتر، متخصصان Cloud و Virtualization، تیم‌های SOC و Incident Response و سازمان‌هایی که از vSphere، VVF یا VCF استفاده می‌کنند.

فهرست مطالب

• خلاصه VMSA-۲۰۲۶-۰۰۰۶.۱
• چرا این Advisory تا این اندازه جدی است؟
• جدول آسیب‌پذیری‌های VMSA-۲۰۲۶-۰۰۰۶.۱
• CVE-۲۰۲۶-۵۹۳۰۹؛ دور زدن احراز هویت در vCenter
• CVE-۲۰۲۶-۵۹۳۱۰؛ اجرای کد از طریق Syslog Server
• CVE-۲۰۲۶-۴۷۸۷۶؛ خروج از VM از طریق VMXNET3
• CVE-۲۰۲۶-۴۱۷۰۳؛ افشای اطلاعات یا DoS
• CVE-۲۰۲۶-۴۱۷۰۹؛ نقص در ثبت عملیات مدیریتی
• چه محصولات و محیط‌هایی تحت تأثیر هستند؟
• آیا VVF و VCF آسیب‌پذیر هستند؟
• نسخه‌ها و Buildهای اصلاح‌شده
• vSphere ۸ U3k یا U2f؛ کدام را نصب کنیم؟
• چطور Version و Build را بررسی کنیم؟
• آیا سوءاستفاده فعال مشاهده شده است؟
• اقدامات فوری پیشنهادی
• ابتدا vCenter را Patch کنیم یا ESX را؟
• آیا آپدیت vCenter ماشین‌های مجازی را قطع می‌کند؟
• به‌روزرسانی ESX و Rolling Update
• آیا می‌توان از Live Patch استفاده کرد؟
• نکات مهم برای VMware Cloud Foundation ۵.x
• هشدار Back-in-Time برای مهاجرت به VCF ۹
• VxRail، SimpliVity و سیستم‌های مهندسی‌شده
• وضعیت VMware vSphere ۷ و نسخه‌های قدیمی‌تر
• آیا زمان برنامه‌ریزی مهاجرت از vSphere ۸ رسیده است؟
• بعد از Patch چه چیزهایی باید بررسی شوند؟
• اگر احتمال نفوذ وجود دارد، Patch کافی نیست
• سوالات متداول
• جمع‌بندی

خلاصه VMSA-۲۰۲۶-۰۰۰۶.۱

Broadcom نسخه اولیه VMSA-۲۰۲۶-۰۰۰۶ را در ۲۹ ژوئیه ۲۰۲۶ منتشر کرد و در ۳ اوت ۲۰۲۶ آن را به VMSA-2026-0006.1 ارتقا داد. مهم‌ترین تغییر Revision جدید، اضافه شدن Express Patchهای مربوط به vSphere ۸ Update ۲ بود.

Advisory دارای سطح کلی Critical و بازه امتیاز CVSS از ۲.۷ تا ۹.۸ است و پنج CVE را شامل می‌شود:

• CVE-2026-59309: دور زدن احراز هویت در VMware Directory Service مربوط به vCenter
• CVE-2026-59310: Directory Traversal در Syslog Server مربوط به vCenter
• CVE-2026-47876: Out-of-Bounds Write در VMXNET3 و امکان VM Escape
• CVE-2026-41703: Out-of-Bounds Read در ESX، Workstation و Fusion
• CVE-2026-41709: ثبت نشدن برخی عملیات مدیریتی در ESX

Broadcom رسیدگی به این مجموعه را در چارچوب ITIL در سطح Emergency Change قرار داده است؛ یعنی موضوع از دید سازنده فراتر از یک Patch معمول دوره‌ای است.

همچنین هیچ Workaround رسمی برای هیچ‌یک از پنج آسیب‌پذیری ارائه نشده است. Patch کردن نسخه آسیب‌پذیر، راهکار نهایی اعلام‌شده توسط Broadcom است.

چرا این آسیب‌پذیری‌های VMware تا این اندازه جدی هستند؟

برای درک اهمیت این Advisory باید به جای نگاه کردن صرف به عدد CVSS، جایگاه اجزای آسیب‌پذیر در معماری زیرساخت را در نظر گرفت.

vCenter یک سرویس مدیریتی معمولی نیست. در بسیاری از سازمان‌ها، vCenter نقطه مرکزی مدیریت Hostها، Clusterها، Datastoreها، شبکه‌های مجازی، مجوزها، VMها و بسیاری از عملیات Lifecycle است.

در نتیجه وجود دو آسیب‌پذیری Critical با امتیاز ۹.۸ که برای Exploit شدن به حساب کاربری معتبر نیاز ندارند، اهمیت بسیار بالایی دارد. مهاجم فقط باید بتواند از طریق شبکه به سرویس آسیب‌پذیر vCenter دسترسی داشته باشد.

از طرف دیگر، CVE-۲۰۲۶-۴۷۸۷۶ مرز امنیتی بین Guest و Hypervisor را هدف قرار می‌دهد. مجازی‌سازی بر این اصل استوار است که نفوذ به یک VM نباید به‌طور خودکار به معنی نفوذ به Host و سایر VMها باشد. یک VM Escape بالقوه همین مرز را تضعیف می‌کند.

ترکیب موارد زیر دلیل اهمیت ویژه این Advisory است:

• دو CVE بحرانی vCenter با دسترسی شبکه و بدون نیاز به حساب معتبر
• یک VM Escape با امتیاز ۹.۳
• نبود Workaround رسمی
• تأثیر بر اجزای مرکزی VVF و VCF
• تأثیر بر چند شاخه اصلی vSphere ۸ و ۹
• وجود یک ضعف Logging که می‌تواند تحلیل رخداد را دشوارتر کند

جدول آسیب‌پذیری‌های VMSA-۲۰۲۶-۰۰۰۶.۱

CVE-۲۰۲۶-۵۹۳۰۹؛ دور زدن احراز هویت در vCenter

CVE-2026-59309 یک آسیب‌پذیری Authentication Bypass در VMware Directory Service است و Broadcom برای آن امتیاز CVSS برابر 9.8 در نظر گرفته است.

مهاجمی که از طریق شبکه به vCenter دسترسی داشته باشد ممکن است بتواند فرایند احراز هویت را دور بزند و بدون مجوز لازم به سیستم دسترسی پیدا کند.

یکی از نکات مهم این CVE آن است که مشکل به Enhanced Linked Mode، Integrated Windows Authentication یا Active Directory Integration محدود نیست.

بنابراین این استدلال‌ها معتبر نیستند:

• «ما Enhanced Linked Mode نداریم، پس آسیب‌پذیر نیستیم.»
• «ما IWA استفاده نمی‌کنیم، پس مشکلی نداریم.»
• «vCenter ما به Active Directory متصل نیست، پس Patch لازم نیست.»

ضعف در خود vCenter وجود دارد و نحوه تنظیم Identity Source، آسیب‌پذیری را حذف نمی‌کند.

ریسک عملی CVE-۲۰۲۶-۵۹۳۰۹

اگر Management Plane بدون محدودیت مناسب از شبکه‌های عمومی، شبکه کاربران، شبکه سرورها یا اینترنت قابل دسترس باشد، دامنه حمله به‌مراتب بزرگ‌تر خواهد بود.

به همین دلیل جداسازی Management Network، استفاده از VPN یا Jump Host و محدود کردن دسترسی Firewall اقدام‌های بسیار مهمی هستند؛ اما باید تأکید کرد که این موارد Mitigation هستند و جای Patch را نمی‌گیرند.

CVE-۲۰۲۶-۵۹۳۱۰؛ اجرای کد از طریق Syslog Server در vCenter

CVE-2026-59310 یک آسیب‌پذیری Directory Traversal در Syslog Server مربوط به vCenter است و مانند CVE قبلی امتیاز CVSS آن 9.8 است.

طبق Advisory رسمی، مهاجمی که دسترسی شبکه به vCenter داشته باشد ممکن است بتواند از این ضعف برای اجرای کد دلخواه استفاده کند.

این آسیب‌پذیری نیز به حساب کاربری معتبر نیاز ندارد.

وجود هم‌زمان یک Authentication Bypass و یک مسیر بالقوه Arbitrary Code Execution در سامانه‌ای مانند vCenter، دلیل مهمی است که این Advisory نباید در چرخه Patch معمول ماهانه قرار گیرد.

CVE-۲۰۲۶-۴۷۸۷۶؛ خروج از ماشین مجازی از طریق VMXNET3

CVE-2026-47876 یک Out-of-Bounds Write در کارت شبکه مجازی VMXNET3 است و امتیاز CVSS برابر 9.3 دارد.

برای Exploit کردن این ضعف، مهاجم باید از قبل داخل یک VM که از VMXNET3 استفاده می‌کند، دسترسی مدیریتی محلی در سطح Administrator یا Root داشته باشد.

در صورت موفقیت، مهاجم ممکن است بتواند روی ESX Host کد اجرا کند.

این همان سناریویی است که به آن VM Escape گفته می‌شود.

آیا مهاجم می‌تواند مستقیماً از اینترنت ESXi را تصاحب کند؟

نه از طریق این CVE به‌تنهایی. CVE-۲۰۲۶-۴۷۸۷۶ ابتدا نیازمند دسترسی مدیریتی داخل Guest است.

اما این پیش‌شرط نباید باعث کم‌اهمیت تلقی کردن آسیب‌پذیری شود. در یک حمله واقعی ممکن است مهاجم ابتدا از طریق یکی از موارد زیر یک VM را در اختیار بگیرد:

• آسیب‌پذیری سیستم‌عامل یا نرم‌افزار
• Web Shell
• سرقت رمز عبور
• Credential Stuffing
• Ransomware
• RDP یا SSH آسیب‌پذیر
• خطای پیکربندی

در چنین سناریویی، VM Escape می‌تواند مرحله دوم حمله باشد و اجازه دهد مهاجم از Guest به لایه Hypervisor برسد.

آیا VMهایی که VMXNET3 ندارند تحت تأثیر هستند؟

برای همین CVE مشخص، Broadcom اعلام کرده VMهایی که از Virtual Network Adapterهای دیگر استفاده می‌کنند تحت تأثیر CVE-۲۰۲۶-۴۷۸۷۶ نیستند.

اما Broadcom صراحتاً تغییر VMXNET3 به کارت‌هایی مثل E1000 را به‌عنوان استراتژی امنیتی عمومی توصیه نمی‌کند. کارت‌های Non-Paravirtualized نیز در گذشته آسیب‌پذیری‌های خود را داشته‌اند و تغییر آن‌ها می‌تواند باعث کاهش کارایی شبکه شود.

رفع صحیح مشکل، Patch کردن ESX است.

آیا آپدیت VMware Tools مشکل را حل می‌کند؟

خیر. با اینکه VMXNET3 دارای Driver داخل Guest است، محل آسیب‌پذیری CVE-۲۰۲۶-۴۷۸۷۶ در سمت ESX قرار دارد.

در نتیجه:

• آپدیت VMware Tools به‌تنهایی کافی نیست.
• ارتقای Virtual Hardware Version مشکل را برطرف نمی‌کند.
• تعویض کارت شبکه VM راهکار اصلی توصیه‌شده نیست.
• ESX Host باید Patch شود.

CVE-۲۰۲۶-۴۱۷۰۳؛ افشای اطلاعات یا اختلال در Host Process

CVE-2026-41703 یک Out-of-Bounds Read است که ESX، VMware Workstation و VMware Fusion را تحت تأثیر قرار می‌دهد.

در ESX، امتیاز CVSS این آسیب‌پذیری 7.6 و سطح آن Important است.

مهاجمی که مجوز Deploy کردن ماشین مجازی را داشته باشد ممکن است بتواند Out-of-Bounds Read ایجاد کند که نتیجه احتمالی آن:

• افشای اطلاعات
• یا ایجاد Denial of Service در Host Process

باشد.

این CVE برخلاف CVE-۲۰۲۶-۴۷۸۷۶ یک VM Escape محسوب نمی‌شود و به مهاجم امکان اجرای کد روی Host را نمی‌دهد.

در Workstation و Fusion نیز اثر این آسیب‌پذیری به Information Disclosure محدود شده و امتیاز آن ۲.۷ است.

CVE-۲۰۲۶-۴۱۷۰۹؛ ثبت نشدن بعضی عملیات مدیریتی ESX

CVE-2026-41709 با امتیاز CVSS برابر 2.7 کم‌خطرترین CVE این مجموعه از نظر امتیاز است، اما در محیط‌های Enterprise نباید نادیده گرفته شود.

یک Administrator مخرب ممکن است بتواند برخی عملیات را بدون ثبت مناسب در Log انجام دهد.

این ضعف به‌تنهایی باعث اجرای کد یا VM Escape نمی‌شود، اما در حوزه‌های زیر اهمیت دارد:

• Incident Response
• Forensics
• Insider Threat
• Auditing
• Compliance
• ردیابی فعالیت Administratorها

از منظر پاسخ به رخداد، وجود چنین ضعفی یعنی نبود یک Event در Log نباید به‌تنهایی به‌عنوان اثبات عدم وقوع آن عملیات تلقی شود.

چه محصولات و محیط‌هایی تحت تأثیر هستند؟

VMSA-۲۰۲۶-۰۰۰۶.۱ فقط مربوط به ESXi مستقل نیست. محصولات تحت تأثیر شامل موارد زیر هستند:

• VMware ESX / ESXi
• VMware vCenter Server
• VMware Workstation
• VMware Fusion
• VMware Cloud Foundation یا VCF
• VMware vSphere Foundation یا VVF
• VMware Telco Cloud Platform
• VMware Telco Cloud Infrastructure

نکته نام‌گذاری: از VCF و VVF نسخه ۹ به بعد، Broadcom نام Hypervisor را از ESXi به ESX تغییر داده است؛ بااین‌حال Patch و Build Identifierها هنوز در بسیاری از موارد با پیشوند ESXi نمایش داده می‌شوند.

آیا VMware VVF و VCF نیز آسیب‌پذیر هستند؟

بله. دلیل آن ساده است: VMware vSphere Foundation و VMware Cloud Foundation از vCenter و ESX به‌عنوان اجزای اصلی زیرساخت استفاده می‌کنند.

بنابراین صرف اینکه محیط شما به‌عنوان VVF ۹ یا VCF ۹ نصب شده است، به معنی مصون بودن نیست. نسخه دقیق و Build مربوط به vCenter و ESX باید با Response Matrix مقایسه شود.

طبق FAQ رسمی Broadcom:

• VCF Operations مستقیماً تحت تأثیر این VMSA نیست.
• VCF Automation مستقیماً تحت تأثیر نیست.
• VMware NSX تحت تأثیر این Advisory نیست.
• SDDC Manager جزء مستقیم آسیب‌پذیری‌های این VMSA نیست، هرچند برخی Releaseهای VCF ممکن است Update مرتبط دیگری برای آن داشته باشند.

تمرکز اصلی باید روی Build واقعی vCenter و ESX باشد.

کدام نسخه‌های VMware باید به‌روزرسانی شوند؟

نسخه اصلاح‌شده به شاخه محصول بستگی دارد. جدول زیر مهم‌ترین مقاصد Patch را بر اساس آخرین Response Matrix رسمی VMSA-۲۰۲۶-۰۰۰۶.۱ نشان می‌دهد:

توجه: Patchها Cumulative هستند. اگر نسخه‌ای جدیدتر از Fixed Version جدول دارید و Release آن اصلاحات را به‌صورت تجمعی شامل می‌شود، لازم نیست به Build قدیمی‌تر Downgrade کنید.

همیشه آخرین Response Matrix خود Advisory را قبل از Patch بررسی کنید؛ زیرا Broadcom ممکن است Revision جدیدی منتشر کند.

vSphere ۸ U3k یا U2f؛ کدام گزینه بهتر است؟

برای سازمان‌هایی که روی vSphere ۸ هستند، تفاوت Update 3k و Update 2f مهم است.

Broadcom شاخه vSphere 8 Update 3 را مقصد ترجیحی برای vSphere ۸ می‌داند.

8.0 U3k یک Patch تجمعی است که علاوه بر CVEهای این Advisory، سایر Security Fixها و Bug Fixهای منتشرشده در آن شاخه را نیز شامل می‌شود.

در مقابل، 8.0 U2f به‌عنوان Express Patch برای سازمان‌هایی ارائه شده است که فعلاً امکان انتقال به Update ۳ را ندارند.

طبق توضیح Broadcom، Patchهای Update ۲ این Advisory فقط Critical CVEهای این Advisory را هدف قرار می‌دهند.

بنابراین در صورت سازگاری زیرساخت:

8.0 U3k یا نسخه جدیدتر

مقصد منطقی‌تری نسبت به باقی ماندن روی Update ۲ است.

اما پیش از ارتقا حتماً سازگاری موارد زیر بررسی شود:

• Firmware سرورها
• Driverها
• Storage Controller
• NIC
• vSAN
• Backup Software
• Replication
• NSX
• Monitoring Agentها
• Vendor Add-onها

چگونه نسخه و Build مربوط به ESX و vCenter را بررسی کنیم؟

صرف دیدن عبارت‌هایی مانند «vCenter ۹.۱» یا «ESXi ۸» کافی نیست. معیار اصلی برای تشخیص Patch شدن، Version، Update Level و Build Number است.

بررسی Build در vCenter

در vSphere Client می‌توانید Build مربوط به vCenter را در صفحه Summary مشاهده کنید.

در PowerCLI نیز بعد از اتصال با Connect-VIServer می‌توانید از این متغیرها استفاده کنید:

$global:DefaultVIServer.Version
$global:DefaultVIServer.Build

بررسی تمام ESX Hostها با PowerCLI

Get-VMHost | Select-Object Name,Version,Build

برای محیط‌های بزرگ‌تر می‌توانید خروجی را مرتب کنید:

Get-VMHost |
Select-Object Name,Version,Build |
Sort-Object Version,Build

یا آن را برای مستندسازی به CSV منتقل کنید:

Get-VMHost |
Select-Object Name,Version,Build |
Export-Csv .\esx-build-inventory.csv -NoTypeInformation

برای عملیات اضطراری پیشنهاد می‌شود Inventory حداقل شامل این موارد باشد:

• نام vCenter
• Version و Build vCenter
• نام Cluster
• نام Host
• Version و Build Host
• نوع VVF، VCF یا vSphere مستقل
• وضعیت vSAN
• نوع Hardware Platform
• امکان vMotion
• Maintenance Window
• وضعیت Backup

آیا سوءاستفاده فعال از VMSA-۲۰۲۶-۰۰۰۶ مشاهده شده است؟

طبق آخرین FAQ رسمی Broadcom در زمان نگارش این مقاله، سازنده اعلام کرده اطلاعاتی در اختیار ندارد که نشان دهد این آسیب‌پذیری‌ها در دنیای واقعی مورد بهره‌برداری قرار گرفته‌اند.

این خبر مثبت است، اما نباید آن را با «امن بودن تا اطلاع ثانوی» اشتباه گرفت.

اکنون:

• CVEها عمومی شده‌اند.
• Attack Vectorها مشخص هستند.
• نسخه‌های Patch شده منتشر شده‌اند.
• دو ضعف vCenter بدون احراز هویت هستند.
• یک VM Escape وجود دارد.
• هیچ Workaround رسمی اعلام نشده است.

فاصله میان انتشار عمومی یک آسیب‌پذیری مهم و توسعه Proof-of-Concept یا ابزارهای سوءاستفاده همیشه طولانی نیست.

بنابراین منتظر ماندن برای مشاهده اولین Exploit عمومی، استراتژی مناسبی برای یک Management Plane مجازی‌سازی نیست.

راهکار فوری برای کاهش خطر چیست؟

۱. تمام vCenterها و ESX Hostها را همین امروز Inventory کنید

فقط Production را بررسی نکنید. موارد زیر معمولاً فراموش می‌شوند:

• DR Site
• Lab
• Test Cluster
• vCenter قدیمی
• Hostهای Standalone
• Management Domain
• Workload Domainها

سیستمی که تیم تصور می‌کند «دیگر استفاده نمی‌شود» اما همچنان روشن و قابل دسترس است، می‌تواند به نقطه ورود تبدیل شود.

۲. Exposure مربوط به Management Plane را بررسی کنید

vCenter و ESX نباید بدون نیاز واقعی از شبکه‌های عمومی در دسترس باشند.

ساختار بهتر شامل مواردی مانند این است:

• Management VLAN مجزا
• Firewall ACL
• VPN
• Jump Server یا Bastion Host
• MFA روی مسیر دسترسی مدیریتی
• عدم دسترسی مستقیم کاربران عادی به vCenter و ESX

این اقدامات ریسک Exploit شبکه‌ای را کاهش می‌دهند، اما جایگزین Patch نیستند.

۳. از vCenter یک Backup معتبر تهیه کنید

قبل از Patch اضطراری، Backup باید تازه، قابل بازیابی و مستند باشد.

Broadcom برای vCenter Server Appliance از File-Based Backup و Image-Based Backup پشتیبانی می‌کند و روش پیشنهادی File-Based Backup از طریق VAMI در پورت ۵۴۸۰ قابل انجام است.

https://vcenter.example.com:5480

صرف وجود Snapshot قدیمی را معادل Backup تأییدشده در نظر نگیرید.

همچنین مطمئن شوید:

• Backup جدید است.
• Destination در دسترس است.
• Credentials Backup معتبر هستند.
• Restore Procedure شناخته شده است.
• Backup از نظر حجم و Log بررسی شده است.

۴. Product Interoperability Matrix را بررسی کنید

قبل از Patch، سازگاری vCenter و ESX را با یکدیگر بررسی کنید.

در محیط‌های پیچیده‌تر موارد زیر نیز باید در Compatibility Assessment قرار گیرند:

• vSAN
• NSX
• Firmware
• Server Model
• Storage
• Backup
• Replication
• Third-party Plug-in

۵. Patch را ابتدا در یک Pilot کنترل‌شده آزمایش کنید

اگر معماری اجازه می‌دهد، ابتدا یک Host یا Cluster کم‌ریسک را انتخاب کنید و موارد زیر را بررسی کنید:

• Boot صحیح Host
• Reconnect شدن به vCenter
• vMotion
• HA
• DRS
• vSAN Health
• Distributed Switch
• Backup Agent
• Monitoring

بعد از تأیید سلامت Pilot، Rollout را به سایر Clusterها ادامه دهید.

ابتدا vCenter را Patch کنیم یا ESX را؟

راهنمای سنتی VMware معمولاً Patch کردن vCenter پیش از ESX را ترجیح می‌داد، اما در نسل‌های جدید این الزام همیشه مطلق نیست.

Broadcom برای VMSA-۲۰۲۶-۰۰۰۶ تأکید می‌کند که Product Interoperability Matrix مرجع اصلی تصمیم‌گیری است.

در این Advisory، یک دلیل امنیتی قوی برای اولویت دادن به vCenter وجود دارد: دو آسیب‌پذیری vCenter دارای امتیاز ۹.۸ و بدون نیاز به احراز هویت هستند.

در یک محیط بزرگ ممکن است این توالی منطقی باشد:

1. Backup و Pre-check مربوط به vCenter
2. Patch کردن vCenter
3. بررسی سلامت سرویس‌های مدیریتی
4. Patch کردن چند Cluster به‌صورت موازی و کنترل‌شده

اما اگر Maintenance Window مربوط به vCenter در دسترس نیست و Compatibility Matrix نشان دهد ESX Patch شده با vCenter فعلی سازگار است، می‌توان Patch کردن Hostها را زودتر آغاز کرد.

پس پاسخ دقیق این نیست که «همیشه vCenter اول» یا «همیشه ESX اول»؛ بلکه باید بر اساس:

• Severity
• Interoperability
• تعداد Hostها
• Maintenance Window
• Live Patch Eligibility
• ساختار VCF/VVF

تصمیم گرفته شود.

آیا Update کردن vCenter باعث توقف VMها می‌شود؟

خیر. vCenter Management Plane است و Update یا Restart آن باعث خاموش شدن VMهایی که روی ESX Hostها در حال اجرا هستند نمی‌شود.

اما در طول عملیات ممکن است موقتاً این موارد در دسترس نباشند:

• vSphere Client
• APIهای مدیریتی
• بعضی عملیات Automation
• عملیات مدیریتی مبتنی بر vCenter

بنابراین Maintenance Window مدیریتی لازم است، حتی اگر Workloadها به کار خود ادامه دهند.

به‌روزرسانی ESX و Rolling Update

در روش Update معمول ESX، Host نیاز به Restart دارد.

در Clusterهایی که vMotion در دسترس است، روش استاندارد عملیاتی معمولاً به این صورت است:

1. بررسی Health کلاستر
2. vMotion ماشین‌های مجازی از Host
3. قرار دادن Host در Maintenance Mode
4. اعمال Update
5. Restart Host در صورت نیاز
6. بررسی Storage، Network و Agentها
7. خروج از Maintenance Mode
8. بازگرداندن Workload در صورت نیاز
9. انتقال به Host بعدی

ماشین‌هایی که امکان vMotion ندارند ممکن است برای Restart Host نیاز به خاموش شدن داشته باشند.

آیا Patchهای VMSA-۲۰۲۶-۰۰۰۶ با ESX Live Patch سازگار هستند؟

بعضی Updateهای ESX مربوط به این Advisory با Live Patch سازگار هستند؛ اما این قابلیت به شرایط محیط و Source Version بستگی دارد.

Broadcom اعلام کرده Live Patch و Quick Patch معمولاً نیاز دارند سیستم روی Update قبلی همان Major Version، یعنی وضعیت N-۱، قرار داشته باشد.

سیستم‌هایی که چند Update عقب‌تر هستند باید ابتدا از مسیر Update معمول به سطح مناسب برسند.

همچنین:

• ESX Live Patch می‌تواند در بعضی محیط‌ها Restart را کاهش دهد.
• Release Notes مقصد باید برای Eligibility بررسی شود.
• Updateهای vCenter این Advisory برای Quick Patch واجد شرایط نیستند.

بنابراین صرف وجود قابلیت Live Patch به معنی قابل استفاده بودن آن در تمام Hostها نیست.

نکات مهم برای VMware Cloud Foundation ۵.x

در محیط VCF ۵.x نباید vCenter یا ESX را مانند یک محیط Standalone vSphere و خارج از Lifecycle Management مربوط به VCF Patch کرد.

Broadcom برای Patchهای خارج از Bill of Materials استاندارد VCF، فرآیندهای رسمی مانند Async Patching و در برخی Releaseها Flexible BOM را ارائه کرده است.

به همین دلیل، برای VCF ۵.x:

• نسخه دقیق SDDC Manager را مشخص کنید.
• KB ۸۸۲۸۷ / Article ۳۴۴۹۳۵ را بررسی کنید.
• Patch Identifier مناسب Release خود را پیدا کنید.
• بررسی کنید Release شما باید از Async Patch Tool استفاده کند یا Flexible BOM.
• Upgrade Path بعد از Patch را نیز قبل از اجرا بررسی کنید.

اعمال یک Offline Bundle عمومی ESXi خارج از مسیر VCF Lifecycle می‌تواند Environment State و قابلیت Upgrade بعدی را دچار مشکل کند.

هشدار مهم Back-in-Time برای مهاجرت به VCF ۹

یکی از مهم‌ترین نکات عملیاتی این Advisory، ارتباط آن با پروژه‌های Migration به VMware Cloud Foundation ۹ است.

Broadcom رسماً تأیید کرده است که بعضی Patchهای vSphere ۸ و ۹.۰ این Advisory می‌توانند باعث Back-in-Time Upgrade Restriction شوند.

این وضعیت زمانی رخ می‌دهد که Build نصب‌شده روی محیط فعلی، از Build موجود در Target Upgrade جدیدتر باشد.

برای مثال:

Current patched build
        ↓
Build number newer than
        ↓
Target VCF 9 upgrade payload
        ↓
Back-in-Time restriction

در چنین وضعیتی، VCF Installer اجازه Upgrade را نمی‌دهد؛ زیرا ارتقا عملاً برخی Componentها را به Build قدیمی‌تر برمی‌گرداند و ممکن است Fixهای امنیتی را از بین ببرد.

Broadcom اعلام کرده Patchهای vSphere ۸.۰ و ۹.۰ مربوط به این Advisory، از جمله Patchهایی که روی VCF ۵.x از مسیر Async Patching اعمال می‌شوند، می‌توانند Upgrade به VCF ۹.x را تا انتشار Target Build سازگار بعدی مسدود کنند.

آیا به دلیل Back-in-Time نباید Patch کنیم؟

خیر.

Back-in-Time یک محدودیت Lifecycle و Upgrade Planning است، نه دلیلی برای باقی ماندن روی Build دارای آسیب‌پذیری Critical.

اگر پروژه Migration هنوز شروع نشده است:

1. ریسک امنیتی فعلی را Patch کنید.
2. Build جدید را مستند کنید.
3. Target VCF ۹ سازگار بعدی را در برنامه Migration لحاظ کنید.

اگر Migration در میانه اجرا است، تیم امنیت و تیم پروژه باید مشترکاً:

• Current Build
• Target Build
• Compatibility Matrix
• Maintenance Window
• ریسک Security Delay

را بررسی کنند.

وضعیت Dell VxRail، HPE SimpliVity و پلتفرم‌های مهندسی‌شده

اگر VMware روی یک Engineered System مثل:

• Dell EMC VxRail
• HPE SimpliVity
• یا سایر پلتفرم‌های Hyperconverged یکپارچه

اجرا می‌شود، Patch عمومی VMware را بدون تأیید Vendor روی Production نصب نکنید.

این پلتفرم‌ها معمولاً ترکیب تأییدشده‌ای از موارد زیر دارند:

• ESXi Image
• Driver
• Firmware
• Storage Stack
• Vendor Agent
• Management Component

Broadcom نیز در FAQ این VMSA صراحتاً اعلام کرده است که برای Third-party Engineered Systems باید Guidance همان Vendor و همان Product Version دنبال شود.

بنابراین برای VxRail یا SimpliVity:

1. فوراً Exposure و Build فعلی را مشخص کنید.
2. Vendor Advisory و Support Matrix را بررسی کنید.
3. در صورت نبود Bundle تأییدشده، با Vendor Support تماس بگیرید.
4. Patch عمومی VMware را بدون Qualification نصب نکنید.

تکلیف VMware vSphere ۷ چیست؟

VMware vSphere ۷ شامل ESXi ۷، vCenter ۷ و vSAN ۷ در ۲ اکتبر ۲۰۲۵ به پایان دوره General Support رسیده است.

Broadcom در FAQ VMSA-۲۰۲۶-۰۰۰۶ صراحتاً اعلام کرده که vSphere ۷ تحت تأثیر این مشکلات قرار دارد.

اگر سازمان Extended Support معتبر دارد، باید برای دریافت Patchهای مربوط به این CVEها از فرآیندهای همان قرارداد استفاده کند.

برای نسخه‌های قدیمی‌تر مانند vSphere ۶.۵ و ۶.۷ نیز Broadcom توصیه می‌کند آن‌ها را آسیب‌پذیر فرض کنید؛ زیرا محصولات خارج از General Support دیگر الزاماً در Advisoryهای جدید به‌طور کامل ارزیابی نمی‌شوند.

در چنین محیطی مشکل فقط VMSA-۲۰۲۶-۰۰۰۶ نیست. با یک پلتفرم End-of-Support روبه‌رو هستید که ریسک امنیتی آن به‌مرور انباشته می‌شود.

آیا زمان برنامه‌ریزی برای مهاجرت از VMware ۸ رسیده است؟

vSphere ۸ همچنان یک شاخه پشتیبانی‌شده و دارای Patchهای امنیتی فعال است؛ بنابراین این Advisory به معنی کنار گذاشتن فوری vSphere ۸ نیست.

اقدام درست برای یک محیط سالم vSphere ۸ این است:

1. ابتدا VMSA-۲۰۲۶-۰۰۰۶.۱ را با Patch مناسب برطرف کنید.
2. سپس برنامه Lifecycle نسخه ۸ را بررسی کنید.
3. سازگاری Hardware با VVF ۹.۱ یا VCF ۹.۱ را ارزیابی کنید.
4. مهاجرت را پیش از نزدیک شدن به پایان Support به پروژه‌ای برنامه‌ریزی‌شده تبدیل کنید.

اطلاعات فعلی چرخه پشتیبانی Broadcom برای شاخه vSphere/ESX ۸.۰، تاریخ ۱۱ اکتبر ۲۰۲۷ را به‌عنوان End of General Support نشان می‌دهد.

در زمان نگارش این مقاله، بیش از یک سال تا این تاریخ باقی مانده است؛ اما برای یک دیتاسنتر Enterprise این بازه الزاماً طولانی نیست.

مهاجرت ممکن است نیازمند بررسی موارد زیر باشد:

• CPU Compatibility
• Server Hardware
• Firmware
• NIC و HBA
• Storage
• vSAN
• Distributed Switch
• Backup
• Replication
• NSX
• Licensing
• انتخاب بین VVF و VCF

مقصد نهایی مهاجرت نیز نباید یک Base Release قدیمی و Patch‌نشده باشد. همیشه آخرین Build اصلاح‌شده و سازگار را بر اساس Lifecycle و Interoperability Matrix انتخاب کنید.

بعد از Patch چه چیزهایی باید بررسی شوند؟

اعلام Success در Lifecycle Manager به‌تنهایی برای بستن Change کافی نیست.

برای vCenter

• Build جدید را بررسی کنید.
• vSphere Client را تست کنید.
• vCenter Services را بررسی کنید.
• SSO Login را تست کنید.
• Backup Job را بررسی کنید.
• Certificateها را کنترل کنید.
• Monitoring و Alerting را بررسی کنید.
• Third-party Plug-inها را تست کنید.

برای ESX Host

• Version و Build را تأیید کنید.
• Host Connection State را بررسی کنید.
• Physical NIC و VMkernel NICها را کنترل کنید.
• Datastore Connectivity را بررسی کنید.
• vSAN Health را کنترل کنید.
• vMotion را تست کنید.
• HA و DRS را بررسی کنید.
• Hardware Sensor و Alarmها را کنترل کنید.
• Backup Agent و Monitoring Agent را بررسی کنید.

تأیید نهایی با PowerCLI

Get-VMHost |
Select-Object Name,Version,Build |
Sort-Object Name

خروجی را با Fixed Version مورد انتظار مقایسه و به Change Record پیوست کنید.

اگر احتمال Exploit وجود دارد، فقط Patch کردن کافی نیست

Patch جلوی سوءاستفاده بعدی از آسیب‌پذیری را می‌گیرد، اما اگر مهاجم پیش از Patch به محیط دسترسی پیدا کرده باشد، Update کردن به‌تنهایی آن دسترسی را حذف نمی‌کند.

اگر vCenter شما از شبکه‌ای غیرقابل اعتماد قابل دسترس بوده، نشانه غیرعادی دیده‌اید یا احتمال Compromise وجود دارد، علاوه بر Patch باید Incident Response انجام شود.

موارد پیشنهادی برای بررسی عبارت‌اند از:

• حساب‌های جدید یا غیرمنتظره vCenter
• تغییر Permission و Role
• SSO Configuration
• Administrator Loginهای غیرعادی
• Task و Eventهای غیرمنتظره
• SSH یا Shell Access روی Appliance و Hostها
• تغییر Firewall Ruleها
• تغییر Syslog Destination
• تغییر Network Configuration
• VMهای جدید یا Cloneهای غیرمنتظره
• تغییر Snapshotها
• Third-party Plug-inها و Integrationها

در صورت وجود شواهد معتبر Compromise، ممکن است لازم باشد Credentialهای مدیریتی، Service Accountها، API Tokenها و Secretهایی که vCenter یا سامانه‌های مدیریتی به آن‌ها دسترسی داشته‌اند نیز Rotate شوند.

وجود CVE-۲۰۲۶-۴۱۷۰۹ نیز یک نکته مهم در Forensics ایجاد می‌کند: بعضی عملیات مدیریتی ممکن است به‌درستی ثبت نشده باشند. بنابراین «نبود Log» به‌تنهایی نمی‌تواند اثبات کند که عملیاتی انجام نشده است.

یک برنامه عملیاتی پیشنهادی برای ۲۴ ساعت اول

سوالات متداول درباره VMSA-۲۰۲۶-۰۰۰۶.۱

VMSA-۲۰۲۶-۰۰۰۶.۱ چیست؟

یک VMware Security Advisory با سطح Critical است که پنج آسیب‌پذیری را در ESX، vCenter، Workstation و Fusion پوشش می‌دهد و محصولات مبتنی بر ESX/vCenter مانند VCF و VVF را نیز تحت تأثیر قرار می‌دهد.

خطرناک‌ترین آسیب‌پذیری‌های این Advisory کدام‌اند؟

CVE-۲۰۲۶-۵۹۳۰۹ و CVE-۲۰۲۶-۵۹۳۱۰ هر دو با CVSS ۹.۸ مربوط به vCenter هستند. CVE-۲۰۲۶-۴۷۸۷۶ نیز با امتیاز ۹.۳ امکان VM Escape در شرایط مشخص را ایجاد می‌کند.

آیا برای Exploit کردن vCenter نیاز به Username و Password است؟

طبق Attack Vector اعلام‌شده برای دو CVE بحرانی vCenter، مهاجم به حساب کاربری معتبر نیاز ندارد، اما باید دسترسی شبکه به vCenter داشته باشد.

آیا غیرفعال بودن Enhanced Linked Mode مشکل را برطرف می‌کند؟

خیر. Broadcom اعلام کرده این آسیب‌پذیری‌ها در خود vCenter هستند و به ELM وابسته نیستند.

اگر Integrated Windows Authentication استفاده نکنیم، امن هستیم؟

خیر. IWA و Active Directory Integration علت این Advisory نیستند و vCenter همچنان باید Patch شود.

آیا CVE-۲۰۲۶-۴۷۸۷۶ یک VM Escape واقعی است؟

بله. مهاجمی که داخل یک VM دارای VMXNET3 دسترسی Administrator یا Root داشته باشد ممکن است بتواند روی ESX Host کد اجرا کند.

آیا باید VMXNET3 را به E1000 تغییر دهیم؟

خیر. Broadcom این کار را به‌عنوان راهکار امنیتی عمومی توصیه نمی‌کند. راهکار اصلی Update کردن ESX است.

آیا آپدیت VMware Tools کافی است؟

خیر. CVE-۲۰۲۶-۴۷۸۷۶ در سمت ESX قرار دارد. آپدیت VMware Tools یا Virtual Hardware به‌تنهایی مشکل را برطرف نمی‌کند.

آیا Workaround رسمی وجود دارد؟

خیر. Broadcom برای این پنج آسیب‌پذیری Workaround رسمی ارائه نکرده است. Firewall و Network Segmentation فقط Compensating Control هستند.

آیا Exploit فعال مشاهده شده است؟

تا آخرین به‌روزرسانی FAQ رسمی در زمان نگارش مقاله، Broadcom اطلاعاتی مبنی بر Exploitation in the Wild اعلام نکرده است.

آیا VCF و VVF نیز تحت تأثیر هستند؟

بله، زیرا vCenter و ESX اجزای مشترک آن‌ها هستند. Build دقیق این اجزا باید با Response Matrix مقایسه شود.

آیا NSX تحت تأثیر است؟

خیر. Broadcom اعلام کرده NSX مستقیماً تحت تأثیر این VMSA نیست.

آیا VCF Operations و VCF Automation آسیب‌پذیر هستند؟

طبق FAQ رسمی، این دو Component مستقیماً تحت تأثیر VMSA-۲۰۲۶-۰۰۰۶ نیستند.

برای vSphere ۸ بهتر است U2f نصب شود یا U3k؟

در صورت سازگاری محیط، Update 3k یا نسخه جدیدتر انتخاب بهتر است؛ زیرا علاوه بر Critical CVEهای این Advisory، سایر Security Fixها و Bug Fixهای تجمعی را نیز شامل می‌شود. U2f بیشتر برای محیط‌هایی ارائه شده که فعلاً نمی‌توانند به U3 منتقل شوند.

آیا vCenter ۹.۱.۰.۰۲۰۰ برای CVE-۲۰۲۶-۵۹۳۰۹ اصلاح شده است؟

این CVE ابتدا در ۹.۱.۰.۰۲۰۰ اصلاح شد، اما Broadcom در Advisory فعلی، نسخه تجمعی جدیدتر 9.1.0.0300 را به‌عنوان Fixed Version فعلی vCenter ۹.۱ معرفی می‌کند.

آیا Update کردن vCenter باعث خاموش شدن VMها می‌شود؟

خیر. Workloadهای در حال اجرا روی Hostها ادامه می‌یابند، اما vSphere Client و Management Operations در طول Update موقتاً در دسترس نخواهند بود.

آیا ESX برای Patch شدن نیاز به Reboot دارد؟

در روش Update عادی بله. در بعضی نسخه‌ها و شرایط، Live Patch ممکن است قابل استفاده باشد. Eligibility باید در Release Notes همان Build بررسی شود.

آیا Patchهای این Advisory روی Migration به VCF ۹ اثر دارند؟

بله. Broadcom رسماً Back-in-Time Upgrade Restriction را برای برخی Patchهای vSphere ۸.۰ و ۹.۰ این Advisory تأیید کرده است. پیش از Migration باید Source و Target Build بررسی شوند.

در VxRail یا SimpliVity می‌توان Patch عمومی ESXi را نصب کرد؟

نباید بدون تأیید Vendor این کار را انجام دهید. این پلتفرم‌ها Stack تأییدشده اختصاصی دارند و Patch باید مطابق Guidance سازنده نصب شود.

vSphere ۷ چطور؟

vSphere ۷ تحت تأثیر است، اما General Support آن در ۲ اکتبر ۲۰۲۵ پایان یافته است. دریافت Fix برای این شاخه به وضعیت قرارداد Extended Support بستگی دارد.

جمع‌بندی

VMSA-2026-0006.1 یکی از مهم‌ترین هشدارهای امنیتی اخیر VMware است؛ نه فقط به دلیل سه CVE بحرانی، بلکه به دلیل محل قرار گرفتن آن‌ها در معماری زیرساخت.

دو آسیب‌پذیری vCenter با امتیاز ۹.۸ می‌توانند بدون حساب معتبر و از طریق دسترسی شبکه مورد سوءاستفاده قرار گیرند. CVE-۲۰۲۶-۴۷۸۷۶ نیز یک VM Escape واقعی است که در صورت Compromise شدن VM دارای VMXNET3، می‌تواند مرز Guest و Host را تحت تأثیر قرار دهد.

از سوی دیگر هیچ Workaround رسمی وجود ندارد. بنابراین Network Segmentation، VPN، Jump Host و Firewall هرچند ضروری هستند، جایگزین Patch محسوب نمی‌شوند.

اگر زیرساخت شما روی VMware اجرا می‌شود، ترتیب منطقی کار این است:

1. Buildها را Inventory کنید.
2. Management Plane را محدود کنید.
3. Backup معتبر تهیه کنید.
4. Compatibility را بررسی کنید.
5. Target Build مناسب را انتخاب کنید.
6. Patch را ابتدا در Pilot اجرا کنید.
7. Rollout کنترل‌شده انجام دهید.
8. Build و سلامت زیرساخت را پس از Update دوباره تأیید کنید.

اگر از VCF ۵.x، VxRail، SimpliVity یا محیطی در حال Migration به VCF ۹ استفاده می‌کنید، فرآیند Patch پیچیده‌تر است و باید حتماً Lifecycle Path، Vendor Guidance و محدودیت Back-in-Time را قبل از اجرا بررسی کنید.

در نهایت، نبود Exploit عمومی تا این لحظه نباید باعث تأخیر در Patch شود. خود Broadcom این Advisory را در سطح Emergency Change دسته‌بندی کرده است و برای یک زیرساخت مجازی‌سازی Enterprise، تصمیم قابل دفاع این است که ریسک را پیش از تبدیل شدن آسیب‌پذیری عمومی به Incident واقعی برطرف کنید.

برای آشنایی بیشتر با مفاهیم زیرساخت مجازی، می‌توانید مقاله سرور مجازی چیست؟ را مطالعه کنید. همچنین برای مشاهده سایر هشدارهای امنیتی مرتبط با زیرساخت، مقاله آسیب‌پذیری CVE-۲۰۲۶-۳۱۴۳۱ در Linux Kernel نیز مرتبط است.

برای زیرساخت‌هایی که نیازمند منابع اختصاصی‌تر هستند نیز می‌توانید سرویس‌های سرور مجازی و اختصاصی، VPS ایران و VPS آلمان پویاسازان را بررسی کنید.

منابع رسمی

• Broadcom Security Advisory VMSA-2026-0006.1
• Broadcom Supplemental FAQ for VMSA-2026-0006
• Broadcom KB 344935 / KB 88287 – VMware Cloud Foundation Async Patching
• Broadcom – Overview of Backup and Restore Options in vCenter Server
• Broadcom – End of General Support for VMware vSphere 7