xss

CVE-2025-47933: Critical XSS Vulnerability in Argo CD’s Repository UI

Robert Morgan

Robert Morgan

— 9 min read

Hey everyone, grab your security hats! Today, we're diving deep into CVE-2025-47933, a crafty Cross-Site Scripting (XSS) vulnerability discovered in Argo CD. If you're running a vulnerable version, a seemingly innocent link on your repositories page could be a Trojan horse, giving attackers the keys to your Kubernetes kingdom. Let's unpack this one, because in the world of GitOps, trust is everything, and this bug tried to break it.

TL;DR / Executive Summary

CVE-2025-47933 is a Cross-Site Scripting (XSS) vulnerability lurking in Argo CD's repository UI. It affects versions starting from 1.2.0-rc1 up to, but not including, the patched versions v3.0.4, v2.14.13, and v2.13.8. The root cause? Improper filtering of URL protocols, specifically allowing javascript: schemes in repository URLs. An attacker with permissions to edit a repository configuration can inject a malicious script. When a victim (often an admin) clicks the specially crafted repository link, the script executes in their browser context. This can lead to unauthorized API actions, including creating, modifying, or deleting Kubernetes resources. The immediate fix is crucial: upgrade your Argo CD instances to a patched version.

Introduction: The Trusted Dashboard with a Hidden Flaw

Imagine your Argo CD dashboard – that central, gleaming console where you manage all your Kubernetes deployments with GitOps grace. It's your command center, a place of trust and control. Now, picture a small, unassuming link within that dashboard, one that points to a repository, suddenly turning into a launchpad for an attack. That's the unsettling reality of CVE-2025-47933.

Argo CD has become a cornerstone for many organizations practicing GitOps, automating application deployment and lifecycle management in Kubernetes. Its UI provides a convenient way to visualize and manage applications and their source repositories. However, with great power comes great responsibility, and any vulnerability in such a critical tool can have far-reaching consequences. This XSS isn't just about defacing a webpage; it's about potentially compromising the entire CI/CD pipeline and the Kubernetes clusters Argo CD manages. For anyone relying on Argo CD, understanding this vulnerability is key to safeguarding your infrastructure.

Technical Deep Dive: How a URL Became a Weapon

Let's get our hands dirty and look at the nitty-gritty of CVE-2025-47933.

Vulnerability Details:
The vulnerability resides in how Argo CD's frontend code handles repository URLs. Specifically, two files are key players:

  1. ui/src/app/shared/components/urls.ts: This file contains a function, repoUrl(url: string), responsible for parsing and formatting the URL of a Git repository.
  2. ui/src/app/shared/components/repo.tsx: This React component displays repository information, including a clickable link to the repository. It uses the output of repoUrl to set the href attribute of an <a> HTML tag.

The problem arose because the repoUrl function, in vulnerable versions (prior to commit a5b4041a79c54bc7b3d090805d070bcdb9a9e4d1, as seen in the state of the code at commit 0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1), didn't adequately validate the protocol of the input URL.

Here's a simplified look at the vulnerable code in urls.ts (referenced from Argo CD commit 0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1):

// File: ui/src/app/shared/components/urls.ts (Simplified, vulnerable version)
// Based on code at commit 0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1

const GitUrlParse = require('git-url-parse');

// Simplified protocol helper
function protocol(proto: string): string {
    return proto === 'ssh' ? 'https://' : proto + '://';
}

export function repoUrl(url: string): string | null {
    try {
        const parsed = GitUrlParse(url);
        if (!parsed.owner || !parsed.name) {
            // For example, if the URL is just 'javascript:alert(1)'
            // 'owner' and 'name' might be undefined or derived unexpectedly.
            // The advisory notes browsers may return a proper hostname for javascript: URLs,
            // which could allow it to pass this check in some cases.
            // Let's assume for a malicious 'javascript:' URL, it might bypass initial simple checks.
        }
        // The core issue: No validation of parsed.protocol against a whitelist (e.g., http, https, git)
        // It would happily use 'javascript' if that's what GitUrlParse extracted.
        return `${protocol(parsed.protocol)}://${parsed.resource}/${parsed.owner}/${parsed.name}`;
    } catch {
        return null;
    }
}

And how it was used in repo.tsx:

// File: ui/src/app/shared/components/repo.tsx (Simplified, vulnerable version)
// Based on code at commit 0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1

// Assume props.repo.repo contains the user-supplied repository URL
const repoLink = repoUrl(props.repo.repo);

// ... later in the render method ...
return (
    <a href={repoLink} title={repoLink}>
        {/* Repository name or icon */}
    </a>
);

