Kubernetes исправляет старые CVE-записи: сканеры начнут видеть уязвимости, которые годами считались закрытыми

Команда Kubernetes исправляет старые записи CVE в официальной базе уязвимостей проекта. Изменение запланировано на 1 июня 2026 года. Оно затрагивает несколько давних проблем, которые были раскрыты ещё в 2020–2021 годах и до сих пор не имеют обычного патча.

Проблема находилась в метаданных CVE. В части записей было поле fixed version — версия, где уязвимость якобы устранена. Фактически исправленной версии нет: эти проблемы связаны с архитектурными компромиссами Kubernetes и закрываются настройками, ограничением прав и аккуратной эксплуатацией кластера.

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

Kubernetes Security Response Committee отдельно выделил три уязвимости:

CVE-2020-8561 — перенаправление вебхук-запросов kube-apiserver;
CVE-2020-8562 — обход ограничений API Server proxy через DNS TOCTOU;
CVE-2021-25740 — межпространственная переадресация через эндпойнды и EndpointSlices.

Еще одна запись, CVE-2020-8554, уже корректно описывает проблему как затрагивающую все версии. Для нее обновят формат версии, но не статус исправления.

Все три основные проблемы не закрываются обычным обновлением Kubernetes. Исправление потребовало бы изменить поведение, на которое полагаются реальные кластеры, сетевые плагины, ingress-реализации, операторы и интеграции.

CVE-2020-8561 связана с admission webhooks. Это механизм, через который Kubernetes передает запросы на внешние или внутренние обработчики перед созданием, изменением или проверкой объектов. Webhook может принимать решение: разрешить действие, изменить объект или отклонить запрос.

Проблема в поведении kube-apiserver при HTTP-редиректах. Если пользователь может управлять MutatingWebhookConfiguration или ValidatingWebhookConfiguration, он способен настроить эндпойнт, который перенаправит запрос API-сервера во внутреннюю сеть. При определенных условиях это может раскрыть ответы и заголовки в логах kube-apiserver.

Оценка риска — Medium, 4.1 по CVSS. Условие эксплуатации не массовое: атакующему нужны высокие права, связанные с webhook-конфигурациями, и доступ к логам API-сервера при слишком подробном уровне логирования.

Патча нет. Полное ограничение редиректов сломало бы нормальное поведение HTTP-клиента, на которое завязаны легитимные интеграции. Kubernetes рекомендует снизить уровень логирования API-сервера ниже 10 и отключить динамическое профилирование через --profiling=false. Это не убирает сам факт редиректа, но снижает риск утечки чувствительных данных через логи.

CVE-2020-8562 относится к API Server proxy. Это низкая по оценке, но неприятная проблема класса TOCTOU — time-of-check to time-of-use. Система сначала проверяет DNS-ответ и убеждается, что IP не относится к запрещенным диапазонам вроде localhost или link-local. Затем для реального подключения выполняется второе разрешение имени. Если DNS-сервер отдает разные ответы, пользователь может обойти ограничение.

Недоверенный пользователь может создавать или менять Node-объекты и проксировать к ним запросы, либо работать со StorageClass и получать доступ к логам kube-controller-manager. Риск получает оценку Low, 3.1 по CVSS.

CVE-2021-25740 связана с Endpoints и EndpointSlices. Эти объекты позволяют вручную указывать IP-адреса backend-сервисов. Такая возможность нужна многим сетевым инструментам и операторам, но она же создаёт риск: пользователь с правом записи в Endpoints или EndpointSlices может направить LoadBalancer или Ingress к IP-адресам в другом namespace.

Проблема описана как confused deputy attack. Компонент, которому доверяет сеть, начинает пересылать трафик туда, куда сам пользователь напрямую доступа не имел. NetworkPolicy может не спасти, если она уже доверяет LoadBalancer или Ingress-реализации.

Оценка — Low, 3.1 по CVSS. Риск зависит от прав в кластере и сетевой модели. Самая важная деталь для администраторов: все версии Kubernetes считаются затронутыми.

Основная мера — ограничить право записи в Endpoints и EndpointSlices. Начиная с Kubernetes 1.22, стандартные роли edit и admin в RBAC уже не включают эти права по умолчанию для новых кластеров. Кластеры, которые были обновлены со старых версий, нужно проверить отдельно. В таких средах старые агрегированные роли могли сохранить лишние разрешения.

Современные сканеры уязвимостей работают с диапазонами версий. Они берут CVE, смотрят affected versions, fixed versions и решают, применима ли запись к конкретному окружению.

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

Это не новая эксплуатация и не внезапный критический баг. Это изменение качества данных. Для SOC, DevOps и платформенных команд такой нюанс лучше объяснить заранее, иначе 1 июня отчеты могут выглядеть как резкий рост числа уязвимостей.

Для CVE-2020-8561 проверьте параметры kube-apiserver. Уровень логирования должен быть ниже 10. Профилирование лучше отключить через --profiling=false, если оно не нужно для эксплуатации и диагностики. Также стоит проверить, кто может создавать и менять ValidatingWebhookConfiguration и MutatingWebhookConfiguration.

Для CVE-2020-8562 проверьте, используется ли локальный кэширующий DNS на control plane-узлах. Если нет, оцените возможность внедрения dnsmasq или аналогичного решения. Отдельно посмотрите, могут ли недоверенные пользователи создавать или менять Node-объекты, StorageClass и выполнять proxy-запросы.

Для CVE-2021-25740 проверьте RBAC. Особое внимание — кластерам, которые начали жизнь до Kubernetes 1.22 и потом обновлялись. Нужно убедиться, что broad roles не дают запись в Endpoints и EndpointSlices без необходимости. Если такие права нужны отдельным сервисам, лучше выдать точечную роль под конкретный сценарий, а не оставлять широкие разрешения для всех редакторов namespace.