Уязвимость в балансировщике нагрузки VMware (CVSS 9.8) и сбой Google Cloud VMware Engine

Критическая уязвимость в балансировщике нагрузки VMware и сбой обновления Google Cloud VMware Engine, две новости для каждого администратора. Broadcom во вторник предупредил о семи уязвимостях в VMware Avi Load Balancer, самая опасная из которых CVE-2026-47865 с оценкой CVSS 9.8: она позволяет обойти аутентификацию и получить доступ к плоскости управления. А Google Cloud признал, что неудачное изменение конфигурации лишило часть клиентов его сервиса VMware Engine (GCVE) отказоустойчивости растянутых кластеров, той самой, за которую они платят. Обе истории описал The Register 15 июля, и обе бьют по администраторам, чья инфраструктура завязана на VMware.

Критическая уязвимость VMware Avi: обход аутентификации с CVSS 9.8

Название VMware Avi Load Balancer вводит в заблуждение. За ним полноценный Application Delivery Controller с балансировкой нагрузки и Web Application Firewall (WAF). VMware описал брешь скупо: «Злоумышленник с сетевым доступом может получить доступ к плоскости управления Avi, обойдя механизм аутентификации».

Почему уязвимость так опасна

Инструмент работает с VMware Cloud Foundation и Kubernetes Service, а ещё умеет связывать ресурсы в публичных облаках. Захват control plane такого продукта означает контроль над тем, как распределяется трафик и как срабатывает защита WAF, то есть потенциальную компрометацию всего, что за ним стоит. Остальные пять CVE тоже нешуточные: оценки от 8.8 до 7.1. Broadcom уже выпустил обновления с исправлениями.

Что делать администраторам

Если у вас в контуре есть балансировщик нагрузки VMware Avi, проверьте версию, накатите патчи Broadcom и ограничьте сетевой доступ к плоскости управления. Держать control plane открытым наружу при активной уязвимости обхода аутентификации, прямое приглашение для атакующего.

Сбой Google Cloud VMware Engine: одно обновление, минус отказоустойчивость

Отдельная беда развернулась в Google Cloud VMware Engine. По отчёту об инциденте (13:24 PDT / 21:24 UTC 14 июля), часть клиентов «испытывает зональные сбои, влияющие на сетевую связность в нескольких регионах»; проблема началась в 10:00 PDT. Сначала Google указал на «базовую проблему сетевой связности инфраструктуры, соединяющей зоны внутри растянутого кластера», и предупредил о «проблемах синхронизации между затронутыми зонами».

Как устроен растянутый кластер

Смысл растянутого кластера (stretched cluster) в повышении надёжности: создаётся виртуальный пул ресурсов, охватывающий две физические площадки, которые синхронизированы для быстрого переключения без простоя. В следующем обновлении Google уточнил причину: «сбои межзональной связи и флаппинг BGP-сессий между зонами кластера». Связь потерялась между зонами и witness-устройством, из-за чего зоны не могли безопасно синхронизировать состояние.

Что именно пострадало

Хранилище и вычисления уцелели, виртуальные машины продолжали работать, пользователи просто не могли до них достучаться. Для бизнеса это ничем не лучше полного падения, если приложения недоступны.

Затронутые регионы Google Cloud VMware Engine и рекомендации

В 16:05 PDT Google признал: «Наше расследование выявило недавнее обновление конфигурации как вероятную причину межзонального сетевого сбоя», команды работают над устранением. Сроков восстановления компания не назвала, так что клиентам в затронутых регионах, australia-southeast1, australia-southeast2, europe-west3 и northamerica-northeast2, остаётся ждать.

Обе истории укладываются в один урок: держите резервные каналы доступа, сегментируйте сеть, ограничивайте внешний доступ к плоскости управления и не завязывайте критичные нагрузки на один облачный регион. Защита данных начинается с того, что к вашему управляющему контуру не может подключиться посторонний. Если вам нужен независимый и безопасный доступ к серверам, у нас есть аренда VPS в Sigma.

Источники

The Register, о сбое GCVE и уязвимостях VMware Avi Load Balancer