Компания Synacktiv нашла уязвимость в Argo CD — одном из самых популярных инструментов для развёртывания приложений в Kubernetes. Уязвимость позволяет выполнить произвольный код на сервере без какой-либо аутентификации. Баг был передан разработчикам Argo CD ещё в январе 2025 года. Патча нет до сих пор, CVE-идентификатор не присвоен. Именно это вынудило Synacktiv опубликовать технические детали: молчание в таких случаях защищает только тех, кто атакует.
Под удар попал компонент repo-server. По своей функции это вполне рутинный сервис: читает Git-репозитории и собирает Kubernetes-манифесты, то есть файлы, определяющие, что именно кластер должен запустить. Проблема в том, что внутри repo-server живёт gRPC-сервис без какой-либо защиты. Никакого токена, никакого пароля. Любой, кто физически добрался до внутреннего сетевого порта, может отправить туда запрос и запустить произвольную команду.
Технически атака строится на том, как Argo CD работает с kustomize — стандартным инструментом, превращающим файлы репозитория в манифесты. У kustomize есть опция --helm-command, указывающая на бинарник helm, который нужно вызвать. Synacktiv выяснили, что неаутентифицированный запрос к сервису GenerateManifest позволяет переопределить эту опцию — направить её на скрипт из репозитория под контролем атакующего. Когда kustomize запускается, он исполняет уже не helm, а нужный атакующему код. Уязвимость воспроизведена на Argo CD версии v2.13.3.
Полная цепочка атаки выглядит так: атакующий компрометирует любой один pod в кластере, через него добирается до внутреннего gRPC-порта repo-server, отправляет подготовленный запрос к GenerateManifest, подменяет --helm-command на свой скрипт, а тот после выполнения читает пароль от Redis прямо из переменной окружения. Дальше атакующий подключается к Redis-кэшу Argo CD и отравляет хранящиеся там данные о развёртываниях. При следующей автоматической синхронизации кластер деплоит то, что подложил атакующий. Итог — полный захват кластера.
Здесь важно понять один нюанс. Argo CD поставляется с Kubernetes network policy, которые должны изолировать repo-server от всего, кроме собственных компонентов системы. Но Helm-чарт, через который большинство и устанавливает Argo CD, по умолчанию держит эти политики выключенными. Параметр networkPolicy.create стоит в false. Это означает, что скомпрометировав буквально один pod в кластере, атакующий уже имеет прямой доступ к repo-server.
Уязвимость не возникла в вакууме. В 2024 году компания Cycode описала CVE-2024-31989: тогда Redis в Argo CD не имел пароля вообще, и любой pod в кластере мог отравить кэш развёртываний. В качестве исправления разработчики добавили пароль к Redis. Новая атака от Synacktiv этот пароль крадёт — и проблема возвращается в полный рост, потому что сам кэш по-прежнему не подписан криптографически.
Помимо этого, в сентябре 2025 года был закрыт CVE-2025-55190: API-токен с минимальными правами на чтение позволял вытащить Git-credentials проекта. А в мае 2026-го обнаружили CVE-2026-42880: пользователи с правами только на чтение могли читать Kubernetes secrets в открытом виде. Закономерность прослеживается отчётливо: Argo CD аккумулирует доступ к кластеру и секретам репозиториев, а его внутренние интерфейсы раз за разом открывают этот доступ либо без аутентификации, либо через низкопривилегированные токены.
Patcha нет. Единственная реальная защита сейчас — сетевая изоляция. Нужно включить Kubernetes network policies так, чтобы только компоненты самого Argo CD могли добраться до порта repo-server и порта Redis. Файлы политик у Argo CD есть, но пользователям Helm-чарта придётся включать их вручную. Проверить текущее состояние можно командой kubectl get networkpolicy -A. Если политики активны — в выводе будет по одной записи на каждый компонент, включая repo-server и Redis. Если список пустой или политик нет — оба порта открыты для всего кластера.
Synacktiv разработали инструмент argo-cdown, автоматизирующий всю цепочку атаки. Пока они его не публикуют — дают администраторам время выставить сетевые политики. Позже инструмент появится на GitHub, чтобы каждый мог проверить свою инфраструктуру самостоятельно. До выхода патча относиться к внутренней сети кластера как к враждебной среде — единственный способ не оказаться в роли жертвы.
Изображение носит иллюстративный характер
Под удар попал компонент repo-server. По своей функции это вполне рутинный сервис: читает Git-репозитории и собирает Kubernetes-манифесты, то есть файлы, определяющие, что именно кластер должен запустить. Проблема в том, что внутри repo-server живёт gRPC-сервис без какой-либо защиты. Никакого токена, никакого пароля. Любой, кто физически добрался до внутреннего сетевого порта, может отправить туда запрос и запустить произвольную команду.
Технически атака строится на том, как Argo CD работает с kustomize — стандартным инструментом, превращающим файлы репозитория в манифесты. У kustomize есть опция --helm-command, указывающая на бинарник helm, который нужно вызвать. Synacktiv выяснили, что неаутентифицированный запрос к сервису GenerateManifest позволяет переопределить эту опцию — направить её на скрипт из репозитория под контролем атакующего. Когда kustomize запускается, он исполняет уже не helm, а нужный атакующему код. Уязвимость воспроизведена на Argo CD версии v2.13.3.
Полная цепочка атаки выглядит так: атакующий компрометирует любой один pod в кластере, через него добирается до внутреннего gRPC-порта repo-server, отправляет подготовленный запрос к GenerateManifest, подменяет --helm-command на свой скрипт, а тот после выполнения читает пароль от Redis прямо из переменной окружения. Дальше атакующий подключается к Redis-кэшу Argo CD и отравляет хранящиеся там данные о развёртываниях. При следующей автоматической синхронизации кластер деплоит то, что подложил атакующий. Итог — полный захват кластера.
Здесь важно понять один нюанс. Argo CD поставляется с Kubernetes network policy, которые должны изолировать repo-server от всего, кроме собственных компонентов системы. Но Helm-чарт, через который большинство и устанавливает Argo CD, по умолчанию держит эти политики выключенными. Параметр networkPolicy.create стоит в false. Это означает, что скомпрометировав буквально один pod в кластере, атакующий уже имеет прямой доступ к repo-server.
Уязвимость не возникла в вакууме. В 2024 году компания Cycode описала CVE-2024-31989: тогда Redis в Argo CD не имел пароля вообще, и любой pod в кластере мог отравить кэш развёртываний. В качестве исправления разработчики добавили пароль к Redis. Новая атака от Synacktiv этот пароль крадёт — и проблема возвращается в полный рост, потому что сам кэш по-прежнему не подписан криптографически.
Помимо этого, в сентябре 2025 года был закрыт CVE-2025-55190: API-токен с минимальными правами на чтение позволял вытащить Git-credentials проекта. А в мае 2026-го обнаружили CVE-2026-42880: пользователи с правами только на чтение могли читать Kubernetes secrets в открытом виде. Закономерность прослеживается отчётливо: Argo CD аккумулирует доступ к кластеру и секретам репозиториев, а его внутренние интерфейсы раз за разом открывают этот доступ либо без аутентификации, либо через низкопривилегированные токены.
Patcha нет. Единственная реальная защита сейчас — сетевая изоляция. Нужно включить Kubernetes network policies так, чтобы только компоненты самого Argo CD могли добраться до порта repo-server и порта Redis. Файлы политик у Argo CD есть, но пользователям Helm-чарта придётся включать их вручную. Проверить текущее состояние можно командой kubectl get networkpolicy -A. Если политики активны — в выводе будет по одной записи на каждый компонент, включая repo-server и Redis. Если список пустой или политик нет — оба порта открыты для всего кластера.
Synacktiv разработали инструмент argo-cdown, автоматизирующий всю цепочку атаки. Пока они его не публикуют — дают администраторам время выставить сетевые политики. Позже инструмент появится на GitHub, чтобы каждый мог проверить свою инфраструктуру самостоятельно. До выхода патча относиться к внутренней сети кластера как к враждебной среде — единственный способ не оказаться в роли жертвы.
