В Grafana Alloy, компоненте для сбора и обработки метрик, обнаружена уязвимость, которая позволяет раскрыть локальные файлы процесса и получить доступ к токену сервисного аккаунта Kubernetes. Проблема затрагивает все версии Alloy с 1.0.0 по 1.18.1 включительно и связана с обработкой ресурсов ServiceMonitor в составе модуля prometheus.operator.servicemonitors. Злоумышленник, имеющий возможность создавать или изменять такие ресурсы в наблюдаемом namespace, может заставить Alloy отправить содержимое произвольного файла на подконтрольный ему сервер.
Уязвимости CVE-2026-75889
Уязвимость получила идентификатор CVE-2026-75889 и оценку 7,7 балла по шкале CVSS. Она относится к категории раскрытия информации и затрагивает конфиденциальность данных, но не целостность и не доступность системы. При этом вектор атаки сетевой, а для эксплуатации требуется учетная запись с минимальными привилегиями. Особенность в том, что результат атаки может выйти далеко за пределы чтения одного файла: раскрытие токена сервисного аккаунта Kubernetes способно привести к полному захвату привилегий Alloy в кластере.
Суть проблемы в том, как Alloy обрабатывает параметр bearerTokenFile в спецификации ServiceMonitor. Этот параметр предназначен для указания пути к файлу, содержимое которого используется в качестве токена аутентификации при сборе метрик. В уязвимых версиях Alloy не проверяет, какой именно файл указан. Пользователь, обладающий правами на запись в ServiceMonitor, может подставить путь к любому файлу, доступному процессу Alloy на чтение. При следующем обращении к заданной конечной точке Alloy прочитает файл и отправит его содержимое как bearer-токен на сервер, указанный злоумышленником в конфигурации. Таким образом, атакующий получает содержимое файла в открытом виде.
Наиболее опасный сценарий - подстановка файла с токеном сервисного аккаунта Kubernetes. Обычно этот токен смонтирован в подах Kubernetes по известному пути. Если Alloy запущен внутри кластера, его процесс имеет доступ к этому файлу. Прочитав его, злоумышленник получает токен, с которым может выполнять запросы к API Kubernetes от имени сервисного аккаунта Alloy. Дальнейшие действия зависят от прав, назначенных этому аккаунту. Если они широкие, атакующий сможет создавать поды, читать секреты, изменять конфигурации или полностью скомпрометировать кластер. Даже если права ограничены, утечка токена сама по себе является критическим событием, поскольку позволяет легитимно взаимодействовать с кластером и развивать атаку.
Важно отметить, что эксплуатация требует определенных условий. Злоумышленник должен иметь возможность создавать или изменять ресурсы ServiceMonitor в том namespace, который наблюдает Alloy. Это значит, что атака доступна не каждому, а только пользователю с правами записи в соответствующие ресурсы Kubernetes. При этом уровень привилегий атакующего должен быть ниже, чем у сервисного аккаунта Alloy, иначе атака теряет смысл: если у атакующего уже есть сопоставимые права, раскрытие токена не даст ему новых возможностей. Тем не менее, в реальных кластерах права на ServiceMonitor часто выдаются разработчикам или командам мониторинга, а сервисный аккаунт Alloy может иметь более широкие полномочия для управления метриками. Именно такой перекос привилегий делает уязвимость практически значимой.
Проблема затрагивает Grafana Alloy, который используется для сбора метрик, логов и трассировок, а также для трансформации данных перед отправкой в системы мониторинга, включая Prometheus и Grafana. Alloy часто разворачивают в Kubernetes с использованием оператора Prometheus, который управляет жизненным циклом мониторинга. В таких средах ресурсы ServiceMonitor являются стандартным способом описания источников метрик. Уязвимость касается именно этой интеграции: Alloy принимает конфигурацию из ServiceMonitor, и в процессе обработки этого ресурса происходит чтение файлов без надлежащей валидации.
На данный момент нет информации о том, что уязвимость активно эксплуатируется в реальных атаках. Однако раскрытие токенов Kubernetes - популярная техника среди злоумышленников, особенно в цепочках атак на облачные инфраструктуры. Даже без активной эксплуатации наличие такой уязвимости в широко используемом инструменте мониторинга повышает риск целевых атак. Организациям, которые развернули Alloy в Kubernetes, стоит рассматривать эту проблему как приоритетную для устранения, поскольку потенциальный ущерб от утечки токена сервисного аккаунта значительно превышает обычную утечку файла конфигурации.
Разработчики Grafana уже знают о проблеме. Уязвимые версии - все выпуски, начиная с 1.0.0 и заканчивая 1.18.1. Пользователям следует обновить Alloy до актуальной версии, в которой эта проблема устранена. Перед обновлением стоит проверить список используемых ресурсов ServiceMonitor и убедиться, что доступ на их изменение имеют только доверенные лица. В качестве временной меры можно ограничить права сервисного аккаунта Alloy, а также запретить использование параметра bearerTokenFile там, где он не требуется. Также рекомендуется следить за бюллетенями безопасности Grafana и применять исправления сразу после их выхода.
Уязвимость в Alloy показывает, насколько опасным может быть сочетание недостаточной валидации входных данных и привилегированного положения сервиса в инфраструктуре. Механизм, предназначенный для подключения аутентификации при сборе метрик, превращается в канал чтения произвольных файлов. Подобные проблемы возникают в системах, которые работают с ресурсами Kubernetes и выполняют код от имени сервисных аккаунтов. В данном случае атакующему достаточно одного непроверенного параметра, чтобы получить доступ к внутренним секретам кластера. Исправление этой уязвимости должно стать частью более широкой работы по минимизации привилегий и строгой валидации всех данных, которые поступают в мониторинговые компоненты из внешних источников.
Ссылки
