В платформе vCluster нашли критическую уязвимость CVE-2026-22806. Ей присвоили оценку 9,1 из 10. Проблема затрагивает механизм ключей доступа и позволяет обходить ограничения, которые администраторы задают для этих ключей. Для команд, которые используют vCluster как слой управления виртуальными кластерами Kubernetes и разделяют ресурсы между проектами, это уже не теория, а реальный риск выхода за пределы выделенного периметра.
В vCluster можно создавать ключи доступа и ограничивать их область действия. Обычно это выглядит так: ключу разрешено работать только с конкретным проектом, определенными ресурсами или частью инфраструктуры. Это привычная практика, когда один сервис или команда должна видеть только свое, а не весь контур.
CVE-2026-22806 позволяет авторизованному пользователю с высокими привилегиями обойти такие ограничения. Важное уточнение: уязвимость не превращает человека в суперпользователя и не дает полномочий выше, чем у владельца ключа. Но она ломает сам принцип разграничения. Пользователь, который по правилам должен работать в рамках одного проекта, может получить доступ к ресурсам за пределами разрешенной области, если его роль достаточно высокая.
В среде Kubernetes это особенно чувствительно, потому что границы проектов часто совпадают с границами ответственности и данных. Когда ограничение ключа перестает работать, под удар попадают конфиденциальные настройки, внутренние сервисы, секреты, конфигурации и рабочие процессы, которые по идее должны быть изолированы друг от друга.
Уязвимость затрагивает все версии vCluster, предшествующие 4.6.0, 4.5.4, 4.4.2 и 4.3.10. Разработчики уже выпустили исправления для соответствующих веток, поэтому ключевой вопрос теперь не в наличии патча, а в скорости обновления.
vCluster часто используют именно ради многопользовательского доступа и разделения ресурсов. Если ограничения области действия ключей можно обойти, то рушится одна из базовых гарантий платформы: что проект А не увидит проект Б и не сможет на него влиять. Даже без полномасштабного взлома это может привести к утечке данных, изменению ресурсов, сбоям сервисов или конфликтам между командами, которые работают в одной инфраструктуре.
Подобные ошибки чаще всего проявляются не как громкая атака, а как тихая эксплуатация. В логах это может выглядеть как обычная работа авторизованного пользователя, который просто ходит туда, куда ему не положено. Поэтому в таких случаях важна не только установка патча, но и проверка, нет ли уже следов доступа к чужим проектам.
Если вы используете vCluster, нужно обновиться до исправленной версии для вашей ветки: 4.6.0, 4.5.4, 4.4.2 или 4.3.10. Если обновление нельзя сделать немедленно, стоит временно уменьшить риск.
Проверьте все ключи доступа, у которых задана ограниченная область действия, и оцените, кто ими пользуется. Убедитесь, что пользователи, имеющие доступ к таким ключам, не обладают избыточными правами. Если ключи используются для автоматизации, лучше создавать отдельные служебные учетные записи с минимально необходимыми правами и выпускать ключи только для них. Это не решает проблему полностью, но минимизирует ущерб, если обход ограничений будет использован.
Эта уязвимость из той категории, где главное не паниковать, а быстро вернуть системе понятные границы. vCluster создавался как инструмент изоляции. Поэтому любая ошибка, которая позволяет пересекать эти границы, должна исправляться в первую очередь.
