Broadcom закрыл две критические ошибки в VMware Workstation и Fusion, позволяющие совершить побег из виртуальной машины: атакующий, уже контролирующий ВМ, вырывается наружу и выполняет код на хосте под ней. Когда граница «гость — хост» падает, вместе с ней падает и предположение, что скомпрометированная ВМ изолирована.
Какие уязвимости дают побег из виртуальной машины VMware
CVE-2026-59346 — переполнение целого числа с оценкой CVSS 9.3. CVE-2026-59347 — переполнение буфера в стеке в компоненте HGFS (обмен файлами между хостом и гостем), оценка 8.1. Обе требуют локального административного доступа внутри ВМ и обе позволяют выполнить код от имени процесса VMX хоста.
Это предусловие важно, поэтому уточним: речь не про удалённый неаутентифицированный RCE. Атакующему сначала нужен админ внутри гостя. Но в реальном мире это низкая планка. Вредонос регулярно получает админа на машине; интересен другой вопрос: что он может сделать дальше? Эти баги отвечают: сбежать из ВМ и захватить хост, то есть ровно то, что виртуализация призвана предотвращать.
Почему побег «гость → хост» важнее, чем кажется на первый взгляд
Изоляция — вся суть виртуализации. Мы кладём недоверенное в ВМ именно затем, чтобы компрометация осталась внутри коробки. Рабочий побег рушит эту модель в повседневных сценариях:
- анализ вредоносного ПО: аналитик детонирует образец в ВМ, считая хост в безопасности, хотя рабочий побег превращает вашу лабораторию в жертву;
- общие и мультитенантные хосты: один арендатор, вырвавшись, добирается до хоста и потенциально до ВМ других;
- машины разработки и CI: скомпрометированная сборочная ВМ, дотянувшись до хоста, дотягивается до всего, к чему имеет доступ хост, включая учётки и другие проекты.
Проверять, держат ли эти границы на самом деле, — задача внутреннего пентеста и аудита облачной инфраструктуры.
Наш взгляд
Соблазн занизить эти баги велик, ведь сначала нужен локальный админ. Не занижайте. Эшелонированная защита означает, что важен каждый слой, а границу «гость — хост» люди чаще всего тихо считают надёжной, не проверяя её. И red team, и вымогатели мыслят цепочками: фишинг пользователя, эскалация до админа в ВМ, затем побег на хост ради доступа к бэкапам и доменной инфраструктуре. Побег из ВМ делает эту цепочку смертельной. Смоделировать такую цепочку целиком помогает Red Team.
Гипервизоры второго типа (Workstation и Fusion) работают на конечных точках и лабораторных машинах, а не на боевых кластерах — это меняет профиль риска, но не убирает его. Тот же класс бага в гипервизоре первого типа был бы аварией номер один, а относиться к побегам второго типа как к пустяку значит превратить исследовательский ноутбук в первую точку входа.
Что делать прямо сейчас
- Обновите VMware Workstation и Fusion до исправленных версий Broadcom. Это и есть весь фикс, примените его без промедления.
- Считайте любую ВМ, где атакующий может получить админа, потенциальным путём к хосту, и сегментируйте хост-машины подальше от чувствительных активов.
- Особо укрепите хосты анализа и CI: на них крутится самый недоверенный код, а значит, именно они станут вероятнейшей целью побега.
- Заведите виртуализацию и хосты гипервизоров в цикл контроля уязвимостей, чтобы следующий баг границы ловился быстро.
Вывод
Любая абстракция, которой мы доверяем изоляцию (ВМ, контейнеры, песочницы), на один эксплойт отстоит от того, чтобы стать просто ещё одним процессом на хосте. Это не повод от них отказываться, а повод перестать считать границу магией: патчить её, мониторить то, что внутри, и проверять, держит ли она, раньше, чем это за вас проверит атакующий. Начать стоит с тестирования на проникновение.