آسیب‌پذیری CVE-2026-47876 در VMXNET3 و خطر اجرای کد روی میزبان ESXi
تاریخ انتشار: ۲۴ مرداد ۱۴۰۵

آسیب‌پذیری CVE-2026-47876 در VMware؛ امکان فرار از VM و اجرای کد روی ESXi 

Broadcom در ۲۹ ژوئیه ۲۰۲۶ بولتن امنیتی VMSA-2026-0006 را منتشر و در ۳ اوت آن را به نسخه VMSA-2026-0006.1 به‌روزرسانی کرد.
یکی از مهم‌ترین موارد این بولتن برای مدیران زیرساخت، آسیب‌پذیری‌ CVE-2026-47876 در آداپتور شبکه مجازی VMXNET3 است. این آسیب‌پذیری VMware ESXi امتیاز ۹.۳ از ۱۰ در معیار CVSS دارد و در سطح بحرانی یا Critical طبقه‌بندی شده است.
مهاجمی که پیش‌تر در یک ماشین مجازی دارای VMXNET3 به سطح دسترسی Administrator یا root رسیده باشد، می‌تواند با بهره‌برداری موفق از این آسیب‌پذیری، روی میزبان ESX/ESXi کد اجرا کند. Broadcom این سناریو را «فرار از ماشین مجازی» یا VM Escape می‌داند.
بنابراین، متصل‌ نبودن ESXi به اینترنت به‌تنهایی این ریسک را برطرف نمی‌کند. نقطه آغاز حمله می‌تواند یک ماشین مجازی متصل به اینترنت یا قابل‌دسترسی از طریق شبکه سازمان باشد؛ سپس مهاجم از داخل همان VM، مرز میان سیستم‌عامل مهمان و هایپروایزر را هدف قرار دهد.

راهنمای مطالعه

آیا زیرساخت VMware شما تحت تاثیر است؟ 
نسخه و Build دقیق ESXi تعیین می‌کند که نصب Patch یا ارتقا ضروری است.

مشاهده نسخه‌ها و Buildهای اصلاح شده

این آسیب‌پذیری چگونه ESXi را تهدید می‌کند؟

در این ویدئو امیر فولادوند مدیر فناوری و اطلاعات پردیسکو نحوه اثرگذاری CVE-2026-47876 و اقدامات ضروری برای تیم‌های زیرساخت را توضیح می‌دهد.

برای رفع CVE-2026-47876 باید ESX/ESXi را به نسخه اصلاح‌شده ارتقا داد. همچنین، به دلیل وجود دو آسیب‌پذیری بحرانی دیگر در همین بولتن، نسخه vCenter نیز باید جداگانه بررسی و اصلاح شود. هیچ راهکار موقت رسمی برای آسیب‌پذیری‌های این بولتن اعلام نشده است.
اگر همچنان از VMware vSphere 6 یا 7 استفاده می‌کنید، لازم است علاوه بر اقدام امنیتی فوری، مسیر مهاجرت از نسخه خارج‌شده از پشتیبانی را مشخص کنید. vSphere 7 از دوره پشتیبانی عمومی خارج شده و Broadcom آن را متأثر از این آسیب‌پذیری می‌داند. نسخه‌های vSphere 6.5 و 6.7 به دلیل پایان پشتیبانی در Response Matrix عمومی این بولتن فهرست نشده‌اند. نبود نام این نسخه‌ها را نباید نشانه ایمن‌بودن آن‌ها دانست؛ تا زمان مهاجرت یا دریافت ارزیابی رسمی، بهتر است در مدیریت ریسک بالقوه متأثر در نظر گرفته شوند.
در انتخاب مقصد مهاجرت، چرخه عمر هر نسخه نیز باید بررسی شود. پشتیبانی عمومی vSphere 8 در ۱۱ اکتبر ۲۰۲۷ پایان می‌یابد؛ بنابراین، ارتقا به آخرین نسخه اصلاح‌شده این شاخه ممکن است برای برخی سازمان‌ها تنها یک راهکار موقت باشد، نه مقصد نهایی زیرساخت.
تصمیم میان vSphere 8، نسل 9 یا یک پلتفرم جایگزین باید پس از ارزیابی سازگاری سخت‌افزار، معماری، مجوزها و الزامات عملیاتی گرفته شود.