Root Cause Analysis:
The fundamental flaw was the lack of URL protocol validation. The repoUrl function would attempt to parse any string given to it. If an attacker supplied a URL like javascript:alert('XSS'), the GitUrlParse library might still process it, and the repoUrl function would reconstruct it, potentially still as a javascript: URL, or something the browser interprets as such when placed in an href. When this javascript: URL is assigned to the href attribute of an <a> tag, clicking the link executes the JavaScript code within the user's browser session.

Think of it like a bouncer at a club (repoUrl function). The bouncer is supposed to check IDs (url string) to make sure they are legitimate (http, https, git). However, this bouncer was only checking if the ID looked like an ID (had some expected parts) but wasn't checking the "issuing authority" (the protocol). So, a fake ID with "Instructions: Give bearer free drinks" (javascript:doSomethingBad()) could get through. When the "bearer" (the user) presents this ID by clicking the link, the bartender (the browser) follows the malicious instructions.

Attack Vectors:
An attacker needs permission to edit repository settings within Argo CD. This isn't an unauthenticated vulnerability, but privilege escalation or insider threat scenarios are common.

  1. Gain Edit Access: The attacker obtains credentials or exploits another vulnerability to gain permissions to add or modify a repository configuration in Argo CD.
  2. Craft Malicious URL: The attacker changes the URL of an existing repository or adds a new one, setting the URL to a payload like javascript:doEvilStuff().
  3. Victim Interaction: A legitimate Argo CD user, typically an administrator or developer with significant privileges, navigates to the repositories page or any page displaying this malicious link.
  4. Execution: The victim clicks the seemingly normal repository link. The browser, seeing the javascript: protocol in the href, executes the embedded JavaScript code.

Business Impact:
The impact is severe due to Argo CD's privileged access:

  • Session Hijacking: Steal the victim's session token, allowing the attacker to impersonate the user.
  • API Abuse: Perform any action the victim's Argo CD session is authorized for:
    • Create, modify, or delete Argo CD applications.
    • Deploy malicious workloads (e.g., cryptominers, backdoors) to managed Kubernetes clusters.
    • Modify sync policies, potentially pointing applications to malicious Git repositories.
  • Data Exfiltration: Access sensitive information within Argo CD, such as repository credentials or application configurations.
  • Denial of Service: Disrupt CI/CD pipelines or Kubernetes workloads.

Given that Argo CD often runs with cluster-admin-like privileges to manage resources, this XSS can effectively lead to a full compromise of the managed Kubernetes environments.

Proof of Concept (PoC)

Let's demonstrate how this could be exploited. This is a simplified example; real-world payloads would be more stealthy and destructive.

Scenario: An attacker has permission to edit a repository's settings in Argo CD.

  1. Attacker's Action:
    The attacker navigates to the repository settings in the Argo CD UI (e.g., Settings -> Repositories -> Edit Repository). They change the "Repository URL" field to the following malicious payload:
    javascript:alert('CVE-2025-47933 PoC: Your Argo CD session token is: ' + localStorage.getItem('argocd.token'))

    Alternatively, if using the Argo CD API directly (this is a theoretical representation of an API call, actual endpoint and payload structure may vary):

    # Theoretical API call - requires attacker to have a valid token with repo edit perms
# curl -X PUT -k https://<your-argocd-instance>/api/v1/repositories/<repo-name-encoded> \
#   -H "Authorization: Bearer <attacker_or_compromised_user_token>" \
#   -H "Content-Type: application/json" \
#   -d '{
#         "repo": "javascript:alert(\'CVE-2025-47933 PoC: Your Argo CD session token is: \' + localStorage.getItem(\'argocd.token\'))",
#         "name": "<repo-name>",
#         "project": "<project-name>"
#      }'

  2. Victim's Action:
    A privileged user (e.g., an Argo CD admin) logs into the Argo CD UI and navigates to the page listing repositories, or views the details of the compromised repository. They see the repository link, perhaps with its usual name.

  3. Exploitation:
    The victim clicks on the repository link. Instead of navigating to a Git hosting provider, their browser executes the JavaScript. An alert box appears on their screen:

    CVE-2025-47933 PoC: Your Argo CD session token is: <actual_session_token_value>

    While an alert() is just a demonstration, a real attacker would use fetch() to silently send the token (and other sensitive data) to an attacker-controlled server, then perhaps redirect the user to the legitimate repository URL to avoid suspicion.

Mitigation and Remediation: Patching the Hole

The good news is that patches are available!

Immediate Fixes:
The most critical step is to upgrade your Argo CD instance to one of the following patched versions (or newer):

  • v3.0.4
  • v2.14.13
  • v2.13.8

Patch Analysis:
The fix for CVE-2025-47933 was implemented in commit a5b4041a79c54bc7b3d090805d070bcdb9a9e4d1. The core change is in the ui/src/app/shared/components/urls.ts file. Let's look at the patched logic:

