Impact
Kustomize passes a remote resource, base, or component URL to git fetch, and appends that URL’s ref or version query value with no -- separator. A value that starts with -, such as --upload-pack=<command>, is parsed as a Git option. --upload-pack runs that command inside argocd-repo-server when the remote is a local transport such as file://. Git does not run it for an https:// remote. A file:// URL never leaves the pod, and Git returns the command’s output to the caller in the manifest-generation error. The command runs as the repo-server user and can read repository credentials and anything else available to that process.

All versions from v2.7.0 onward are affected, including every currently supported release. v2.6.15 and earlier are not. The behavior was introduced in 25badeb7a1 (2023-03-16, #12299), the change that upgraded the bundled Kustomize from 4.5.7 to 5.0.1, and was first released in v2.7.0. Kustomize 4.5.7 rejects a file:// URL, so this payload does not run there. Kustomize 5.0.0 is what first accepts file:// and hands it to git fetch. Replacing the repo-server binary with a newer Kustomize does not help: current Kustomize still passes ref through without --.

Two ways to supply the Kustomization:

Commit it to a Git repository that an Application builds with Kustomize.
Upload it through POST /api/v1/applications/manifestsWithFiles (argocd app diff --local --server-side-generate). This needs only Application get on an existing Application. It does not need permission to update or sync the Application, or write access to its Git repository.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:

v3.6.0-rc2
v3.5.4
v3.4.10
v3.3.15
The patch keeps Kustomize remote bases working. It places a git wrapper ahead of the real git on the Kustomize build’s PATH, so the remote URL and ref cannot be parsed as Git options.

Workarounds
Pin every Application that runs Kustomize to a Kustomize older than 5.0, such as 4.5.7. Register that binary with kustomize.path.<version> in argocd-cm, and set spec.source.kustomize.version (or argocd app set <app> --kustomize-version) on each Application. The binary that actually runs has to be that older one. Leaving Kustomize 5.x as the default, or as another registered version, leaves that path open.

Applications that rely on Kustomize 5 features cannot use this pin. Those builds will fail or drop behavior that 4.5.7 does not have.

Blocking repo-server egress does not prevent this, because a file:// remote never leaves the pod. Restricting Application get, or blocking POST /api/v1/applications/manifestsWithFiles, closes only the upload path. A Kustomization committed to Git is still built on the next sync.

There is no complete workaround besides upgrading.

Credits
The Argo CD team would like to thank @hoang-prod and @yabeow for responsibly disclosing this issue according to our security reporting guidelines.

References
Introducing commit: 25badeb7a1e154805340bb7237e0ce671f3772dd (#12299), first released in v2.7.0
Custom Kustomize versions: https://argo-cd.readthedocs.io/en/stable/user-guide/kustomize/#custom-kustomize-versions