В популярной системе непрерывной доставки Argo CD обнаружена критическая уязвимость, которая позволяет злоумышленникам с минимальными привилегиями извлекать конфиденциальные данные Kubernetes прямо из хранилища etcd. Проблема получила идентификатор CVE-2026-42880 и рейтинг 9,6 по шкале CVSS, что подтверждает её исключительную опасность для облачных сред.
Уязвимость CVE-2026-42880
Корень уязвимости кроется в отсутствии последовательной маскировки данных в конечной точке ServerSideDiff платформы Argo CD. Другие точки входа, такие как GetManifests и PatchResource, успешно применяют специальную функцию для скрытия секретной информации. Однако уязвимый ServerSideDiff, доступный через протоколы gRPC (протокол удаленного вызова процедур от Google) и REST (архитектурный стиль взаимодействия компонентов), формирует ответы на основе необработанных, незамаскированных состояний.
По данным технического разбора, опубликованного мейнтейнером alexmt, Argo CD обычно использует защитный слой под названием removeWebhookMutation. Этот механизм удаляет несанкционированные поля из ответа механизма Server-Side Apply dry-run (пробного применения изменений на стороне сервера). Затем система объединяет результат с предоставленным клиентом замаскированным живым состоянием, чтобы не допустить утечки реальных значений. Однако эта критическая защита не срабатывает, когда приложение включает аннотацию compare-options с включенной опцией mutation webhooks.
При такой конфигурации исходный ответ dry-run от Kubernetes возвращается напрямую в API-ответе, что раскрывает данные, хранящиеся в etcd (распределенное хранилище ключ-значение, используемое Kubernetes). Злоумышленнику не требуются продвинутые навыки или привилегии администратора. Любой аутентифицированный пользователь с базовым доступом только для чтения к приложениям Argo CD может использовать эту лазейку, если опция mutation webhook активирована.
После успешной эксплуатации атакующий получает возможность извлекать подлинные значения Kubernetes Secrets. В таких секретах часто содержатся токены сервисных аккаунтов, учетные данные баз данных, ключи API и TLS-сертификаты. Это ставит под угрозу конфиденциальность и целостность всего кластера Kubernetes.
Исследователь безопасности Hoang-Prod уже продемонстрировал PoC-скрипт (доказательство концепции) на Python, который автоматизирует процесс извлечения. Скрипт получает список управляемых ресурсов, идентифицирует секреты и использует протокол grpc-web для принудительного вызова конечной точки ServerSideDiff с целью получения незамаскированных целевых состояний. Поскольку скрипт сам обрабатывает необходимую фреймовку протокола и кодирование полезной нагрузки (данных, передаваемых в запросе), даже умеренно квалифицированные злоумышленники могут быстро собрать конфиденциальную информацию.
Эта уязвимость затрагивает версии Argo CD от 3.2.0 до 3.3.8 включительно. Разработчики проекта уже выпустили исправленные версии 3.3.9 и 3.2.11. Обновление до этих релизов - единственный надежный способ гарантировать корректную маскировку данных во всех конфигурациях приложений, независимо от настроек вебхуков.
Специалистам по информационной безопасности настоятельно рекомендуется немедленно проверить свои конвейеры непрерывной доставки. Важно убедиться, что окружения, использующие Argo CD, обновлены до защищенных версий. Промедление может привести к компрометации кластеров Kubernetes, утечке критически важных секретов и последующему развитию атаки вглубь инфраструктуры.
Интересно, что для эксплуатации этой уязвимости не требуется сложный вектор атаки или предварительное закрепление в системе (persistence) - злоумышленнику достаточно аутентифицироваться в Argo CD с минимальными правами. Это делает проблему особенно опасной для организаций, где управление доступом настроено нестрого или используются общие учетные записи с ограниченными полномочиями.
Хотя разработчики оперативно закрыли брешь, данная ситуация служит напоминанием о важности тщательного тестирования механизмов маскировки в системах, работающих с чувствительными данными. Ошибка в реализации защиты на одной конечной точке свела на нет безопасность всего решения. Поэтому при внедрении средств автоматизации доставки приложений необходимо не только полагаться на встроенные механизмы, но и регулярно проводить аудит их корректной работы в различных сценариях.
Организациям, использующим уязвимые версии, следует действовать незамедлительно. Обновление до версий 3.3.9 или 3.2.11 закрывает критическую уязвимость и предотвращает потенциальную утечку секретов Kubernetes. Дополнительно рекомендуется пересмотреть конфигурации приложений, особенно аннотацию compare-options с включенными mutation webhooks, и отключить эту опцию, если она не является строго необходимой для бизнес-процессов. Это снизит поверхность атаки даже в случае задержки с обновлением.
Ссылки
