Spring Cloud Gateway и Tanzu для Postgres допускают удалённые атаки без аутентификации, затронуты и другие продукты VMware Tanzu

Максимальная оценка уязвимостей в пяти продуктах VMware Tanzu достигает 10,0 балла по шкале CVSS (общая система оценки уязвимостей). Восемь бюллетеней Broadcom от 1 октября описывают проблемы в шлюзе Spring Cloud Gateway для Kubernetes, в базе данных Tanzu для Postgres на Kubernetes, в платформе Spring Cloud Data Flow для Kubernetes и в хранилище Tanzu для Valkey. Днём позже французский центр реагирования на компьютерные атаки CERT-FR (подразделение национального агентства по информационной безопасности) свёл их в одно уведомление. Характер последствий разработчик не раскрыл, поэтому масштаб приходится оценивать по векторам атак и баллам из самих бюллетеней. Обновлять придётся платформы обработки данных и шлюзы API, развёрнутые в кластерах Kubernetes (система оркестрации контейнеров).

Детали уязвимостей

Spring Cloud Gateway принимает внешний трафик и распределяет его между внутренними сервисами. Уязвимы версии до 2.2.17. Вектор атаки описывает доступ по сети, без учётных данных и без действий со стороны пользователя. Отдельный параметр указывает на влияние за пределами самого компонента, то есть на смежные системы. Похожая картина у Tanzu для Postgres на Kubernetes: исправления вышли для версии 4.5.2, максимальная оценка та же. Ветка Spring Cloud Data Flow для Kubernetes обновляется до 1.6.16, там максимум составляет 9,8 балла. Для Tanzu для Valkey на Kubernetes подготовлена версия 3.5.1 с оценкой 9,3. Отдельно обновляется сам Tanzu для Valkey, хранилище типа "ключ - значение" для кэша и очередей: ветки 8.0.x, 8.1.x, 9.0.x и 9.1.x доводят до версий 8.0.11, 8.1.10, 9.0.6 и 9.1.2. Там оценка скромнее, 7,5 балла, но обновление обязательно. Часть уязвимостей Broadcom помечает как Critical, то есть высшая категория по внутренней шкале производителя.

Большая часть исправлений касается не собственного кода Broadcom, а сторонних библиотек внутри контейнерных образов. В списках фигурируют компоненты на языке Go (компилируемый язык программирования), библиотеки Python и элементы стека Java. Наряду с обычными CVE (единый идентификатор уязвимости) производитель приводит записи из базы уязвимостей Go. Один и тот же номер, CVE-2026-46595, встречается сразу в двух бюллетенях. Причина в общем компоненте, который используют и шлюз, и Postgres. Попадаются и давно известные случаи: в перечне есть CVE-2022-40897, CVE-2023-5752, CVE-2024-2236. Значит, часть образов содержала устаревшие зависимости годами. Общий объём списков в отдельных бюллетенях измеряется сотнями строк, и это не опечатка. Столько стороннего кода лежит сегодня в основе корпоративной платформы.

Практический интерес в том, какие системы затрагивает эта история. Postgres и Valkey хранят данные приложений, кэш и очереди сообщений. Компрометация хранилища открывает доступ к содержимому баз и к учётным данным сервисов, которые к ним подключены. Через шлюз проходит внешний трафик, поэтому ошибка в нём открывает путь к сервисам внутри кластера. В кластерах Kubernetes такие компоненты обычно доступны из внутренней сети, так что одной защиты периметра мало. Оценка 10,0 по CVSS означает высший уровень угрозы по этой шкале. Вектор для обоих продуктов описывает атаку по сети без аутентификации и без участия пользователя. Сходные условия складываются вокруг Spring Cloud Data Flow с его 9,8 балла. Для команд, которые отвечают за платформу, это оборачивается внеплановой работой: обновление затрагивает несколько сервисов сразу, а совместимость версий приходится проверять отдельно. Сведений об эксплуатации в реальных атаках в бюллетенях нет. CERT-FR отдельно отмечает, что разработчик не указал степень риска, и советует обращаться к первоисточникам.

Обновиться нужно до версий, указанных производителем. Spring Cloud Data Flow для Kubernetes доводят до 1.6.16, Spring Cloud Gateway для Kubernetes до 2.2.17, Tanzu для Postgres на Kubernetes до 4.5.2, Tanzu для Valkey на Kubernetes до 3.5.1, Tanzu для Valkey до 8.0.11, 8.1.10, 9.0.6 или 9.1.2 в зависимости от ветки. Одной смены тега мало. Продукты распространяются как контейнерные образы, поэтому зависимости меняются только вместе с новой сборкой. Администраторам стоит проверить, какие версии работают в кластерах, и пересобрать образы, подготовленные ранее. Проверить нужно и локальные реестры, где старые сборки лежат месяцами. Отдельного внимания требуют конвейеры сборки: если они тянут библиотеки из прежних источников, уязвимость вернётся при следующем релизе. Установки в тестовых контурах тоже нужны, иначе старые образы однажды попадут в рабочую среду.

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

Детали уязвимостей

Ссылки