خلاصه هشدار امنیتی

مشخصه وضعیت
شناسه CVE-2026-47876
بولتن VMSA-2026-0006.1
شدت Critical
امتیاز CVSS v3.1 9.3 از 10
مؤلفه آسیب‌پذیر VMXNET3 در سمت ESX/ESXi Host
نوع آسیب‌پذیری Out-of-Bounds Write
پیش‌نیاز حمله دسترسی مدیریتی محلی داخل یک VM دارای VMXNET3
پیامد اجرای کد روی ESX/ESXi Host یا VM Escape
Workaround رسمی وجود ندارد
اقدام اصلی نصب Patch یا نسخه اصلاح‌شده ESX/ESXi
وضعیت اعلام‌شده بهره‌برداری فعال تا ۱5 اوت ۲۰۲۶، در بولتن Broadcom اشاره‌ای به بهره‌برداری فعال نشده است.

مرجع قطعی این اطلاعات، بولتن رسمی VMSA-2026-0006.1 شرکت Broadcom است.

CVE-2026-47876 چیست و چگونه عمل می‌کند؟

VMXNET3 آداپتور شبکه پارامجازی‌سازی‌شده (Paravirtualized) شرکت VMware است. این آداپتور به دلیل کارایی بالا و سربار کمتر، در بسیاری از ماشین‌های مجازی سازمانی به کار می‌رود. بخشی از ارتباط آن در سیستم‌عامل مهمان و بخشی دیگر در سمت هایپروایزر پردازش می‌شود.
آسیب‌پذیری VMXNET3 با شناسه CVE-2026-47876 به نحوه پردازش برخی ورودی‌ها در سمت میزبان مربوط است و می‌تواند باعث نوشتن خارج از محدوده مجاز حافظه شود. مهاجم دارای دسترسی مدیریتی داخل VM می‌تواند با ارسال ورودی‌های دست‌کاری‌شده به VMXNET3، این ضعف را تحریک کند و در صورت بهره‌برداری موفق، روی Host کد اجرا کند.
Broadcom امکان اجرای کد روی میزبان را تأیید کرده است؛ پیامدی که از نظر فنی می‌توان آن را در دسته فرار از ماشین مجازی یا VM Escape قرار داد.

نحوه فرار مهاجم از ماشین مجازی به میزبان ESXi از طریق VMXNET3

دسترسی بعدی به سایر VMها، Datastoreها یا سرویس‌های حیاتی، پیامدی بالقوه از تصاحب میزبان است؛ اما تحقق آن به سطح دسترسی به‌دست‌آمده، معماری محیط و کنترل‌های امنیتی سازمان وابسته است. آنچه Broadcom مستقیماً تأیید کرده، امکان اجرای کد روی میزبان است.

چرا ESXi بدون دسترسی اینترنت نیز در معرض خطر است؟

CVE-2026-47876 یک آسیب‌پذیری اجرای کد از راه دور، بدون احراز هویت و مستقیماً از اینترنت به ESXi نیست. مهاجم ابتدا باید در یک VM دارای VMXNET3 به دسترسی مدیریتی برسد. بااین‌حال، در یک مرکز داده واقعی، مسیرهای متعددی می‌توانند به تصاحب اولیه ماشین مجازی منجر شوند:

  • وب‌سرورها و APIهای متصل به اینترنت
  • VPN، سرور ایمیل و درگاه‌های دسترسی از راه دور
  • سرویس‌های قابل دسترسی از شبکه کاربران یا شعب
  • محیط‌های Dev/Test و ماشین‌های تحت مدیریت پیمانکاران
  • حساب‌های RDP یا SSH سرقت‌شده
  • سیستم‌عامل‌ها یا نرم‌افزارهای دارای آسیب‌پذیری اجرای کد
  • VMهای آلوده به بدافزار یا تحت کنترل مهاجم داخلی
