اگر زیرساخت مجازیسازی سازمان شما بر پایه VMware ESXi، vCenter، VVF یا VCF اجرا میشود، بررسی این هشدار امنیتی را نباید به Maintenance Window بعدی موکول کنید.
Broadcom در Advisory امنیتی VMSA-2026-0006.1 پنج آسیبپذیری را در محصولات VMware اعلام کرده است که سه مورد از آنها در محدوده Critical قرار دارند. دو آسیبپذیری میتوانند به مهاجم دارای دسترسی شبکه به vCenter اجازه دورزدن احراز هویت یا اجرای کد بدهند. آسیبپذیری بحرانی دیگر نیز امکان خروج از ماشین مجازی و اجرای کد روی ESXi Host را فراهم میکند.
خطر اصلی اینجاست که برای این مجموعه آسیبپذیریهای VMware هیچ Workaround رسمی ارائه نشده است. محدودکردن شبکه مدیریت، کنترل دسترسی و سایر اقدامات امنیتی میتوانند احتمال حمله را کاهش دهند، اما مشکل را برطرف نمیکنند. راهکار اصلی، نصب نسخهها و Patchهای اصلاحشدهای است که Broadcom منتشر کرده است.
این هشدار فقط مختص یک محصول یا نسخه خاص نیست. VMware ESXi، vCenter، VMware vSphere Foundation یا VVF، VMware Cloud Foundation یا VCF، Workstation و Fusion در فهرست محصولات تحت تأثیر قرار دارند. بنابراین اگر زیرساخت شما روی VVF، VCF یا نسخههای مستقل vSphere اجرا میشود، باید وضعیت Buildهای فعلی را فوراً بررسی کنید.
Advisory رسمی Broadcom این مجموعه را با سطح کلی Critical و بازه امتیاز CVSS از ۲.۷ تا ۹.۸ منتشر کرده است.
چرا این آسیبپذیری VMware تا این اندازه جدی است؟
در بسیاری از حملات سایبری، مهاجم برای رسیدن از یک ماشین آلوده به لایه زیرساخت باید چندین کنترل امنیتی را پشت سر بگذارد. مجازیسازی قرار است میان ماشینهای مجازی و Hypervisor مرز مشخصی ایجاد کند تا نفوذ به یک VM بهمعنای نفوذ به کل Host نباشد.
آسیبپذیری CVE-2026-47876 همین مرز را هدف قرار میدهد.
اگر مهاجم داخل یک ماشین مجازی مجهز به کارت شبکه VMXNET3 به دسترسی Administrator یا Root برسد، ممکن است بتواند از محیط VM خارج شود و کد خود را روی ESXi Host اجرا کند. به این نوع حمله اصطلاحاً VM Escape گفته میشود.
این موضوع به آن معنا نیست که هر مهاجمی از اینترنت میتواند مستقیماً وارد ESXi شود. سوءاستفاده از این CVE به دسترسی مدیریتی داخل یک ماشین مجازی نیاز دارد. اما اگر یکی از سرورها در اثر سرقت رمز عبور، آسیبپذیری سیستمعامل، Web Shell، باجافزار یا خطای پیکربندی در اختیار مهاجم قرار گرفته باشد، مرحله بعدی حمله ممکن است دیگر به همان VM محدود نماند.
دسترسی به Host میتواند محرمانگی، یکپارچگی و دسترسپذیری ماشینهای مجازی دیگر را نیز در معرض خطر قرار دهد. به همین دلیل CVE-2026-47876 با امتیاز ۹.۳ در گروه آسیبپذیریهای بحرانی قرار گرفته است.
در کنار آن، دو آسیبپذیری vCenter با امتیاز ۹.۸ وجود دارد که برای سوءاستفاده به حساب کاربری معتبر نیاز ندارند. کافی است مهاجم بتواند از طریق شبکه به vCenter دسترسی داشته باشد. همین ترکیب باعث شده این Advisory یک هشدار معمولی برای Patch ماهانه نباشد و Broadcom رسیدگی به آن را در سطح Emergency Change توصیه کند.
آسیبپذیریهای VMSA-2026-0006 شامل چه مواردی هستند؟
دورزدن احراز هویت در vCenter
آسیبپذیری CVE-2026-59309 در VMware Directory Service قرار دارد و امتیاز CVSS آن ۹.۸ است.
مهاجمی که به vCenter دسترسی شبکهای داشته باشد، ممکن است بتواند احراز هویت را دور بزند و بدون داشتن مجوز لازم به سیستم دسترسی پیدا کند. این آسیبپذیری به Enhanced Linked Mode یا Integrated Windows Authentication محدود نیست و حتی در محیطهایی که از این قابلیتها استفاده نمیکنند نیز باید vCenter بهروزرسانی شود.
اجرای کد از طریق Syslog Server در vCenter
آسیبپذیری CVE-2026-59310 یک Directory Traversal در Syslog Server مربوط به vCenter است و امتیاز ۹.۸ دارد.
طبق توضیحات Broadcom، مهاجم دارای دسترسی شبکه به vCenter ممکن است از این ضعف برای اجرای کد دلخواه استفاده کند. این مورد نیز به حساب کاربری معتبر نیاز ندارد و برای آن Workaround رسمی اعلام نشده است.
وجود همزمان Authentication Bypass و امکان اجرای کد در یک سامانه مدیریتی مانند vCenter موضوعی نیست که بتوان آن را تا چرخه عادی Patch سازمان عقب انداخت.
خروج از ماشین مجازی از طریق VMXNET3
آسیبپذیری CVE-2026-47876 یک Out-of-Bounds Write در کارت شبکه مجازی VMXNET3 است و امتیاز ۹.۳ دارد.
برای سوءاستفاده از آن، مهاجم باید داخل یک ماشین مجازی که از VMXNET3 استفاده میکند، دسترسی Administrator یا Root داشته باشد. در این شرایط ممکن است بتواند روی ESXi Host کد اجرا کند.
ماشینهایی که از کارت شبکه مجازی دیگری استفاده میکنند، از این CVE مشخص تأثیر نمیپذیرند. بااینحال Broadcom تغییر VMXNET3 به E1000 را بهعنوان راهکار امنیتی توصیه نمیکند. کارتهای شبکه غیر Paravirtualized نیز در گذشته آسیبپذیریهای خود را داشتهاند و تعویض آنها میتواند باعث کاهش کارایی شود.
رفع صحیح مشکل، نصب Patch مربوط به ESXi است. بهروزرسانی VMware Tools یا Virtual Hardware بهتنهایی این آسیبپذیری را برطرف نمیکند.
افشای اطلاعات یا اختلال در Host Process
آسیبپذیری CVE-2026-41703 با امتیاز ۷.۶ در ESXi وجود دارد. مهاجمی که مجوز استقرار ماشین مجازی داشته باشد، ممکن است بتواند یک Out-of-Bounds Read ایجاد کند.
نتیجه احتمالی این حمله میتواند افشای اطلاعات یا ایجاد وضعیت Denial of Service در Host Process باشد. این مورد VM Escape محسوب نمیشود و به مهاجم امکان اجرای کد روی Host را نمیدهد، اما همچنان میتواند روی امنیت و دسترسپذیری زیرساخت اثر بگذارد.
ثبتنشدن بعضی عملیات مدیریتی ESXi
آسیبپذیری CVE-2026-41709 با امتیاز ۲.۷ به ضعف در ثبت رویدادهای ESXi مربوط است.
یک Administrator مخرب ممکن است بتواند بعضی عملیات را بدون ثبتشدن در Log انجام دهد. این ضعف بهتنهایی سطح خطر CVEهای بحرانی را ندارد، اما در زمان بررسی رخداد امنیتی، Incident Response و تحلیل رفتار مدیران اهمیت زیادی پیدا میکند.
آیا VVF و VCF نیز آسیبپذیر هستند؟
بله. آسیبپذیری VVF و آسیبپذیری VCF در این Advisory به اجزای مشترک آنها، یعنی vCenter و ESXi یا ESX مربوط است.
اگرچه VVF و VCF معماری و قابلیتهای متفاوتی دارند، هر دو از vCenter و ESX برای مدیریت و اجرای Workloadها استفاده میکنند. بنابراین نصب VVF 9 یا VCF 9 بهتنهایی به معنای مصونبودن محیط نیست. نسخه ۹.۰ و حتی Buildهای اولیه ۹.۱ نیز در فهرست نسخههای تحت تأثیر قرار دارند.
در مقابل، Broadcom اعلام کرده است که NSX، VCF Operations و VCF Automation مستقیماً تحت تأثیر این Advisory نیستند. تمرکز اصلی باید روی نسخه و Build مربوط به vCenter و ESX باشد.
برای آشنایی بیشتر با تفاوت معماری این دو پلتفرم میتوانید مقاله تفاوت VVF و VCF را مطالعه کنید.
کدام نسخهها باید بهروزرسانی شوند؟
نسخه اصلاحشده به شاخه محصول شما بستگی دارد:
| محصول و نسخه | نسخه اصلاحشده پیشنهادی |
|---|---|
| vCenter 9.1 | 9.1.0.0300 |
| ESX 9.1 | ESXi-9.1.0.0200-25557999 |
| vCenter 9.0 | 9.0.2.0100 |
| ESX 9.0 | ESXi-9.0.2.0100-25595025 |
| vCenter 8 Update 3 | 8.0 U3k |
| ESXi 8 Update 3 | ESXi80U3k-25595708 |
| vCenter 8 Update 2 | 8.0 U2f |
| ESXi 8 Update 2 | ESXi80U2f-25626445 |
| VMware Workstation 25H2 | 26H1 |
| VMware Fusion 25H2 | 26H1 |
در نسخه ۸ بهتر است در صورت سازگاری محیط، Update 3k بهعنوان مقصد انتخاب شود؛ زیرا یک Patch تجمعی است و علاوه بر این آسیبپذیریهای بحرانی، اصلاحات امنیتی و Bug Fixهای قبلی را نیز در بر میگیرد. Patch نسخه 8 Update 2 بیشتر برای سازمانهایی منتشر شده است که فعلاً امکان انتقال به Update 3 را ندارند.
برای محیطهای VCF 5.x باید از روش Asynchronous Patching و دستورالعمل رسمی همان نسخه استفاده شود. نصب مستقیم Patchهای عمومی vSphere بدون درنظرگرفتن فرآیند VCF میتواند وضعیت Lifecycle Management محیط را با مشکل مواجه کند.
نسخههای جدیدتر از موارد جدول نیز در صورتی که اصلاحات را بهصورت تجمعی شامل شوند، مشکل را برطرف میکنند. بااینحال پیش از هر اقدامی، Response Matrix آخرین نسخه Advisory را بررسی کنید.
چگونه نسخه ESXi و vCenter را بررسی کنیم؟
نسخه و Build مربوط به vCenter در Summary صفحه vSphere Client نمایش داده میشود.
برای بررسی vCenter با PowerCLI نیز میتوان پس از اتصال، Build و Version را از متغیرهای زیر مشاهده کرد:
$global:DefaultVIServer.Build
$global:DefaultVIServer.Version
برای مشاهده نسخه و Build تمام ESXi Hostها از دستور زیر استفاده کنید:
Get-VMHost | Select-Object Name,Version,Build
صرف دیدن عبارتهایی مانند ESXi 8 یا vCenter 9.1 کافی نیست. معیار اصلی، Update Level و Build Number است. ممکن است محیطی روی نسخه ۹.۱ باشد، اما هنوز Patch اصلاحکننده آسیبپذیری VMware را دریافت نکرده باشد.
آیا سوءاستفاده فعال از این آسیبپذیریها مشاهده شده است؟
Broadcom در FAQ رسمی اعلام کرده که تا زمان آخرین بهروزرسانی، اطلاعاتی مبنی بر بهرهبرداری عملی از این موارد در دنیای واقعی در اختیار ندارد.
این موضوع خبر مثبتی است، اما نباید با امنبودن محیط اشتباه گرفته شود. جزئیات CVEها اکنون عمومی شدهاند و فاصله بین افشای عمومی یک آسیبپذیری بحرانی و توسعه ابزارهای سوءاستفاده همیشه طولانی نیست.
در این مجموعه سه آسیبپذیری Critical، دو مورد بدون نیاز به احراز هویت و یک VM Escape وجود دارد. علاوه بر این، هیچ Workaround رسمی نیز ارائه نشده است. در چنین شرایطی منتظرماندن برای مشاهده اولین حمله ثبتشده، تصمیم قابل دفاعی برای یک زیرساخت مجازیسازی سازمانی نیست.
راهکار فوری برای کاهش خطر چیست؟
وضعیت vCenter و ESXi را همین امروز Inventory کنید
فهرست تمام vCenterها، Hostها، نسخهها، Buildها، کلاسترها و محیطهای VVF یا VCF را تهیه کنید. محیطهای آزمایشگاهی، DR Site و vCenterهای قدیمی را فراموش نکنید. بسیاری از رخدادهای امنیتی از سامانهای شروع میشوند که تیم تصور میکرد دیگر استفاده نمیشود.
دسترسی شبکه به Management Plane را محدود کنید
دسترسی مستقیم کاربران عادی، شبکه سرورها و اینترنت به vCenter و ESXi باید محدود باشد. مدیریت زیرساخت بهتر است از طریق شبکه مدیریتی جداگانه، Jump Server، VPN امن و Access Control مشخص انجام شود.
این اقدام جای Patch را نمیگیرد، اما سطح دسترسی مهاجم به دو آسیبپذیری بحرانی vCenter را کاهش میدهد.
از vCenter نسخه پشتیبان معتبر بگیرید
پیش از بهروزرسانی، از vCenter Server Appliance یک File-Based Backup سالم تهیه و امکان بازیابی آن را بررسی کنید. صرف داشتن Snapshot قدیمی یا Backup تأییدنشده برای یک عملیات اضطراری کافی نیست.
سازگاری اجزای زیرساخت را کنترل کنید
پیش از Patch، وضعیت ESXi، vCenter، vSAN، Firmware، Driver، Backup Solution، Replication، افزونهها و ابزارهای مانیتورینگ را در VMware Product Interoperability Matrix و Compatibility Guide بررسی کنید.
در محیطهای VCF نیز Patch باید مطابق روش Lifecycle Management همان نسخه انجام شود.
ابتدا یک Pilot کنترلشده انجام دهید
Patch را ابتدا روی یک Host یا کلاستر کمریسک آزمایش کنید. وضعیت vMotion، HA، vSAN Health، شبکه، Backup و Agentهای نصبشده را بررسی کنید و سپس عملیات را به سایر کلاسترها گسترش دهید.
برای Hostها از Rolling Update استفاده کنید
بهروزرسانی ESXi معمولاً به Restart شدن Host نیاز دارد. در کلاسترهایی که vMotion در دسترس است، ماشینها را تخلیه کنید، Host را وارد Maintenance Mode کنید، Patch را نصب کنید و پس از بررسی سلامت، سراغ Host بعدی بروید.
آپدیت vCenter باعث توقف ماشینهای مجازی در حال اجرا نمیشود، اما vSphere Client و عملیات مدیریتی برای مدتی در دسترس نخواهند بود.
برخی از Patchهای ESX این Advisory با Live Patch سازگار هستند؛ البته استفاده از آن به نسخه فعلی، وضعیت N-1، طراحی محیط و پشتیبانی سختافزار بستگی دارد.
هشدار مهم برای سازمانهایی که در حال مهاجرت به VCF 9 هستند
Patchهای منتشرشده برای vSphere 8 و نسخه ۹.۰ در این Advisory ممکن است هنگام ارتقا به VMware Cloud Foundation 9.x خطای Back-in-Time ایجاد کنند.
این وضعیت زمانی اتفاق میافتد که Build نصبشده روی محیط فعلی از Build موجود در مسیر ارتقای مقصد جدیدتر باشد. در چنین شرایطی، VCF Installer یا فرآیند Upgrade اجازه ادامه عملیات را نمیدهد تا یک نسخه مقصد سازگارتر منتشر شود.
این هشدار به معنای کنارگذاشتن Patch امنیتی نیست. سازمانی که همزمان در حال مهاجرت به VCF 9 است باید پیش از اجرا، Patch فعلی، Build مقصد، Interoperability Matrix و برنامه Upgrade را با دقت تطبیق دهد.
اگر پروژه مهاجرت هنوز شروع نشده است، آسیبپذیری فعلی را برطرف کنید و سپس مسیر مهاجرت را بر اساس Buildهای جدید طراحی کنید. اگر پروژه در میانه اجرا قرار دارد، تیم امنیت و تیم مهاجرت باید درباره زمانبندی تصمیم مشترک بگیرند.
وضعیت سیستمهای VxRail، SimpliVity و پلتفرمهای مهندسیشده
اگر VMware روی یک سیستم یکپارچه مانند Dell VxRail، HPE SimpliVity یا محصولات مشابه اجرا میشود، Patch عمومی ESXi یا vCenter را بدون تأیید سازنده نصب نکنید.
این پلتفرمها معمولاً Firmware، Driver، ESXi Image و ابزارهای مدیریتی اختصاصی دارند. نسخه اصلاحشده باید از مسیر تأییدشده همان Vendor دریافت و طبق Runbook رسمی نصب شود.
در چنین محیطهایی باید فوراً با سازنده یا تیم پشتیبانی تماس بگیرید، اما نباید بدون بررسی سازگاری، Patch عمومی VMware را مستقیماً روی زیرساخت عملیاتی اجرا کنید.
تکلیف VMware vSphere 7 چیست؟
پشتیبانی عمومی VMware vSphere 7، شامل ESXi 7، vCenter 7 و vSAN 7، در تاریخ ۲ اکتبر ۲۰۲۵ پایان یافته است.
Broadcom اعلام کرده است که vSphere 7 تحت تأثیر این مشکلات قرار دارد، اما دریافت Patch برای آن به داشتن قرارداد Extended Support و طیکردن فرآیندهای مربوط به آن بستگی دارد. نسخههای قدیمیتر مانند 6.5 و 6.7 نیز باید آسیبپذیر فرض شوند، زیرا محصولات خارج از دوره پشتیبانی در Advisoryهای جدید ارزیابی نمیشوند.
اگر هنوز بخشی از زیرساخت شما روی نسخه ۷ یا قدیمیتر اجرا میشود، موضوع دیگر صرفاً ارتقای قابلیتها نیست. شما با پلتفرمی روبهرو هستید که دریافت عادی Patchهای امنیتی آن متوقف شده و هر آسیبپذیری جدید میتواند ریسک انباشته محیط را افزایش دهد.
