Broadcom выпустила исправления для двух серьёзных уязвимостей в VMware Workstation и VMware Fusion. Обе позволяют выйти за границы виртуальной машины и выполнить код на хосте. Для атаки уже нужны локальные административные права внутри гостевой системы, поэтому обычного доступа пользователя недостаточно. Но такой уровень привилегий злоумышленник может получить через фишинг, слабые настройки учётных записей либо отдельную уязвимость.
CVE-2026-59346 получила 9,3 балла по шкале CVSS и критический статус. Ошибка связана с целочисленным переполнением при работе виртуального сетевого адаптера VMXNET3. Администратор скомпрометированной виртуальной машины может воспользоваться ею для произвольного выполнения кода непосредственно на хосте. Уязвимость обнаружили исследователи @h4urek, @cameudis и Stan S.
Вторая проблема, CVE-2026-59347, оценена в 8,1 балла CVSS. Это переполнение стекового буфера в HGFS, механизме общих папок между гостевой и основной системами. Атакующий с административными правами внутри виртуальной машины способен выполнить код с правами процесса VMX, работающего на хосте. Ошибку сообщили Yeonghyeon Choi и Tianchu Chen из Tencent Xuanwu Lab.
Уязвимы VMware Workstation и VMware Fusion версий 25H2 и 26H1. Исправления вошли в VMware Workstation 26H1u1 и VMware Fusion 26H1u1. Broadcom прямо указала, что обходных мер нет. Отключение отдельных функций может сократить поверхность атаки, но официальной заменой обновлению это не считается: затронутые установки следует перевести на 26H1u1.
Сценарий атаки требует предварительного захвата гостевой системы. Например, сотрудник запускает вложение из фишингового письма, злоумышленник повышает привилегии из-за слабой конфигурации, а затем использует CVE-2026-59346 или CVE-2026-59347 для перехода на хост. В лаборатории с несколькими виртуальными машинами такой переход особенно неприятен: компрометация одного гостя перестаёт быть изолированным инцидентом.
Сведений об эксплуатации CVE-2026-59346 и CVE-2026-59347 в реальных атаках пока нет. Это не делает отсрочку безопасной. Уязвимости VMware регулярно попадают в поле зрения атакующих, а промежуток между публикацией технических данных и появлением рабочих атак порой измеряется днями.
За месяц до выхода этих исправлений злоумышленники активно применяли уязвимости VMware vCenter CVE-2026-59309 и CVE-2026-59310. Последнюю, предположительно, превратил в оружие APT-актор, связанный с Китаем. Активность началась через пять календарных дней после публичного раскрытия, то есть времени на спокойное планирование обновлений почти не осталось.
Масштаб той кампании оценили в 361 уникальный IP-адрес жертв в 47 странах. Больше всего заражений пришлось на Германию — 55. Далее шли США с 41 адресом, Турция с 38, Иран с 26 и Франция с 25. Эти цифры относятся к атакам на vCenter, а не к новым ошибкам Workstation и Fusion, но хорошо показывают скорость охоты за свежими уязвимостями VMware.
Администраторам стоит проверить точные сборки Workstation и Fusion на всех рабочих станциях, включая редко используемые тестовые компьютеры. Версии 25H2 и 26H1 нужно обновить до 26H1u1, после чего убедиться, что новая сборка действительно установлена. Поскольку Broadcom не предложила обходного решения, откладывание патча оставляет открытым путь из захваченной виртуальной машины к коду на хосте.
Изображение носит иллюстративный характер
CVE-2026-59346 получила 9,3 балла по шкале CVSS и критический статус. Ошибка связана с целочисленным переполнением при работе виртуального сетевого адаптера VMXNET3. Администратор скомпрометированной виртуальной машины может воспользоваться ею для произвольного выполнения кода непосредственно на хосте. Уязвимость обнаружили исследователи @h4urek, @cameudis и Stan S.
Вторая проблема, CVE-2026-59347, оценена в 8,1 балла CVSS. Это переполнение стекового буфера в HGFS, механизме общих папок между гостевой и основной системами. Атакующий с административными правами внутри виртуальной машины способен выполнить код с правами процесса VMX, работающего на хосте. Ошибку сообщили Yeonghyeon Choi и Tianchu Chen из Tencent Xuanwu Lab.
Уязвимы VMware Workstation и VMware Fusion версий 25H2 и 26H1. Исправления вошли в VMware Workstation 26H1u1 и VMware Fusion 26H1u1. Broadcom прямо указала, что обходных мер нет. Отключение отдельных функций может сократить поверхность атаки, но официальной заменой обновлению это не считается: затронутые установки следует перевести на 26H1u1.
Сценарий атаки требует предварительного захвата гостевой системы. Например, сотрудник запускает вложение из фишингового письма, злоумышленник повышает привилегии из-за слабой конфигурации, а затем использует CVE-2026-59346 или CVE-2026-59347 для перехода на хост. В лаборатории с несколькими виртуальными машинами такой переход особенно неприятен: компрометация одного гостя перестаёт быть изолированным инцидентом.
Сведений об эксплуатации CVE-2026-59346 и CVE-2026-59347 в реальных атаках пока нет. Это не делает отсрочку безопасной. Уязвимости VMware регулярно попадают в поле зрения атакующих, а промежуток между публикацией технических данных и появлением рабочих атак порой измеряется днями.
За месяц до выхода этих исправлений злоумышленники активно применяли уязвимости VMware vCenter CVE-2026-59309 и CVE-2026-59310. Последнюю, предположительно, превратил в оружие APT-актор, связанный с Китаем. Активность началась через пять календарных дней после публичного раскрытия, то есть времени на спокойное планирование обновлений почти не осталось.
Масштаб той кампании оценили в 361 уникальный IP-адрес жертв в 47 странах. Больше всего заражений пришлось на Германию — 55. Далее шли США с 41 адресом, Турция с 38, Иран с 26 и Франция с 25. Эти цифры относятся к атакам на vCenter, а не к новым ошибкам Workstation и Fusion, но хорошо показывают скорость охоты за свежими уязвимостями VMware.
Администраторам стоит проверить точные сборки Workstation и Fusion на всех рабочих станциях, включая редко используемые тестовые компьютеры. Версии 25H2 и 26H1 нужно обновить до 26H1u1, после чего убедиться, что новая сборка действительно установлена. Поскольку Broadcom не предложила обходного решения, откладывание патча оставляет открытым путь из захваченной виртуальной машины к коду на хосте.
