Критическая уязвимость Kyverno: арендатор namespace может стать администратором кластера Kubernetes

Коротко о главном

26 сентября 2026 года уязвимость в Kyverno получила идентификатор CVE-2026-100706 с оценкой CVSS 9.9. В версиях до 1.19.1 пользователь, которому разрешено создавать политики только в своём namespace, может через поле apiCall.urlPath выйти за его пределы и получить права администратора всего кластера. Исправление — Kyverno 1.19.1, обновляться стоит сейчас.

Kyverno — один из самых распространённых движков политик для Kubernetes: он проверяет и изменяет объекты на входе в кластер. Уязвимость бьёт именно по мультиарендным кластерам, где командам выдают собственные namespace и разрешают писать свои политики. Когда мы ведём DevOps-сопровождение, права арендаторов на объекты движка политик разбираем отдельно от обычного RBAC, а для уже работающих кластеров проводим аудит информационной безопасности.

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

Что раскрыто и когда

Мейнтейнеры Kyverno выпустили версию 1.19.1 10 сентября 2026 года и в тот же день опубликовали пакет из пяти бюллетеней GitHub Security Advisory. Самый серьёзный из них — GHSA-5qq8-67g6-4h2w с пометкой «critical» и оценкой CVSS 3.1 9.9. 26 сентября CNA VulnCheck присвоил проблеме номер CVE-2026-100706, и запись появилась в национальной базе уязвимостей NVD; по шкале CVSS 4.0 там указано 9.4. Автор находки — исследователь Артём Черезов.

Уязвимыми названы все версии Kyverno ниже 1.19.1. Демонстрацию автор проводил на Kyverno 1.18.1, установленном из официального Helm-чарта 3.8.1 с настройками по умолчанию. Сведений об эксплуатации в реальных атаках на 28 сентября в открытых источниках нет, но бюллетень содержит пошаговую инструкцию воспроизведения — порог входа для атакующего низкий.

Как тенант выходит за границы своего namespace

В политиках Kyverno есть контекст apiCall: политика может сама обратиться к Kubernetes API. Для namespaced-политик действует ограничение — запрос обязан адресоваться только к namespace самой политики. Проблема в том, что проверка и исполнение запроса трактуют путь по-разному:

• Проверка нормализует urlPath функцией path.Clean, которая не раскодирует процентные последовательности. Сегмент %2e%2e для неё — обычное имя, и регулярное выражение видит в пути «правильный» namespace.
• Исполнение передаёт исходную строку в клиент client-go, а тот раскодирует %2e%2e в .. и схлопывает путь. Запрос уходит в чужой namespace или в кластерную коллекцию.
• Идентичность — сервисный аккаунт admission-контроллера Kyverno, а не пользователь, написавший политику. Поэтому RBAC арендатора здесь ничего не ограничивает.

В бюллетене описаны два сценария. Первый работает на установке по умолчанию: POST-запрос создаёт кластерный объект MutatingWebhookConfiguration, и вебхук атакующего начинает переписывать любые объекты, поступающие в кластер, — это прямой путь к правам cluster-admin. Второй сценарий создаёт PolicyException в служебном namespace kyverno и отключает принудительную политику для namespace атакующего; он требует включённых исключений политик — ровно той «усиленной» конфигурации, которую рекомендуют для продакшена.

Кого это касается

Для атаки нужно, чтобы у пользователя было право create на ресурс policies группы kyverno.io в своём namespace и обычная роль редактора для запуска нагрузок. Это типичная схема для внутренних платформ разработки, SaaS с выделенным namespace на клиента и CI-систем, где пайплайны сами разворачивают политики. Если политики пишет только администратор кластера, риск заметно ниже, но обновление всё равно обязательно.

В том же выпуске 1.19.1 закрыты ещё четыре проблемы высокой критичности: чтение данных из чужих namespace тем же приёмом с %2e%2e через GET-запросы (GHSA-c5qq-7g2q-cpqp, CVSS 7.7), обход проверки подписи образов через исключения ImageValidatingPolicy, обход SSRF-блоклиста в устаревшем исполнителе apiCall.service и чтение кэшированных данных GlobalContextEntry из чужих namespace. Это уже вторая критическая уязвимость класса «apiCall и namespace» в Kyverno за 2026 год — в январе была CVE-2026-22039.

Что сделать командам прямо сейчас

1. Обновите Kyverno до 1.19.1 или новее. Проверьте версию образа контроллеров командой kubectl -n kyverno get deploy -o wide и поднимите релиз Helm.
2. До обновления заберите у арендаторов право создавать policies.kyverno.io. Найдите такие привязки через kubectl auth can-i create policies.kyverno.io --as=… или аудит Role и RoleBinding.
3. Проверьте вебхуки. Выведите kubectl get mutatingwebhookconfigurations и сравните список с ожидаемым: каждый неизвестный вебхук — повод для расследования.
4. Проверьте исключения. Выведите kubectl -n kyverno get policyexceptions: всё, что не создавал администратор, удалите и выясните происхождение.
5. Поищите следы в политиках и логах. Namespaced-политики, у которых в apiCall.urlPath встречается %2e или .., и записи аудит-лога API-сервера о действиях сервисного аккаунта admission-контроллера за пределами ожидаемого.
6. Сузьте права самого Kyverno. Сервисный аккаунт движка политик не должен иметь больше прав, чем требуют ваши правила: чем уже его роль, тем меньше ущерб от следующей ошибки такого класса.

Часто задаваемые вопросы

Нужна ли атакующему учётная запись в кластере? Да. Это не атака из интернета без аутентификации: нужен пользователь или сервисный аккаунт с правом создавать политики Kyverno в своём namespace. Опасность в том, что такие права в мультиарендных кластерах выдают массово.

Защищает ли от атаки ClusterPolicy вместо namespaced Policy? Проблема в ограничении, которое применяется к namespaced-политикам. Но если арендаторы в принципе могут создавать объекты kyverno.io/v1 Policy, уязвимость доступна независимо от того, какими политиками пользуется администратор.

Эксплуатируется ли уязвимость? На 28 сентября 2026 года сообщений об атаках нет, в каталог CISA KEV уязвимость не внесена. При этом в бюллетене опубликован рабочий сценарий воспроизведения, поэтому откладывать обновление не стоит.

Что делать, если обнаружен посторонний вебхук? Считать кластер скомпрометированным: удалить вебхук, ротировать токены сервисных аккаунтов и секреты, проверить созданные за период объекты и образы запущенных подов.

Источники

• Kyverno, GitHub Security Advisory GHSA-5qq8-67g6-4h2w — Privilege escalation to cluster admin via Policy apiCall urlPath, 10 сентября 2026 (первоисточник)
• NIST NVD — CVE-2026-100706, опубликовано 26 сентября 2026
• Kyverno — release notes v1.19.1, 10 сентября 2026
• Kyverno, GitHub Security Advisory GHSA-c5qq-7g2q-cpqp — Namespace isolation bypass in namespaced Policy apiCall