مسیر حمله از ماشین مجازی آلوده به میزبان ESXi بدون دسترسی مستقیم به اینترنت

پس از دستیابی مهاجم به Administrator یا root داخل VM، اتصال اینترنتی ESXi برای ادامه این زنجیره لازم نیست. ارتباط ماشین مجازی با دستگاه مجازی بخشی از عملکرد طبیعی بستر مجازی‌سازی است و حمله از همان مرز میان مهمان و میزبان انجام می‌شود.
در نتیجه، قطع دسترسی مستقیم ESXi به اینترنت همچنان یک کنترل امنیتی ضروری است، اما جای نصب نسخه اصلاح‌شده را نمی‌گیرد.

نسخه اصلاح‌شده ESXi برای CVE-2026-47876 کدام است؟

Broadcom نسخه‌های اصلاح‌شده زیر را در Response Matrix بولتن اعلام کرده است. از آنجا که Patchها تجمیعی‌اند، نسخه‌های جدیدتر همان شاخه نیز این اصلاحات را در بر دارند.

نسخه فعلی وضعیت و نسخه اصلاح‌شده Build
ESX 9.1.x ارتقا به ESX/ESXi 9.1.0.0200 یا نسخه جدیدتر اصلاح‌شده 25557999
ESX 9.0.x ارتقا به ESX/ESXi 9.0.2.0100 یا نسخه جدیدتر اصلاح‌شده 25595025
ESXi 8.0 Update 3 ارتقا به ESXi 8.0 Update 3k یا نسخه جدیدتر اصلاح‌شده 25595708
ESXi 8.0 Update 2 ارتقا به ESXi 8.0 Update 2f 25626445
vSphere 7 آسیب‌پذیر و خارج از پشتیبانی عمومی؛ Patch فقط از مسیر Extended Support، در صورت داشتن قرارداد معتبر —
vSphere 6.5 و 6.7 خارج از پشتیبانی؛ باید آسیب‌پذیر فرض شوند و Patch عمومی اعلام نشده است —

Broadcom شاخه vSphere 8 Update 3 را نسخه ترجیحی برای ادامه استفاده از vSphere 8 می‌داند و به‌روزرسانی‌های امنیتی جدید را بر مبنای آن می‌سازد. نسخه U2f فقط CVEهای بحرانی همین بولتن را برای شاخه Update 2 برطرف می‌کند. بنابراین، اگر سازگاری زیرساخت اجازه می‌دهد، U3k یا نسخه جدیدتر همان شاخه مقصد کامل‌تری برای اصلاح امنیتی و دریافت رفع اشکال‌های تجمیعی است.
طبق (فهرست رسمی نسخه‌ها و Buildهای VMware ESX/ESXi)، نسخه ESXi 9.1.0.0200 با Build 25557999 در ۱۳ ژوئیه ۲۰۲۶ منتشر شده است. بولتن این CVE در ۲۹ ژوئیه انتشار یافت. این فاصله زمانی به‌خودی‌خود نشان‌دهنده افشای عمومی جزئیات آسیب‌پذیری پیش از بولتن نیست و نباید از آن نتیجه امنیتی مستقلی گرفت.

مشاوره تخصصی VMware

برای ارتقای VMware نیاز به بررسی دارید؟
اگر از نسخه‌های قدیمی vSphere یا Buildهای آسیب‌پذیر ESXi استفاده می‌کنید، کارشناسان پردیسکو می‌توانند وضعیت فعلی و مسیر مناسب اصلاح، ارتقا یا مهاجرت را بررسی کنند.

درخواست بررسی زیرساخت VMware

برای هر نسخه از vSphere چه اقدامی لازم است؟

