Незакрытая уязвимость в Argo CD ставит кластеры Kubernetes под угрозу полного захвата

Если коротко

Synacktiv раскрыла неаутентифицированную уязвимость удалённого выполнения кода (RCE) в repo-server у Argo CD, которую можно раскрутить до полного захвата кластера Kubernetes. Ни CVE, ни патча — спустя восемнадцать месяцев после того, как в январе 2025 года о проблеме сообщили мейнтейнерам, — так что единственная защита сегодня это конфигурация. Внутренний gRPC-сервис, который рендерит манифесты, работает без аутентификации: любой под, дотягивающийся до него, может выполнять команды, а затем через кэш Redis у Argo CD развернуть подконтрольную злоумышленнику нагрузку на следующей автоматической синхронизации.

Исправление — это не обновление версии, потому что обновляться некуда. Это сегментация сети: включите сетевые политики Kubernetes, чтобы до портов repo-server и Redis дотягивались только собственные компоненты Argo CD, и относитесь к GitOps-платформе с той же настороженностью, что и к control plane кластера.

Если вы используете Argo CD, считайте внутренние порты открытыми, пока не докажете обратное. Включите сетевые политики сегодня, проверьте, какие нагрузки дотягиваются до control plane, и поставьте усиление GitOps в план на эту неделю, а не на следующий квартал. Это ровно та работа над радиусом поражения, которой место в каждом ревью платформы Kubernetes.

Что именно нашла Synacktiv?

Argo CD — один из самых распространённых GitOps-контроллеров в Kubernetes: он следит за Git-репозиторием, рендерит найденные там манифесты и приводит кластер в соответствие с ними. Уязвимость сидит в repo-server — компоненте, который и делает этот рендеринг. Его внутренний gRPC-сервис, включая эндпоинт GenerateManifest, поставляется без аутентификации в расчёте на то, что общаться с ним будут только другие компоненты Argo CD. Synacktiv показала, что это допущение небезопасно: любая нагрузка, дотягивающаяся до порта, может отправить специально сформированный запрос и, злоупотребляя опциями сборки манифестов вроде плагинов Kustomize, выполнить произвольные команды на repo-server. Proof of concept продемонстрирован на Argo CD v2.13.3, и, по данным Synacktiv, исправленного релиза не существует.

Неприятная часть — таймлайн раскрытия. Synacktiv сообщила о проблеме мейнтейнерам Argo CD в январе 2025 года; примерно восемнадцать месяцев спустя, без патча и без присвоенного CVE, компания опубликовала технические детали, чтобы предупредить операторов. Это значит, что обновляться попросту не на что. Для команд, опирающихся на облачную и DevOps-автоматизацию, это тот неудобный класс уязвимостей, где рекомендация вендора звучит как «обойдите конфигурацией», а не «обновитесь сейчас», — причём нужная конфигурация по умолчанию выключена.

Как одна уязвимость превращается в захват кластера?

Выполнение кода на рендерере манифестов звучит локально. Это не так — из-за того, где стоит repo-server и до чего он дотягивается. Synacktiv собрала из начального плацдарма полный захват в несколько шагов. Изнутри repo-server прочитали пароль от Redis из переменной окружения, подключились к кэшу Redis у Argo CD и отравили сохранённые данные о развёртывании. Argo CD доверяет этому кэшу. Поэтому на следующей автоматической сверке контроллер послушно развернул подсунутую злоумышленником нагрузку в целевой кластер — без вредоносного Git-коммита, потому что подмена произошла ниже по потоку от Git, внутри собственного состояния Argo CD.

В этом вся суть: Argo CD имеет доступ на запись к кластерам, которыми управляет, и хранит секреты, которые разворачивает, так что выполнение кода внутри него напрямую превращается в контроль над тем, что запускается в кластере. Злоумышленнику, дотянувшемуся до внутренних портов, не нужно ломать API-сервер кластера или красть kubeconfig — они дают Argo CD развернуть нагрузку за них. Для регулируемых нагрузок — платформы FinTech под DORA или системы здравоохранения под HIPAA — это не только проблема доступности и целостности, но и проблема управления данными, потому что скомпрометированный контроллер может планировать поды с доступом к продовым хранилищам данных.

Почему GitOps-инфраструктура — это уровень zero?

Самая полезная рамка, которую дало это раскрытие: GitOps-платформы относятся к «уровню zero» — тому же уровню доверия, что ваш провайдер идентичности и control plane кластера. Подумайте, что накапливает Argo CD: доступ на чтение к приватным репозиториям, доступ на запись к целевым кластерам и хранение секретов развёртывания — всё это в одном долгоживущем сервисе. Компрометация там затрагивает не одно приложение; она влияет на доставку ПО в масштабе. Большинство команд инстинктивно охраняют API-сервер Kubernetes и свой менеджер секретов, а затем запускают GitOps-контроллер, способный переписать и то и другое, как обычный под приложения в общей сети.

Практически мышление в терминах уровня zero меняет, куда вы вкладываете защитные усилия. Оно означает фокус на путях атаки, а не на периметровой экспозиции — вопрос не «этот порт в интернете?», а «какие поды дотягиваются до моего control plane и что они смогут, если один из них скомпрометируют?». Сегментация восток-запад внутри кластера, наименьшие привилегии между неймспейсами и жёсткая граница вокруг repo-server и Redis — вот контроли, которые реально притупляют этот класс атак. Именно здесь окупается сфокусированный аудит безопасности: он проясняет доверительные связи, которые большинство команд никогда не прорисовывали.

