Broadcom закрыла три критические уязвимости VMware vCenter и ESXi с обходом аутентификации

Коротко о главном

29 июля 2026 года Broadcom выпустила бюллетень безопасности VMSA-2026-0006, закрыв три критические уязвимости VMware vCenter Server и ESXi с оценками CVSS до 9.8. Две из них позволяют неаутентифицированному злоумышленнику с сетевым доступом к vCenter обойти проверку подлинности и выполнить код, а третья даёт побег из виртуальной машины на хост ESXi. Обходных решений (workaround) нет — единственная защита — установить обновления. На момент публикации признаков эксплуатации в реальных атаках и публичного PoC не зафиксировано.

Для команд, которые эксплуатируют собственную виртуализацию или размещают в ней клиентские нагрузки, это событие уровня «патчить немедленно»: захват vCenter означает контроль над всей плоскостью управления инфраструктурой — виртуальными машинами, данными и связанными сервисами. Пока эксплойта в дикой природе нет, но окно между раскрытием и первыми атаками на инфраструктуру VMware исторически короткое.

Если вы отвечаете за виртуализацию, разумно провести ИТ-аудит периметра и инвентаризацию версий, а при переносе нагрузок в защищённый контур — оценить миграцию в облако и усилить информационную безопасность. Ниже разбираем, что именно закрыла Broadcom и какие шаги предпринять в первую очередь.

Что именно закрыла Broadcom

Бюллетень VMSA-2026-0006 описывает три уязвимости. Первая, CVE-2026-59309 (CVSS 9.8), — обход аутентификации в службе каталога VMware Directory Service внутри vCenter: злоумышленник с сетевым доступом к серверу может обойти проверку подлинности и получить несанкционированный доступ к плоскости управления. Вторая, CVE-2026-59310 (CVSS 9.8), — уязвимость обхода каталога (directory traversal) в компоненте vCenter Syslog server, позволяющая выполнить произвольный код. В связке эти две проблемы дают неаутентифицированное удалённое выполнение кода против уязвимого vCenter Server.

Третья уязвимость, CVE-2026-47876 (CVSS 9.3), — запись за пределами буфера (out-of-bounds write) в виртуальном сетевом адаптере VMXNET3. Она относится к классу «побег из виртуальной машины»: злоумышленник, уже имеющий локальные административные привилегии внутри гостевой ВМ, может выполнить код на хосте ESXi. Это разрушает границу изоляции между виртуальной машиной и гипервизором — особенно опасно в мультитенантных средах, где на одном хосте соседствуют нагрузки разных клиентов или подразделений.

Кто в зоне риска и какие версии обновлять

Уязвимости затрагивают широко распространённые ветки VMware. По данным бюллетеня, для vCenter это версия 8.0, а также vCenter в составе VMware Cloud Foundation и vSphere Foundation веток 9.0.x.x и 9.1.x.x. Побег из ВМ через VMXNET3 актуален для VMware ESX/ESXi версий 8.0, 9.0.2 и 9.1.0.

Broadcom указывает исправленные версии: vCenter 8.0 — до 8.0 U3k; vCenter в составе Cloud Foundation/vSphere Foundation 9.0.x.x — до 9.0.2.0100; ветка 9.1.x.x — до 9.1.0.0300. Компания прямо предупреждает: организациям, работающим на релизах старше указанных как исправленные, следует считать себя уязвимыми и действовать немедленно. Обходных мер вендор не предлагает, поэтому обновление — единственный путь закрытия.

Почему vCenter — критичная цель

vCenter Server — это централизованная точка управления виртуальной инфраструктурой VMware. Компрометация vCenter обычно означает не единичный взлом, а контроль над всей средой: злоумышленник может создавать и клонировать ВМ, менять сети, вытягивать данные и разворачивать вредоносное ПО на десятках и сотнях виртуальных машин. Именно поэтому платформы VMware в последние годы стали приоритетной мишенью для операторов вирусов-вымогателей — доступ к гипервизору позволяет зашифровать сразу весь парк ВМ.

Уязвимости, не требующие аутентификации и доступные по сети, — самый опасный сценарий: атакующему не нужны учётные данные, достаточно сетевой видимости vCenter. Если управляющий интерфейс доступен из недоверенных сегментов или, тем более, из интернета, риск максимален. Первый защитный слой до и после патча — жёсткая сетевая сегментация плоскости управления и ограничение доступа к vCenter и ESXi только доверенными административными сетями.

Что это значит для команд разработки и инфраструктуры

Для CTO и инженеров инфраструктуры сообщение простое: инвентаризируйте все установки vCenter и ESXi, сверьте версии с исправленными и запланируйте установку патчей как экстренное изменение. Если у вас есть окна обслуживания — уплотните их; отсутствие эксплойта сегодня не гарантирует его отсутствия завтра, а работа по устранению одинакова вне зависимости от того, атакуют вас уже или ещё нет.

Параллельно стоит проверить архитектуру доступа. Управляющие интерфейсы виртуализации не должны быть доступны из общих корпоративных сетей и тем более из интернета; доступ к ним — только через выделенные административные подсети и защищённые каналы. Полезно включить мониторинг аномальной активности vCenter, ограничить и регулярно ротировать административные учётные записи и вести журналирование действий на плоскости управления. Эти меры снижают ущерб не только от текущих CVE, но и от будущих уязвимостей той же поверхности.

Компаниям, у которых нет собственной команды для быстрого реагирования, разумно закрепить ответственность за виртуализацию и подключить внешнюю экспертизу по информационной безопасности и сопровождению инфраструктуры. Регулярный аудит поверхности атаки и дисциплина обновлений превращают такие бюллетени из аврала в плановую операцию — подробнее об этом мы писали в материале о том, зачем проводить аудит ИТ-инфраструктуры.

Часто задаваемые вопросы

Эксплуатируются ли уязвимости в реальных атаках? На момент публикации бюллетеня VMSA-2026-0006 Broadcom не сообщала о случаях эксплуатации в дикой природе и о публичном PoC. Однако вендор классифицирует проблемы как критические и рекомендует немедленное обновление, поскольку окно до появления рабочих эксплойтов на популярные продукты VMware обычно невелико.

Есть ли обходные меры без обновления? Нет. Broadcom прямо указывает, что workaround для этих уязвимостей отсутствует, и единственная защита — установка исправленных версий. До установки патчей стоит максимально ограничить сетевой доступ к vCenter и ESXi.

Какие версии считаются исправленными? vCenter 8.0 — 8.0 U3k; vCenter в составе Cloud Foundation/vSphere Foundation ветки 9.0.x.x — 9.0.2.0100; ветки 9.1.x.x — 9.1.0.0300. Всё, что старше этих релизов, следует считать уязвимым.

Насколько опасен побег из виртуальной машины? CVE-2026-47876 требует локальных прав администратора внутри ВМ, но при их наличии позволяет выполнить код на хосте ESXi, разрушая изоляцию между гостевой машиной и гипервизором. В мультитенантных средах это критично, так как компрометация одной ВМ ставит под угрозу соседние нагрузки на том же хосте.

Источники

Broadcom — VMSA-2026-0006: VMware vCenter Server and ESX updates address critical vulnerabilities, 29 июля 2026 года (первоисточник).

Rapid7 — Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution (CVE-2026-59309, CVE-2026-59310), 2026.

BleepingComputer — VMware fixes three critical flaws allowing auth bypass, VM escapes, 2026.

The Hacker News — Three Critical VMware Flaws Allow Auth Bypass, Code Execution, and VM Escape, 2026.