برای هر نسخه از vSphere چه اقدامی لازم است؟

چرا تغییر VMXNET3 جایگزین به‌روزرسانی امنیتی نیست؟

اگرچه آداپتورهای غیر VMXNET3 از این CVE مشخص تأثیر نمی‌پذیرند، Broadcom تغییر نوع آداپتور را به‌عنوان Workaround رسمی اعلام نکرده است. این تغییر نیز ممکن است بر سازگاری، تنظیمات شبکه و دسترس‌پذیری سرویس اثر بگذارد؛ بنابراین جایگزین نصب نسخه اصلاح‌شده نیست.

تغییر آداپتور VMXNET3 جایگزین نصب وصله امنیتی ESXi نیست

تغییر نوع کارت شبکه مجازی می‌تواند بر Driver، نام Interface ،MAC Address، تنظیمات شبکه، کارایی و دسترس‌پذیری سرویس اثر بگذارد. آداپتورهای دیگر نیز ممکن است آسیب‌پذیری‌های مختص خود را داشته باشند. اقدام اصلی و قابل‌اتکا، نصب Patch امنیتی VMware و ارتقای میزبان ESXi به نسخه اصلاح‌شده است.
به‌روزرسانی VMware Tools یا Virtual Hardware نیز به‌تنهایی این CVE را برطرف نمی‌کند؛ زیرا ضعف امنیتی در سمت میزبان قرار دارد.

به‌روزرسانی امنیتی vCenter برای آسیب‌پذیری‌های بحرانی

اگرچه تمرکز این مقاله بر ESXi است، بولتن VMSA-2026-0006 دو آسیب‌پذیری بحرانی دیگر را نیز در vCenter برطرف می‌کند:

  • CVE-2026-59309:
    دورزدن احراز هویت در VMware Directory Service
  • CVE-2026-59310:
    پیمایش مسیر (Directory Traversal) در Syslog Server با امکان اجرای کد دلخواه
آسیب‌پذیری‌های بحرانی CVE-2026-59309 و CVE-2026-59310 در VMware vCenter

بنابراین، برنامه پاسخ به بولتن VMSA-2026-0006.1 نباید به ESXi محدود شود. نسخه فعلی را بررسی و به‌روزرسانی امنیتی vCenter را مطابق آخرین Response Matrix اجرا کنید.

برنامه اقدام فوری برای تیم زیرساخت

در vSphere Client، نسخه و Build در بخش Summary هر میزبان قابل مشاهده است. در ESXi Shell نیز می‌توان از فرمان زیر استفاده کرد:

vmware -v

برای Inventory گروهی با PowerCLI:

Get-VMHost | Select-Object Name, Version, Build
Get-VM | Get-NetworkAdapter |
    Where-Object { $_.Type -eq "Vmxnet3" } |
    Select-Object @{Name="VM";Expression={$_.Parent.Name}}, Name, Type, NetworkName

این فهرست برای تعیین اولویت مفید است، اما جای به‌روزرسانی میزبان را نمی‌گیرد. VMهای خاموش و Templateها را نیز در فهرست موجودی بررسی کنید.

در اولویت‌بندی اصلاح، به میزبان‌ها و کلاسترهایی توجه بیشتری داشته باشید که موارد زیر را اجرا می‌کنند:

  • VMهای متصل به اینترنت یا مستقر در DMZ
  • ماشین‌های تحت مدیریت پیمانکار یا Tenant
  • محیط‌های Dev/Test و آزمون امنیت
  • Domain Controller ،Database و Backup Server
  • VMهایی با چندین کاربر دارای دسترسی Administrator یا root

