Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-113708: Argo CD Command Injection
TL;DR - CVE-2026-113708 enables command execution in Argo CD’s
argocd-repo-serverthrough malicious Kustomize resource references. - Argo CD 2.7.0 and later branches listed by NVD are affected; upgrade to a supported fixed release. - CISA KEV has no listing, but the critical severity and low privilege requirement make urgent patching appropriate.
CVE-2026-113708 is a critical Argo CD vulnerability that enables command injection in argocd-repo-server during Kustomize manifest generation. The issue affects deployments processing malicious remote resources, bases, or components and can be triggered through a path requiring only Application get permission.
Are You Affected?
CVE-2026-113708 affects Argo CD deployments that process Kustomize remote resources, bases, or components. The vulnerable behavior involves ref or version query-string values passed to git fetch without a Git end-of-options separator. A malicious value beginning with a hyphen can be interpreted as the Git --upload-pack option.
| Field | Assessment |
|---|---|
| CVE | CVE-2026-113708 |
| CVSS | 9.9 Critical |
| CVSS vector | Not included in the supplied NVD result; retrieve the complete NVD JSON record before relying on individual vector components |
| Attack vector | The vulnerable API and manifest-generation paths are remotely reachable where Argo CD is exposed; the authoritative CVSS attack-vector field is unavailable in the supplied record |
| Authentication / privileges | The described upload path requires Application get permission on an existing Application; Application update and sync permissions are not required |
| Patch available | Yes, for the listed 3.3.x, 3.4.x, 3.5.x, and 3.6.x branches |
| Affected component | Argo CD argocd-repo-server manifest generation and Kustomize handling |
The supplied NVD description says Argo CD versions beginning with 2.7.0 contain the vulnerability. The listed branch-specific ranges are 2.7.0 through an unspecified fixed release, 3.3.0 through 3.3.14, 3.4.0 through 3.4.9, and 3.5.0 through 3.5.3. Argo CD 3.6.x before 3.6.0-rc2 is also identified as affected.
Because the supplied record is truncated and does not provide a complete product matrix, administrators should validate older and vendor-packaged builds against the upstream advisory before declaring them unaffected.
The issue is especially relevant to environments that grant broad Application read access. An attacker may commit a malicious Kustomization to a repository used by an Argo CD Application, or submit files through POST /api/v1/applications/manifestsWithFiles or argocd app diff --local --server-side-generate.
The upload route reportedly requires only Application get permission and does not require repository write, Application update, or Application sync access.
The Fix, If You’re in a Hurry
Upgrade to the latest supported Argo CD release. The minimum fixed versions identified in the supplied NVD record are:
- Argo CD 3.3.15
- Argo CD 3.4.10
- Argo CD 3.5.4
- Argo CD 3.6.0-rc2
No corresponding fixed version for the 2.7.x branch is provided in the supplied research. Do not assume that remaining on 2.7.x is safe. Move to a currently supported release line and confirm the installed image or binary version, rather than relying on a control-plane chart version alone.
For a Helm-managed deployment, the exact chart and image names vary by organization and release policy. A generic operational pattern is:
helm repo update
helm search repo argo/argo-cd --versions | head
helm upgrade argo-cd argo/argo-cd \
--namespace argocd \
--reuse-values \
--version <validated-chart-version>
Validate the resulting Argo CD image versions in the deployment and confirm that the repo-server rolled successfully:
kubectl -n argocd get deploy argocd-repo-server \
-o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
kubectl -n argocd rollout status deployment/argocd-repo-server
There is no reliable network-only workaround in the supplied advisory. Blocking outbound repo-server egress does not prevent execution because the vulnerable path uses a local transport such as file://.
As temporary risk reduction, restrict access to manifest-generation APIs, review users and service accounts with Application get, remove unnecessary file:// Kustomize references, and prevent untrusted repositories from being used by production Applications. These measures reduce exposure but do not replace upgrading.
Analyst’s Take: Patch the repo-server before spending time on detection tuning. Application
getpermission is sufficient in the described upload path, and network egress controls do not address execution throughfile://; use access restrictions and repository review only as interim measures.
How This Vulnerability Works
Kustomize supports remote resources, bases, and components whose URLs can contain query-string values such as ref or version. In the vulnerable implementation, those values can flow into a git fetch invocation without an explicit end-of-options marker. Git therefore has an opportunity to parse an attacker-controlled value beginning with - as an option rather than as data.
The relevant dangerous behavior is the use of Git’s --upload-pack option. With a local transport such as file://, Git can invoke the supplied command within the argocd-repo-server process.
The command runs with the privileges of the repo-server user. It may therefore access repository credentials, temporary files, mounted configuration, and other data available to that process. Command output may also be exposed through manifest-generation errors.
The NVD description states that Git does not execute the supplied command when the remote uses an https:// URL. That distinction matters, but filtering only HTTPS URLs is not a complete remediation. Deployments may process local transport references, and the underlying unsafe argument handling remains a product defect until the fixed release is installed.
The vulnerable functionality can be reached through normal Application processing or through local-file manifest-generation workflows. The described upload path lowers the privilege barrier because Application get permission is sufficient. An attacker does not necessarily need to alter an Application, synchronize it, or write to its source repository.
Technical Notes: Vulnerable Argument Handling
Conceptually, the unsafe flow resembles passing an untrusted value directly to Git:
git fetch <transport-url>?ref=<attacker-controlled-value>
A value beginning with a hyphen can be interpreted as an option. The corrective implementation must preserve the value as data and prevent option parsing.
Operators should not attempt to reproduce the issue in production. Validate exposure through version inventory, configuration review, and controlled security testing.
Severity, Explained
The supplied NVD result rates CVE-2026-113708 9.9 Critical. That score reflects a vulnerability with potentially severe consequences: command execution in a central Argo CD repository-service component, possible access to repository credentials, and a low privilege requirement in the described API path.
The complete CVSS vector was not included in the supplied NVD response. Consequently, the precise values for attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability cannot be stated without risking an invented scoring breakdown.
The API exposure and Application get requirement provide operational context, but they are not a substitute for the authoritative vector. Retrieve the full NVD JSON record or the upstream advisory before publishing a component-by-component CVSS explanation.
The practical severity is higher than a routine manifest-generation bug. The repo-server is a trust boundary between Git repositories, Argo CD control-plane services, and Kubernetes deployment workflows. A successful compromise may expose credentials or repository content and could enable follow-on activity against connected systems.
The impact depends on pod identity, mounted secrets, repository credentials, network reachability, and Kubernetes permissions. Organizations reviewing broader identity-related exposure can also consult this identity attacks glossary.
Is It Being Exploited?
CISA’s Known Exploited Vulnerabilities catalog does not currently list CVE-2026-113708. Its supplied status is on_kev: false, with no addition date, due date, or ransomware campaign flag. CISA has not confirmed this vulnerability as exploited in the wild through the KEV catalog.
No confirmed in-the-wild exploitation was identified in the supplied NVD and CISA results. That does not prove exploitation has not occurred. KEV absence is an absence of current CISA catalog confirmation, not evidence that the issue is harmless or unexploited in every environment.
The supplied references include an upstream Argo CD fix commit and pull request, but they do not establish the existence of a separate public exploit repository or confirmed weaponized proof of concept.
Treat the public fix and technical description as sufficient information for capable attackers to develop exploit attempts, particularly because the issue involves command injection and the required privilege may be only Application get.
Detecting It in Your Environment
Begin with an inventory of every Argo CD repo-server instance and its exact version. Review Applications and source repositories for Kustomizations containing remote resources, bases, or components, with particular attention to file:// URLs and query parameters named ref or version.
Audit access to manifest-generation workflows and identify principals with Application get permission.
Review repo-server logs for failed manifest generation, unexpected Git options, suspicious Kustomize references, and command output embedded in errors. The exact log format differs by Argo CD version and deployment configuration, so the following searches are starting points rather than universal signatures:
kubectl -n argocd logs deploy/argocd-repo-server --since=30d \
| grep -E -- 'file://|--upload-pack|manifest generation|failed to generate|ref=|version='
Search collected logs and SIEM events for patterns such as:
file://
--upload-pack
failed to generate manifests
manifest generation error
invalid Kustomization
ref=-
version=-
These strings are not proof of exploitation. file:// or manifest-generation errors may be legitimate, and logging may escape or truncate attacker-controlled values.
Correlate suspicious entries with Application access logs, Argo CD API audit events, repository changes, and pod process telemetry.
If runtime monitoring is available, alert when argocd-repo-server launches unexpected child processes or executes interpreters. Example process-monitoring logic should be adapted to the deployed image and legitimate baseline:
parent_process = argocd-repo-server
child_process in (sh, bash, ash, curl, wget, nc, python, perl, powershell)
Also inspect repository credentials, mounted secrets, service-account permissions, and outbound or lateral activity from the repo-server pod.
If suspicious execution is confirmed or cannot be ruled out on an affected instance, isolate the workload according to incident-response procedures, preserve logs, rotate repository credentials, and review other process-accessible secrets. A team password manager such as Try 1Password → may help organize credential rotation and controlled access during remediation, but it does not replace incident-response procedures or secret revocation.
For a structured readiness review after containment, consider documenting the response in a security tabletop exercise.
References and Further Reading
The primary references supplied for this vulnerability are:
- Argo CD Kustomize documentation
- Upstream Argo CD fix commit
- Upstream Argo CD pull request
- Argo CD 3.3.15 release
- Argo CD 3.4.10 release
Before finalizing an asset inventory or risk exception, retrieve the complete NVD JSON record and validate the version boundaries against the upstream Argo CD advisory and release notes. The supplied NVD result did not include the CVSS vector and may not contain the complete affected-version matrix.
For incident response, prioritize evidence from argocd-repo-server: container logs, Kubernetes audit records, Argo CD API access logs, process-execution telemetry, repository access logs, and secret-rotation history.
Affected operators should patch first, then investigate whether malicious Kustomizations or manifest-generation requests were submitted.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.