Что это значит для команд в США и ЕС

Если убрать частности, следствий три. Первое — немедленное и операционное: если вы используете Argo CD, у вас, скорее всего, есть экспозиция, которую можно закрыть конфигурацией уже сегодня. Поскольку смягчение — это сетевая политика, а не патч, нет обновления, которое надо планировать, и нет окна обслуживания, которого надо ждать, — и это палка о двух концах. Исправить быстро, но и легко пропустить, потому что ничто не заставляет вносить изменение, а установки по умолчанию, особенно через Helm, поставляются с выключенными защитными политиками.

Второе — архитектурное. Это раскрытие — конкретный аргумент в пользу того, чтобы относиться к каждому долгоживущему сервису автоматизации — GitOps-контроллерам, CI-раннерам, операторам секретов — как к привилегированной инфраструктуре с собственной сегментацией, а не как к ещё одной нагрузке в плоской подовой сети. Команды, которые переживают этот класс багов, — те, кто заранее допустил, что до внутренних сервисов дотянутся, и с первого дня выстроил сетевые политики, изоляцию неймспейсов и сервис-аккаунты с наименьшими привилегиями, так что единственный плацдарм с выполнением кода не проходит прямиком в кластер.

Третье — про процесс. Уязвимость, остающаяся незакрытой восемнадцать месяцев, без CVE, за который зацепятся ваши сканеры, не всплывёт в инструментах, на которые большинство команд полагаются, чтобы узнать, что чинить. Это напоминание, что сканеры зависимостей и ленты CVE необходимы, но недостаточны; нужен ещё и тот, кто рассуждает о ваших собственных границах доверия. Встроить такое ревью в то, как вы ведёте Cloud & DevOps, — а не рассматривать безопасность как шлагбаум в конце — вот что отличает команды, которые патчатся быстро, от тех, кто узнаёт слишком поздно.

Что сделать на этой неделе

Вот версия «в продакшн». Воспримите раскрытие Synacktiv как подтверждение, что GitOps — это уровень zero, и закройте разрыв, прежде чем его найдёт кто-то другой. Включите сетевые политики Kubernetes, чтобы до repo-server и Redis дотягивались только компоненты Argo CD; проверьте, какие нагрузки могут говорить с control plane; при установке через Helm явно включите защитные политики (по умолчанию они выключены) и убедитесь, что внутренние порты недостижимы из посторонних подов.

Ничто из этого не является юридической консультацией, и ваши конкретные обязательства зависят от данных, отрасли и юрисдикции. Но стратегический сигнал трудно не заметить: индустрии только что напомнили, что конвейер, разворачивающий ваш софт, так же чувствителен, как и кластер, который его запускает. Преимущество у команд, которые сегментируют свою GitOps-инфраструктуру сейчас — пока это изменение конфигурации, — а не после того, как оно станет отчётом об инциденте.

Частые вопросы

Что за уязвимость? Неаутентифицированная RCE в repo-server у Argo CD — компоненте, который читает Git-репозитории и рендерит манифесты Kubernetes. Его внутренний gRPC-сервис, включая эндпоинт GenerateManifest, работает без аутентификации, поэтому любая нагрузка, дотягивающаяся до порта, может отправить сформированный запрос — например, злоупотребив опциями сборки Kustomize — и выполнить команды. Synacktiv раскрыла её около 1 июля 2026 года, продемонстрировав на Argo CD v2.13.3.

Есть ли патч? Нет. На начало июля 2026 года нет ни идентификатора CVE, ни исправленного релиза. Synacktiv сообщила мейнтейнерам в январе 2025 года и примерно восемнадцать месяцев спустя, когда дыру так и не закрыли, опубликовала детали, чтобы предупредить пользователей. Защита опирается на конфигурацию — прежде всего сетевые политики Kubernetes, а не на обновление версии.

Как это доходит до захвата кластера? Synacktiv раскрутила начальное выполнение кода на repo-server до полного захвата: прочитали пароль от Redis из переменной окружения, подключились к кэшу Redis у Argo CD и отравили сохранённые данные о развёртывании. На следующей автоматической синхронизации Argo CD развернул подсунутую нагрузку. Поскольку Argo CD имеет доступ на запись к своим кластерам и хранит секреты развёртывания, выполнение кода внутри него превращается в контроль над тем, что запускается.

Что делать? Включите сетевые политики Kubernetes, чтобы до портов repo-server и Redis дотягивались только собственные компоненты Argo CD. Argo CD поставляет манифесты политик, но установки через Helm по умолчанию оставляют их выключенными — включите явно. Также проверьте, какие нагрузки могут говорить с control plane, сегментируйте трафик восток-запад и относитесь к GitOps-инфраструктуре как к уровню zero.

Установки через Helm рискованнее? На практике да. Argo CD предоставляет определения сетевых политик, ограничивающих доступ к repo-server и Redis, но официальный Helm-чарт поставляется с ними в выключенном состоянии, поэтому установка по умолчанию через Helm с большей вероятностью оставит внутренние порты достижимыми из других подов. Командам, использующим Argo CD через Helm, стоит явно включить политики и убедиться, что до этих сервисов дотягиваются только компоненты Argo CD.