Broadcom این مجموعه آسیب‌پذیری‌ها را براساس روش‌های ITIL واجد شرایط Emergency Change می‌داند؛ بااین‌حال، زمان‌بندی دقیق باید با ارزیابی تیم امنیت اطلاعات و شرایط عملیاتی سازمان تعیین شود.
در کلاسترهای دارای vMotion، می‌توان پس از آزمون و تأیید پیش‌نیازها، میزبان‌ها را به‌صورت مرحله‌ای اصلاح کرد. پیش از اجرا، سازگاری Server ،CPU ،Firmware ،NIC/HBA ،Storage ،vSAN ،NSX ،Backup و Monitoring را بررسی کنید.
در راهکارهای یکپارچه مانند Dell VxRail و HPE SimpliVity، از بسته و مسیر به‌روزرسانی تأییدشده سازنده استفاده کنید تا سازگاری اجزای راهکار حفظ شود.

نسخه دقیق vCenter و ESXi و ترتیب به‌روزرسانی مؤلفه‌های وابسته را در VMware Product Interoperability Matrix بررسی کنید. وجود دو CVE بحرانی vCenter در همین بولتن به این معناست که اصلاح میزبان‌ها نباید باعث نادیده‌گرفتن vCenter شود.

در ESXi 8.0 U3k ممکن است Installer یا مراحل ابتدایی Boot شماره Build قبلی را نمایش دهد. پس از Boot کامل، خروجی vmware -v، بخش DCUI یا vSphere Client باید Build 25595708 را گزارش کند. Broadcom این تفاوت نمایش را ظاهری و بدون اثر بر وضعیت امنیتی نسخه اصلاح‌شده دانسته است. جزئیات در (توضیح رسمی Broadcom درباره Build نسخه U3k) آمده است.
نکته مهم پیش از به‌روزرسانی: براساس پرسش‌وپاسخ رسمی Broadcom، بعضی Patchهای این بولتن برای vSphere 8 و نسخه 9.0 ممکن است به دلیل بالاتر بودن شماره Build، ارتقای بعدی به VMware Cloud Foundation 9.x را موقتاً با محدودیت Back-in-Time مواجه کنند. سازمان‌هایی که در میانه پروژه ارتقا به VCF 9 هستند، باید پیش از نصب Patch، مسیر ارتقا و نسخه مقصد را بررسی کنند. این نکته به معنی تعویق خودکار اصلاح امنیتی نیست و تصمیم نهایی باید با ارزیابی هم‌زمان ریسک امنیتی و برنامه ارتقا گرفته شود.

اگر فعلاً امکان Patch نداریم چه کنیم؟

اقدامات زیر می‌توانند تا زمان اجرای تغییر، احتمال تصاحب VM یا گسترش حمله را کاهش دهند؛ اما هیچ‌کدام راهکار موقت رسمی یا جایگزین نصب نسخه اصلاح‌شده نیستند:

کنترل‌های امنیتی جبرانی تا زمان نصب وصله CVE-2026-47876
  • محدود کردن دسترسی Administrator یا root داخل VMها
  • حذف حساب‌های مشترک و بازبینی دسترسی پیمانکاران
  • تقویت EDR و پایش امنیتی روی VMهای متصل به اینترنت
  • جداسازی بارهای کاری اینترنتی از کلاسترهای حیاتی
  • مسدود کردن ارتباط غیرضروری VMهای DMZ با شبکه‌های Management ،Backup و Storage
  • انتقال موقت VMهای پرریسک به میزبان‌های اصلاح‌شده
  • ثبت رسمی پذیرش ریسک همراه با مسئول مشخص و تاریخ قطعی اصلاح

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

آیا این آسیب‌پذیری در حملات واقعی استفاده شده است؟

تا تاریخ آخرین بازبینی این مقاله، Broadcom اطلاعاتی در تأیید بهره‌برداری از آسیب‌پذیری‌های این بولتن در دنیای واقعی اعلام نکرده است. این وضعیت به معنی نبود خطر یا امکان تعویق نامحدود اصلاح نیست. پس از انتشار Patch، تحلیل تفاوت میان نسخه آسیب‌پذیر و اصلاح‌شده آسان‌تر می‌شود و نبود راهکار موقت رسمی نیز دامنه گزینه‌های دفاعی را محدود می‌کند.
CVE-2026-47876 به‌صورت خصوصی و در ارتباط با Pwn2Own به Broadcom گزارش شده است. (پرسش‌وپاسخ رسمی VMware) نیز از سازمان‌ها می‌خواهد این موارد را به‌عنوان تغییر اضطراری ارزیابی و نسخه‌های اصلاح‌شده را نصب کنند.

