Argo CD Repo-Server 未修复漏洞可接管集群

Argo CD 是一款广泛用于向 Kubernetes 部署软件的工具，其 repo-server 组件存在一个未修复缺陷，未认证攻击者只要能够访问该组件的内部网络端口，就可以运行代码。

发现该漏洞的 Synacktiv 表示，这个问题可能导致整个集群被接管。目前没有修复方案，也没有 CVE。该公司称已于 2025 年 1 月向 Argo CD 维护者报告此缺陷；大约十八个月后，该问题仍未修复，因此它公开了细节以提醒用户。

该漏洞位于 repo-server，这是 Argo CD 中负责读取 Git 仓库并构建 Kubernetes manifests 的组件，这些文件定义了集群将部署什么内容。

其内部 gRPC 服务没有认证；任何能够访问它的人都可以发送精心构造的请求来运行命令。Synacktiv 在 Argo CD v2.13.3 上演示了该攻击，并表示没有修复版本；它没有公布完整的受影响版本列表。

该技术滥用了 kustomize，这是 Argo CD 运行的标准工具，用于将仓库文件转换为 manifests。kustomize 具有一个 --helm-command 选项，用来指定它应调用的 helm 二进制文件。

Synacktiv 发现，向 repo-server 的 GenerateManifest 服务发送未认证请求时，可以将该选项改为指向一个脚本，而该脚本从攻击者控制的 Git 仓库中拉取。当 kustomize 运行时，它执行的是该脚本，而不是 helm。

但“internal”并不意味着默认隔离。Argo CD 会随附 Kubernetes network policies，用于将 repo-server 与除其自身组件之外的所有对象隔离开。

Synacktiv 发现，常见的 Argo CD 安装方式 Helm chart 默认关闭这些策略，networkPolicy.create 设为 false。在这种配置下，攻击者只要攻陷集群中的一个 pod，就可以访问 repo-server 并触发该漏洞。

在 repo-server 上运行代码并不是终点。Synacktiv 利用该访问权限从环境变量中读取了集群的 Redis password，连接到 Argo CD 的 Redis cache，并污染了存储的部署数据。在下一次自动同步时，Argo CD 部署了攻击者提供的 workload。

这一步重新触发了 CVE-2024-31989，这是 Cycode 在 2024 年发现的一个缺陷：Argo CD 的 Redis 没有密码，导致集群中任何 pod 都可以污染部署缓存。Argo CD 通过添加 Redis password 修复了该问题，但缓存本身仍未签名，因此再次窃取密码就会重新打开同样的攻击路径。

该怎么做

目前没有已修复版本，因此防护手段是网络隔离。请启用 Kubernetes network policies，让只有 Argo CD 自身组件可以访问 repo-server 和 Redis 端口。Argo CD 提供了这些策略文件；Helm 用户需要手动启用，因为该 chart 默认将其关闭。

可使用以下命令检查当前是否已启用：kubectl get networkpolicy -A。正常的安装中，每个组件都应有一条 network policy，包括 repo-server 和 Redis。如果这些策略缺失，则集群中的其他位置都可以访问 repo-server 和 Redis 端口。

Synacktiv 编写了一个工具 argo-cdown，用于自动化整个攻击流程。该工具目前暂不公开，以便防御者有时间锁定自己的 network policies，并称稍后会在 GitHub 发布，供管理员测试自己的部署。

这并不是 Argo CD 第一次暴露其内部机制。2025 年 9 月，它修复了 CVE-2025-55190，当时一个只有基础读取权限的 API token 就能取回某项目的 Git 仓库凭据，《The Hacker News》当时也对此作出提示。

2026 年 5 月，另一个漏洞 CVE-2026-42880 允许只读用户读取明文 Kubernetes secrets。这个模式并不难看出：Argo CD 集中了集群访问权限和仓库密钥，而它的内部接口总是在把这些信息交出去，前一个漏洞是交给未认证请求，后一个则交给低权限 token。

在补丁发布之前，把集群网络视为不可信是唯一真正的防御方式。