CVE-2025-49592: N8n Workflow Automation Open Redirect Flaw

CVE-2025-49592 Overview

n8n is a workflow automation platform used to build and run automated workflows. Versions prior to 1.98.0 contain an Open Redirect vulnerability [CWE-601] in the login flow at the /signin endpoint. Authenticated users can be redirected to attacker-controlled domains after login by crafting URLs with a malicious redirect query parameter. The flaw affects any deployment that exposes the n8n sign-in page to users. Attackers can abuse the trusted n8n origin to launch phishing campaigns on lookalike domains such as n8n.local.evil.com, harvest credentials or 2FA tokens, and damage the hosting organization's reputation. The issue is patched in n8n version 1.98.0.

Critical Impact
Attackers can weaponize the n8n login flow to redirect authenticated users to phishing sites that impersonate the n8n UI, enabling credential and 2FA theft.

Affected Products

n8n versions prior to 1.98.0
n8n self-hosted deployments exposing the /signin endpoint
n8n Node.js distributions matching cpe:2.3:a:n8n:n8n:*:*:*:*:*:node.js:*:*

Discovery Timeline

2025-06-26 - CVE-2025-49592 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-49592

Vulnerability Analysis

The vulnerability lives in the frontend sign-in view at packages/frontend/editor-ui/src/views/SigninView.vue. The isRedirectSafe() helper validates the post-login redirect query parameter before the browser navigates to it. The pre-patch check accepts any value that begins with / or with window.location.origin as a string prefix.

String-prefix matching against the origin is insufficient. An attacker can register a domain whose string representation begins with the victim's origin, for example https://n8n.local.evil.com, and the check returns true. The browser then performs the redirect after a legitimate login.

Because the user is already authenticated with the real n8n instance when the redirect fires, the destination page can present a convincing re-authentication prompt or 2FA challenge. The pattern is tracked as CWE-601: URL Redirection to Untrusted Site.

Root Cause

The root cause is improper origin validation. Comparing a URL to window.location.origin using String.prototype.startsWith treats the origin as a text prefix rather than parsing the URL and comparing its origin property.

Attack Vector

An attacker crafts a link such as https://victim-n8n.example.com/signin?redirect=https://victim-n8n.example.com.attacker.tld/fake-login and delivers it through email, chat, or workflow notifications. After the user authenticates, the n8n frontend validates the redirect, accepts the attacker-controlled URL, and navigates away from the trusted origin.

text

 const isRedirectSafe = () => {
 	const redirect = getRedirectQueryParameter();
-	return redirect.startsWith('/') || redirect.startsWith(window.location.origin);
+
+	// Allow local redirects
+	if (redirect.startsWith('/')) {
+		return true;
+	}
+
+	try {
+		// Only allow origin domain redirects
+		const url = new URL(redirect);
+		return url.origin === window.location.origin;
+	} catch {
+		return false;
+	}
 };

Source: n8n commit 4865d1e. The patch parses the parameter with the URL constructor and compares the parsed origin for strict equality, rejecting malformed inputs through the catch branch.

Detection Methods for CVE-2025-49592

Indicators of Compromise

HTTP requests to /signin containing a redirect query parameter whose value points to an external or lookalike domain.
Referrer headers in web proxy logs showing navigation from the n8n origin to an unrelated domain immediately after a POST to /rest/login.
User reports of being prompted to re-enter n8n credentials or 2FA codes on a page that is not the configured n8n hostname.

Detection Strategies

Parse n8n reverse proxy or load balancer logs and alert on redirect query parameters that resolve to a hostname other than the n8n deployment's own origin.
Correlate successful authentications with subsequent cross-origin navigations and flag anomalous destinations.
Compare the version string reported by n8n (/rest/settings) against 1.98.0 to identify unpatched hosts.

Monitoring Recommendations

Enable access logging on the layer fronting n8n and retain /signin request parameters for review.
Monitor DNS resolver and secure web gateway telemetry for newly registered domains that embed the n8n hostname as a subdomain prefix.
Alert on outbound traffic from user workstations to domains that visually resemble the n8n hostname.

How to Mitigate CVE-2025-49592

Immediate Actions Required

Upgrade all n8n instances to version 1.98.0 or later.
Audit recent /signin traffic for suspicious redirect parameter values and notify any affected users.
Rotate credentials and 2FA secrets for users who followed suspicious n8n sign-in links.

Patch Information

The fix is delivered in n8n release 1.98.0 via pull request #16034 and commit 4865d1e. The patched isRedirectSafe() function parses the redirect value with the URL constructor and allows navigation only when the parsed origin strictly equals window.location.origin, or when the value is a relative path beginning with /. See GHSA-5vj6-wjr7-5v9f for the vendor advisory.

Workarounds

If upgrading is not immediately possible, place n8n behind a reverse proxy that strips or validates the redirect query parameter on /signin requests.
Restrict access to the n8n UI through VPN or allow-listed source IPs to reduce exposure to phishing-delivered links.
Train users to confirm the browser address bar still shows the trusted n8n hostname before entering credentials or 2FA codes.

bash

# Example NGINX snippet to strip the redirect query parameter on /signin
location = /signin {
    if ($arg_redirect) {
        return 302 /signin;
    }
    proxy_pass http://n8n_backend;
}