وضعیت بهره‌برداری از آسیب‌پذیری CVE-2026-47876 در حملات واقعی

جمع‌بندی: چرا به‌روزرسانی امنیتی ESXi ضروری است؟

CVE-2026-47876 نشان می‌دهد که امنیت ESXi فقط به محدود کردن دسترسی اینترنتی آن وابسته نیست. مهاجم می‌تواند ابتدا یک VM را تصاحب کند، در آن به Administrator یا root برسد و سپس از ضعف VMXNET3 برای اجرای کد روی میزبان ESX/ESXi استفاده کند.
اگر از vSphere 8 استفاده می‌کنید، Build دقیق میزبان‌ها را بررسی و ESXi را دست‌کم به 8.0 Update 3k ،8.0 Update 2f یا نسخه جدیدتر اصلاح‌شده در همان شاخه ارتقا دهید. vCenter را نیز به دلیل وجود دو آسیب‌پذیری با امتیاز 9.8، مطابق آخرین Response Matrix اصلاح کنید.
اگر هنوز vSphere 6 یا 7 دارید، اصلاح این بولتن را از برنامه مهاجرت بلندمدت جدا نکنید. برای نسخه 7، مسیر Extended Support یا مهاجرت به یک نسخه اصلاح‌شده را بررسی کنید. برای نسخه‌های 6.5 و 6.7 نیز با فرض تأثیرپذیری، انتقال به یک پلتفرم پشتیبانی‌شده را در اولویت قرار دهید.
پرسش تصمیم‌ساز این است: اگر یکی از VMهای سازمان تصاحب شود، آیا هایپروایزر برای جلوگیری از عبور مهاجم از مهمان به میزبان، به نسخه اصلاح‌شده ارتقا یافته است؟

سوالات متداول

  • آیا ESXi بدون اتصال اینترنت نیز آسیب‌پذیر است؟
    بله. مهاجم پس از دسترسی مدیریتی به یکی از ماشین‌های مجازی مجهز به VMXNET3 می‌تواند از این آسیب‌پذیری سوءاستفاده کند؛ بنابراین قطع اینترنت به‌تنهایی مانع حمله نمی‌شود.
  • آیا تغییر VMXNET3 به E1000 مشکل را برطرف می‌کند؟
    خیر. این تغییر فقط سطح خطر را به‌صورت موقت کاهش می‌دهد و جایگزین نصب به‌روزرسانی امنیتی ESXi نیست.
  • آیا به‌روزرسانی VMware Tools کافی است؟
    خیر. آسیب‌پذیری CVE-2026-47876 در ESXi و نحوه پردازش آداپتور VMXNET3 قرار دارد؛ بنابراین باید خود ESXi به‌روزرسانی شود.
  • کدام نسخه ESXi این آسیب‌پذیری را برطرف می‌کند؟
    نسخه‌های اصلاح‌شده شامل ESXi 9.1.0.0200 ،ESXi 9.0.2.0100 ،ESXi 8.0 U3k و ESXi 8.0 U2f هستند.
  • آیا vCenter نیز باید به‌روزرسانی شود؟
    برای رفع CVE-2026-47876، به‌روزرسانی ESXi ضروری است. بااین‌حال، به‌دلیل وجود آسیب‌پذیری‌های جداگانه و بحرانی vCenter در همان هشدار امنیتی، vCenter نیز باید به نسخه اصلاح‌شده ارتقا یابد.
5/5 - (12 رای)
پیمایش به بالا