CI/CD infrastructure · High, 8.8 of 10
We turned Argo CD's proxy field into a shell
Argo CD is how many teams ship to Kubernetes: it watches Git and deploys whatever the repository says. It is part of Argo, a CNCF graduated project, and has more than 24,000 stars on GitHub. We found that one field in its repository settings, the proxy for an SSH repository, was copied straight into a shell command. Anyone allowed to add or edit a repository could put a command in that field, and Argo CD would run it inside the component that holds the credentials for other repositories. It is public as CVE-2026-55797, scored 8.8 of 10 by the Argo CD maintainers, with RIA Labs among the credited reporters.
Read this part first
If you run Argo CD 2.11 or later, read the advisory. The fix is in 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2. Argo CD 2.x and 3.0 through 3.2 are out of support and will not get one: the only fix on those is upgrading to a patched 3.3 or newer.
If you cannot upgrade today, the advisory’s own workarounds: do not let untrusted users create or edit repositories, including project-scoped ones, and do not set a proxy on an SSH repository or on a credential template that matches one. No setting keeps an SSH proxy and removes the shell. Then check your repository and credential-template Secrets for proxy values nobody remembers setting.
The rest of this is about the pattern. There is no exploit code below.
How bad it is
8.8 of 10. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Reachable over the network, no click needed, and full loss of confidentiality, integrity and availability for the component it lands in. Two things keep it below Critical: the attacker needs permission to create or update a repository or a repository credential template (PR:L), and the score counts damage to the repo-server only (S:U).
Out of the box, only an admin can do that. But project-scoped repositories exist so app teams can add their own repos without one. It is a permission built to be handed out. Once an admin turns it on, any app team holding it could put a shell in a component every team depends on.
The code arrived in January 2024, with SOCKS5 proxy support for SSH repositories, but any proxy scheme set on an SSH repository takes the same path: http, https and socks5. It shipped in every release for nearly two and a half years, from 2.11.0 in May 2024 until the fix on 6 October 2026. The command runs when Argo CD tests the repository connection and again on later fetches, so it does not fire once and disappear. Set on a credential template, one proxy value applies to every matching SSH repository that has no credentials of its own.
Why a deployment tool is the worst place for a shell
A CD system is trusted by design. It reads every repository it deploys from and decides what runs in the cluster. The repo-server is the part that fetches those repositories and renders what gets deployed, and the advisory says plainly that a process running there can read the other Git, Helm and OCI credentials stored for it.
The score stops at the repo-server. The credentials don’t. The blast radius is not one team’s app. It is whatever those credentials reach. If they can only read, an attacker reads other teams’ source and charts. If they can write, the question becomes what Argo CD deploys next, and that is a supply-chain problem, not a bug report.
One field, one shell
To reach an SSH repository through a proxy, Argo CD hands SSH a small command that opens the proxy connection. The proxy host and port came straight from the repository’s settings and were placed into that command as text, and the command ran through a shell. A host value carrying shell syntax stops being a host and becomes a second command.
It only happens on SSH repositories. An HTTPS repository uses the same proxy setting as an ordinary HTTP proxy and never builds the command. The fix stops passing the proxy through a shell at all.
How we know
A description is not a finding. Our engine traced the proxy value from the repository settings into the shell, then ran Argo CD’s own connection code, unmodified, in a test harness against the then-current source, the same code as in 3.5.3, the latest release at the time. It executed the command that code built exactly the way Git does. With an ordinary proxy value the command stayed intact. With a crafted one, the shell split it and ran ours. We did not stand up a full Argo CD or a cluster, so container hardening was never part of the test. We reported it privately to the Argo CD team and published nothing until the fix and the advisory were out.
The 8.8 is the Argo CD maintainers’ score, on the published record. Ours was lower: 7.2, because out of the box only an admin can create or edit repositories. Our report noted that delegating that permission to a project role makes it 8.8, and that is the case the maintainers scored. Credit is shared: the advisory lists seven reporters, and its thanks name eight. RIA Labs is one of them, so we claim neither first nor alone.
Three questions for your own pipeline
None of this is unique to Argo CD. Any tool that turns configuration into commands, and most CI/CD systems do, is worth asking these about.
- Does any setting you store end up inside a shell command? A field labelled “host” is still input. If it reaches a shell as text, it is a command line with a nicer form in front of it.
- Who can edit your deployment tool’s repositories? Self-service permissions feel low-risk because they look like configuration. Treat them as privileged until you know where every field goes.
- What does the component that runs the command hold? A shell in a process with no secrets is a bug. A shell in a process holding other teams’ credentials is an incident.
None of it needs exotic tooling. It needs someone to follow each setting from the form where it is typed to the place where it is used.
What it proves, and what it doesn’t
It proves the engine can find a real bug in core infrastructure and show the injected command running, using Argo CD’s own code rather than an argument from source.
It does not prove we would find every bug in your pipeline, and it does not show how exposed any particular Argo CD install is: that depends on who holds repository permissions there and what its credentials can do. It was also not a test of a running Argo CD: the reproduction called the real function in a harness, so container hardening was never part of it.
If you run Argo CD, or anything else that turns settings into commands, we’ll read it. Nominate a target and the first scan costs nothing.
Published 7 October 2026. CVE-2026-55797 · GHSA-j6cw-g6p4-7hch · CVSS 3.1 base score 8.8 · CWE-78 (OS Command Injection) · RIA Labs credited as one of seven reporters, scored and published by the Argo CD maintainers. Status as of 8 October 2026. Corrections, or a project you maintain and want looked at: info@ria-labs.com.
See what a scan turns up
Nominate a target. The first scan costs nothing, and we’ll walk you through it.