Команда безопасности SUSE Rancher раскрыла информацию о критической уязвимости, зарегистрированной под идентификатором CVE-2026-41050. Эта серьёзная проблема затрагивает Rancher Fleet - популярный инструмент, построенный по методологии GitOps (подход, при котором состояние инфраструктуры описывается в репозитории Git) и предназначенный для управления кластерами Kubernetes (системы оркестрации контейнеров) в масштабах предприятия. Суть уязвимости заключается в том, что она полностью разрушает ключевой механизм многоарендной изоляции платформы. Иными словами, злоумышленник может обойти границы безопасности между разными клиентами (арендаторами) и похитить конфиденциальные данные.
Согласно анализу, проведённому экспертами подразделения Lyrie Threat Intelligence, данная уязвимость фактически превращает компонент Helm (пакетного менеджера для Kubernetes), отвечающий за развёртывание приложений, в машину для кражи секретов. В результате общие среды, где несколько команд или клиентов используют один кластер, оказываются под непосредственной угрозой повышения привилегий.
Как работает уязвимость
Проблема возникает из-за того, что развёртыватель Helm в составе Fleet не проверяет, от имени какой учётной записи сервиса (ServiceAccount) выполняются операции при развёртывании. В нормальной ситуации каждый арендатор должен работать только со своими ресурсами. Однако из-за этой ошибки учётные данные с высокими привилегиями - а именно токен агента fleet-agent (служебного компонента, управляющего развёртыванием) - используются даже для запросов, которые должен выполнять ограниченный аккаунт клиента. В результате открываются два отдельных пути для атаки.
Первый путь связан с функцией lookup (поиска) в шаблонах Helm. Когда арендатор пишет шаблон диаграммы Helm и использует эту функцию для доступа к ресурсам Kubernetes, система выполняет команду от имени высокопривилегированного агента, а не от имени ограниченной учётной записи самого арендатора. Таким образом, если атакующий имеет базовый доступ на запись (git push) в отслеживаемый репозиторий, он может развернуть вредоносную диаграмму, которая незаметно извлечёт токены администратора из любого пространства имён (namespace) во всех подчинённых кластерах.
Второй путь атаки реализуется через конфигурационный файл Fleet (как правило, он называется fleet.yaml). Когда этот файл ссылается на секрет (Secret) или конфигурационную карту (ConfigMap) с помощью директивы valuesFrom, система снова считывает данные с правами администратора кластера (cluster-admin). Атакующий может легко создать конфигурацию, которая нацеливается на учётные данные за пределами его ограниченного окружения. При этом такие неавторизованные чтения секретов выглядят как обычные рабочие операции. Стандартные средства защиты не могут отличить легитимные команды от активной эксплуатации.
Каковы последствия
Эта уязвимость представляет значительный риск для общих DevOps-сред и платформ, предоставляющих Kubernetes как услугу (Kubernetes-as-a-Service). Если похищенный токен принадлежит внешнему сервису - например, роли IAM (управления доступом) в облаке AWS, - атакующий может использовать его для перемещения в стороны (lateral movement) по всей корпоративной инфраструктуре. В результате возможна утечка данных, компрометация критических систем и финансовый ущерб.
Какие версии затронуты
Уязвимость касается версий Rancher Fleet, выпущенных до 0.11.13, 0.12.14, 0.13.10 и 0.14.5. Для пользователей полноценных развёртываний Rancher в зону риска попадают Rancher 2.10.11 и старше - в таких случаях требуется ручное обновление Fleet. Ветки Rancher 2.11.x, 2.12.x и 2.13.x уязвимы, если не обновлены до версий 2.11.13, 2.12.9 и 2.13.5 соответственно. Кроме того, Rancher 2.14.0 также подвержен проблеме и требует немедленного обновления до версии 2.14.1.
Что делать специалистам
Установка патча - это окончательное решение, но пока обновление внедряется, командам безопасности необходимо предпринять самостоятельные срочные действия для защиты кластеров. Прежде всего следует выявить все уязвимые версии Rancher в сети и немедленно отключить репозитории, отслеживаемые Fleet, для любых недоверенных арендаторов. Затем нужно провести аудит репозиториев Git на предмет вредоносной активности: проверить диаграммы Helm на использование функции lookup в их шаблонах, а также проинспектировать файлы fleet.yaml на предмет ссылок valuesFrom, указывающих на пространства имён, выходящие за пределы допустимых.
Если такие неавторизованные обращения обнаружены, следует исходить из того, что компрометация уже произошла, и ротировать (заменить) все секреты, к которым был получен доступ из привилегированных областей (например, из пространства имён kube-system). Наконец, необходимо включить строгое аудиторское логирование на сервере API Kubernetes, чтобы фиксировать все будущие чтения секретов из подов, контролируемых арендаторами.
Вывод
Уязвимость CVE-2026-41050 - это серьёзный сигнал для всех, кто использует общие Kubernetes-среды на базе Rancher. Она демонстрирует, как ошибка в механизме подстановки учётных данных может свести на нет многоарендную изоляцию. В условиях, когда инструменты GitOps становятся стандартом для управления инфраструктурой, такие пробелы требуют немедленного внимания. Эксплуатация уязвимости не требует высокой квалификации, а последствия могут затронуть всю корпоративную сеть. Поэтому обновление до исправленных версий - не рекомендация, а обязательное условие безопасной работы.
