Broadcom предупредил о трех критических уязвимостях в продуктах VMware, включая vCenter и ESXi. Для администраторов это не абстрактная история про «безопасность вообще»: две бреши позволяют обойти аутентификацию и выполнить код удаленно, а третья открывает путь к атаке из гостевой системы на хост.
Риск в том, что речь идет о базовых компонентах виртуальной инфраструктуры. Если компания держит на VMware внутренние сервисы, тестовые среды или клиентские системы, откладывать обновление здесь плохая идея.
Какие CVE затрагивают инфраструктуру VMware
Первая уязвимость, CVE-2026-59309, получила оценку CVSS 9.8. По описанию Broadcom, злоумышленник с сетевым доступом может использовать ее для обхода аутентификации в vCenter.
Вторая, CVE-2026-59310, тоже имеет CVSS 9.8 и затрагивает vCenter. Она позволяет выполнить произвольный код. В исходном тексте это было описано неуклюже как «уязвимость каталога», но для читателя важнее практический смысл: при успешной эксплуатации атакующий получает контроль над системой.
Третья проблема, CVE-2026-47876 с оценкой CVSS 9.3, связана с виртуальным сетевым адаптером VMXNET3 в VMware ESXi. Здесь сценарий другой: атакующий с правами администратора внутри виртуальной машины может попытаться выполнить код уже на хосте. Это уже история не про вход в периметр, а про выход из виртуальной машины.
Патчи уже доступны, но окно риска еще открыто
Broadcom сообщил, что выпустил исправления для затронутых продуктов. В тексте компании отдельно упомянуты патчи для VMware Cloud Foundation и vSphere Foundation; точные затронутые версии и исправленные сборки нужно сверять по матрице обновлений в advisory.
При этом в Broadcom заявили, что не видят подтвержденных случаев эксплуатации этих уязвимостей в реальных атаках. Хорошая новость, но не повод расслабляться: такие бреши редко остаются «тихими» надолго после публикации технических деталей.
Что это меняет для российских компаний
Для российских команд, которые продолжают поддерживать инфраструктуру на VMware, новость предельно прикладная: нужно проверить доступность vCenter из внутренних и внешних сегментов, сверить версии ESXi и vCenter с advisory и поставить обновления по приоритету. Особенно это касается крупных инсталляций, где одна уязвимость в плоскости управления может потянуть за собой весь кластер.
На практике это еще один аргумент в пользу жесткой сегментации доступа к системам виртуализации и регулярного цикла патч-менеджмента. Когда уязвимость живет в гипервизоре или в панели управления, цена ошибки обычно выше, чем у рядового серверного софта.
Следующий шаг очевиден: после публикации патчей рынок будет ждать, появятся ли публичные PoC-эксплойты и начнут ли атакующие массово проверять не обновленные инсталляции.