vCenter взламывают через ошибку 9,8 балла — обходного решения нет

К 19 августа 2026 года активная эксплуатация CVE-2026-59310 в VMware vCenter была подтверждена: днём ранее CISA внесла уязвимость в каталог известных эксплуатируемых ошибок. Карточка CVE в базе NVD указывает, что сетевой злоумышленник может использовать ошибку обхода каталогов в сервере Syslog для выполнения произвольного кода.

Прямой маршрут реакции к 19 августа не изменился: определить полную сборку vCenter, проверить сетевую доступность и возможные следы компрометации, затем установить исправление. Временной меры, устраняющей уязвимость без обновления, поставщик не предложил; разбор активной кампании BleepingComputer также описывает применение ошибки для получения удалённого доступа и закрепления через reverse SSH.

Почему оценка 9,8 соответствует реальному риску

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

Именно это сочетание даёт базовую оценку CVSS 3.1 в 9,8 балла. Речь идёт не только о чтении произвольного файла: заявленное последствие — выполнение произвольного кода на vCenter. Поэтому формулировка «vCenter взламывают» описывает подтверждённый сценарий эксплуатации, а не только теоретическую возможность.

Сетевой доступ не равен обязательной публикации сервера в интернете. Потенциальный маршрут может проходить через VPN, пользовательский или подрядный сегмент, скомпрометированный административный узел, балансировщик либо обратный прокси. Закрытый внешний интерфейс снижает экспозицию, но сам по себе не доказывает, что атакующий не мог достичь службы изнутри.

Какие сборки vCenter содержат исправление

Обновлённый 19 августа бюллетень Broadcom VMSA-2026-0006.2 подтверждает оценку 9,8, отсутствие обходного решения и следующую матрицу исправленных версий:

• vCenter 9.1.x.x: перейти на 9.1.0.0300 или более новую накопительную сборку, содержащую исправление.
• vCenter 9.0.x.x: установить 9.0.2.0100 или более новую исправленную сборку.
• vCenter 8.0 Update 3: установить 8.0 U3k или более новую сборку соответствующей ветки.
• vCenter 8.0 Update 2: доступен экспресс-патч 8.0 U2f.
• vCenter 7.0: при наличии контракта расширенной поддержки необходимо получить инструкции через Broadcom Support.

Проверять нужно полное обозначение версии, а не только номер основной ветки. Наличие 8.0 U3 не означает, что исправление уже установлено: контрольной версией является U3k. По той же причине ранняя сборка 9.1 не считается защищённой только потому, что относится к самой новой ветке.

Для vCenter в составе VMware Cloud Foundation, VMware vSphere Foundation или специализированной телекоммуникационной платформы требуется соблюдать предусмотренную для комплекса последовательность обслуживания. Совместимость и порядок установки следует сверить с документацией конкретного продукта, а не обновлять отдельный компонент как автономный сервер.

Как проверить доступность и период риска

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

1. Проверить правила межсетевых экранов, списки доступа, VPN, балансировщики, обратные прокси и опубликованные DNS-записи, через которые можно достичь vCenter.
2. Определить, был ли сервер доступен из интернета или менее доверенных внутренних сегментов в период между раскрытием уязвимости 29 июля и установкой исправления.
3. Сопоставить журналы vCenter, операционной системы и сетевых устройств с обычным профилем работы. Неожиданные входящие запросы, новые процессы, задания, файлы или исходящие соединения требуют отдельного расследования.
4. Сохранить журналы и доступные артефакты до очистки, переустановки или других изменений. При обоснованном подозрении на взлом сервер следует рассматривать как потенциально недоверенный.

Отсутствие одного известного индикатора не доказывает, что компрометации не было. Проверка должна учитывать фактическую достижимость сервера, время работы уязвимой сборки и изменения на самом узле, а не только наличие публичного адреса.

Почему изоляция не заменяет обновление

Ограничить доступ к vCenter до необходимых управляющих узлов и доверенных административных сегментов разумно как дополнительную меру. Также стоит закрыть неиспользуемые маршруты, пересмотреть доступ подрядчиков и контролировать исходящие соединения сервера.

Однако сегментация не устраняет CVE-2026-59310. Если атакующий уже контролирует разрешённый внутренний узел, VPN-учётную запись или систему администрирования, он может оказаться внутри доверенной зоны. Поэтому фильтрация трафика уменьшает вероятность эксплуатации, но не является объявленным поставщиком обходным решением.

Реакция считается завершённой после установки подходящей исправленной сборки и проверки фактического номера версии. Если vCenter был доступен злоумышленнику до обновления, одной установки патча недостаточно: необходимо отдельно оценить возможную компрометацию. Для поддерживаемых веток исправления доступны, а владельцам vCenter 7.0 с расширенной поддержкой требуется решение Broadcom Support.

Читайте также:

• Cisco закрыла пять ошибок SD-WAN с оценкой 9,9 — обходного решения нет
• Что делать, если ничто не интересует и нет цели в жизни.
• Возможность загружать Клипы через веб-версию Вконтакте