Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-54066

CVE-2025-54066: DiracX-Web CSRF Vulnerability

CVE-2025-54066 is a CSRF flaw in DiracX-Web that allows attackers to forge requests and redirect authenticated users to malicious sites for phishing. This post covers the technical details, affected versions, and mitigation.

Published:

CVE-2025-54066 Overview

CVE-2025-54066 is an open redirect vulnerability in DiracX-Web, a web application that provides an interface to interact with DiracX services. Versions prior to 0.1.0-a8 fail to validate the redirect parameter on the login page, allowing attackers to forge requests that redirect authenticated users to arbitrary external websites. The flaw is categorized under [CWE-601] (URL Redirection to Untrusted Site). Combined with HTTP parameter pollution, attackers can conceal the malicious destination URI. Version 0.1.0-a8 remediates the issue.

Critical Impact

Attackers can redirect authenticated DiracX-Web users to attacker-controlled sites for credential phishing and data theft.

Affected Products

  • DiracX-Web versions prior to 0.1.0-a8
  • DIRACGrid diracx-web component (packages/diracx-web-components)
  • Deployments exposing the DiracX-Web authentication flow

Discovery Timeline

  • 2025-07-17 - CVE-2025-54066 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-54066

Vulnerability Analysis

DiracX-Web exposes a redirect query parameter on its login page. The server uses this parameter to send users to a destination URL after authentication. The application does not validate whether the target URI belongs to a trusted origin, so any absolute URL is accepted. This behavior enables open redirect attacks against authenticated sessions.

Attackers exploit the flaw by crafting a login URL that appears to point to the legitimate DiracX-Web host while carrying a hostile redirect value. Because the initial hostname is trusted, users are more likely to complete authentication and follow the redirect. The result is an effective vector for phishing pages that impersonate the DiracX login screen and harvest credentials on second entry.

Root Cause

The root cause is missing origin validation on user-supplied redirect targets in the LoginForm and OIDCSecure components. The client passed window.location.pathname + window.location.search into a redirect URL parameter without allowlisting the destination. HTTP parameter pollution compounds the issue: attackers can supply multiple redirect values so parsing logic selects an attacker-controlled URI while user-visible tooling shows a benign one. See the CERN Auth Redirect Notice for a proof-of-concept URL demonstrating the parameter pollution technique.

Attack Vector

Exploitation is remote and requires user interaction. An attacker sends a victim a crafted DiracX-Web login link. After the user authenticates, DiracX-Web forwards them to the attacker's URI, which typically hosts a cloned login form requesting credentials again.

text
// Security patch in packages/diracx-web-components/src/components/OIDC/OIDCSecure.tsx
  const { configuration } = useOIDCContext();
  const { isAuthenticated } = useOidc(configuration?.scope);
  const { setPath } = useContext(NavigationContext);
+  const pathName = useContext(NavigationContext).getPath();

  useEffect(() => {
    // Redirect to login page if not authenticated
-    if (!isAuthenticated) {
-      setPath(
-        "/auth?" +
-          // URLSearchParams to ensure that auth redirects users to the URL they came from
-          new URLSearchParams({
-            redirect: window.location.pathname + window.location.search,
-          }).toString(),
-      );
+    if (!isAuthenticated && !pathName.startsWith("/auth")) {
+      setPath("/auth");
    }
-  }, [isAuthenticated, setPath]);
+  }, [isAuthenticated, setPath, pathName]);

  return <>{children}</>;
}
// Source: https://github.com/DIRACGrid/diracx-web/commit/eba3b7bc4f9d394074215986e6d3c15b546b25d5

The patch removes user-controlled redirect construction and forces navigation to the static /auth path when the user is not authenticated.

Detection Methods for CVE-2025-54066

Indicators of Compromise

  • Login URLs containing external hostnames in the redirect parameter, for example /auth?redirect=https://attacker.example/
  • Multiple redirect parameters in a single request, indicating HTTP parameter pollution
  • Referrer logs showing DiracX-Web sessions terminating on unfamiliar third-party domains

Detection Strategies

  • Parse web server access logs and alert when the redirect query parameter contains an absolute URL whose host is not in the DiracX-Web allowlist
  • Deploy web application firewall rules that flag or block requests to /auth containing duplicate redirect keys
  • Correlate authentication events with outbound HTTP 302 responses to identify redirects leaving the trusted origin

Monitoring Recommendations

  • Baseline the set of legitimate post-login destinations and alert on deviations
  • Monitor phishing intelligence feeds for lookalike domains hosting DiracX-Web login clones
  • Track user-reported credential re-prompts, which often accompany successful open redirect phishing

How to Mitigate CVE-2025-54066

Immediate Actions Required

  • Upgrade DiracX-Web to version 0.1.0-a8 or later across all deployments
  • Audit outbound redirect logs from /auth for prior abuse
  • Notify users of the phishing risk and instruct them to verify login URLs before entering credentials

Patch Information

The fix is delivered in commit eba3b7bc4f9d394074215986e6d3c15b546b25d5 and released in version 0.1.0-a8. Details are documented in the GitHub Security Advisory GHSA-hfj7-542q-8fvv and the GitHub Commit Log Update. The patch removes the client-side construction of the redirect query parameter in OIDCSecure.tsx and forces navigation to the static /auth path.

Workarounds

  • Enforce an allowlist of trusted redirect hosts at the reverse proxy or WAF layer until the patch is applied
  • Strip duplicate redirect parameters from inbound requests to defeat HTTP parameter pollution
  • Deploy Content Security Policy frame-ancestors and referrer policies to reduce phishing effectiveness
bash
# Example NGINX rule to block off-origin redirect targets on /auth
location /auth {
    if ($arg_redirect ~* "^https?://(?!diracx\.example\.org)") {
        return 400;
    }
    proxy_pass http://diracx_backend;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.