// File: ui/src/app/shared/components/urls.ts (Patched version)
import {GitUrl} from 'git-url-parse';
import {isSHA} from './revision';
import {isValidURL} from '../../shared/utils'; // <-- New import for validation

const GitUrlParse = require('git-url-parse');

// Simplified protocol helper (same as before)
function protocol(proto: string): string {
    return proto === 'ssh' ? 'https://' : proto + '://';
}

export function repoUrl(url: string): string | null {
    try {
        const parsed = GitUrlParse(url);
        if (!parsed.owner || !parsed.name) {
            return null;
        }

        // Reconstruct the URL based on parsed components
        const parsedUrl = `${protocol(parsed.protocol)}://${parsed.resource}/${parsed.owner}/${parsed.name}`;

        // THE FIX: Validate the reconstructed URL
        if (!isValidURL(parsedUrl)) {
            return null; // If isValidURL returns false (e.g., for 'javascript:...' schemes), return null
        }
        return parsedUrl; // Only return if it's a valid URL
    } catch {
        return null;
    }
}

Why the fix works:
The patch introduces a call to a new helper function, isValidURL(), (presumably located in ui/src/app/shared/utils.ts). This function is responsible for checking if the scheme of the parsedUrl is legitimate (e.g., http, https, git, ssh). If parsedUrl starts with javascript: or any other disallowed protocol, isValidURL() would return false.
When isValidURL() returns false, the repoUrl function now returns null. An <a> tag with href={null} is generally treated by browsers as a non-interactive link or is simply ignored, effectively neutralizing the XSS payload.

Long-Term Solutions:
Beyond this specific patch, general best practices include:

  • Strict Input Validation: Always validate and sanitize all user-supplied input, especially URLs. Use allow-lists for URL schemes.
  • Contextual Output Encoding: While protocol validation is key for href attributes, ensure proper encoding is applied elsewhere to prevent other forms of XSS.
  • Content Security Policy (CSP): Implement a robust CSP to restrict where scripts can be loaded from and to disallow inline scripts and javascript: URLs in hrefs if possible (script-src 'self'; object-src 'none';).
  • Principle of Least Privilege: Ensure users and service accounts interacting with Argo CD have only the minimum necessary permissions.

Verification Steps:

  1. Verify your Argo CD instance is running one of the patched versions.
  2. (Carefully, in a test environment) Try to add or edit a repository with a URL like javascript:void(0) or javascript:alert(1). The UI should either reject the input outright, or if it accepts it, the rendered link should be inert (non-clickable or doesn't execute JavaScript).

Timeline of CVE-2025-47933

  • Discovery Date: Discovered by RyotaK (@Ry0taK from ryotak.net) prior to public disclosure. (Exact date not specified in the public advisory).
  • Vendor Notification: Assumed to follow responsible disclosure practices, notified Argo Proj maintainers.
  • Patch Availability: Patches were made available with the releases of Argo CD v3.0.4, v2.14.13, and v2.13.8, likely on or before May 28, 2025.
  • Public Disclosure: The CVE was publicly disclosed on May 28, 2025.

Lessons Learned: Trust but Verify, Especially URLs

This vulnerability, like many XSS issues, underscores some fundamental security principles:

  • Prevention Practices:

    • Never Trust User Input: This is the golden rule. Any data originating from outside your application's trust boundary (users, external systems) must be treated as potentially malicious until proven otherwise.
    • URL Protocol Whitelisting: When dealing with URLs, especially those destined for href attributes or other sensitive sinks, always validate the protocol against an explicit allow-list (e.g., http, https, git, ssh). Deny all others by default.
    • Defense in Depth: Don't rely on a single security control. Combine input validation on the server-side and client-side (though client-side is for UX, not security), contextual output encoding, strong Content Security Policies, and regular security testing.

  • Detection Techniques:

    • Static Analysis (SAST): SAST tools can help identify potentially dangerous data flows where unvalidated input reaches sensitive sinks like href attributes.
    • Dynamic Analysis (DAST): DAST tools can actively probe web applications for XSS vulnerabilities by injecting test payloads.
    • Manual Code Reviews: A security-conscious developer or a dedicated security reviewer looking at how URLs are handled in frontend code can often spot such issues. Pay special attention to any component that renders user-provided links.

  • One Key Takeaway:
    The javascript: pseudo-protocol is a powerful, and often dangerous, feature. While it has legitimate uses in bookmarks, its appearance in data intended for href attributes is almost always a red flag. Always sanitize and validate URL schemes before embedding them in your application's UI.

References and Further Reading

This CVE is a stark reminder that even in sophisticated systems like Argo CD, simple oversights can lead to significant security gaps. So, patch your systems, review your code, and stay vigilant!

What's the most overlooked attack surface in your CI/CD pipeline? Share your thoughts in the comments below!

Read more