CVE-2026-33213: Redash CSRF Vulnerability

CVE-2026-33213 Overview

CVE-2026-33213 is an open redirect vulnerability [CWE-601] in Redash, an open source data visualization and sharing platform. Affected versions range from 5.0.2 through 26.3.0. The get_next_path() function in the authentication module strips the scheme and netloc from user-supplied next parameters but does not normalize multiple leading slashes. An attacker can craft a login URL such as /login?next=////evil.com to redirect authenticated users to an attacker-controlled external site. This behavior enables phishing and credential theft campaigns that abuse the trusted Redash domain.

Critical Impact
Attackers can weaponize legitimate Redash login URLs to redirect authenticated users to malicious sites, enabling phishing and session-token theft against organizations using Redash for business intelligence.

Affected Products

Redash versions 5.0.2 through 26.3.0
Redash self-hosted deployments using default authentication
Redash instances exposing /login endpoints to end users

Discovery Timeline

2026-07-15 - CVE-2026-33213 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-33213

Vulnerability Analysis

The vulnerability resides in the get_next_path() helper inside redash/authentication/__init__.py. This function processes the next query parameter used to redirect users after successful login. The original logic used urlsplit and urlunsplit to strip the scheme and netloc from user-supplied URLs, treating the result as a safe relative path.

Browsers, however, interpret URLs beginning with two or more forward slashes as protocol-relative references. A value like ////evil.com becomes //evil.com after partial sanitization and resolves to an external host when returned in an HTTP Location header. The authentication flow then redirects the user off the Redash domain immediately after login.

This is classified as an open redirect [CWE-601]. It requires user interaction because the victim must click the crafted link, but it does not require authentication or elevated privileges on the target Redash instance.

Root Cause

The root cause is incomplete input normalization. The get_next_path() function assumed that removing scheme and netloc components was sufficient to constrain redirects to same-origin paths. It did not collapse consecutive leading slashes or validate the result against an allowlist of internal paths, leaving protocol-relative URLs exploitable.

Attack Vector

An attacker crafts a phishing message containing a link such as https://redash.victim.example/login?next=////evil.com. The victim recognizes the legitimate Redash domain and authenticates normally. After authentication, Redash issues an HTTP redirect that browsers resolve to https://evil.com. The attacker-controlled site can then present a spoofed Redash interface, harvest session tokens transmitted via referrer, or deliver malware.

python

 import hmac
 import logging
 import time
+import unicodedata
 from datetime import timedelta
-from urllib.parse import urlsplit, urlunsplit
+from urllib.parse import urlparse, urlsplit, urlunsplit
 
 from flask import jsonify, redirect, request, session, url_for
 from flask_login import LoginManager, login_user, logout_user, user_logged_in

Source: Redash security patch commit 9e66f81. The patch adds urlparse and unicodedata imports to support stricter normalization of the next parameter before it is passed to redirect().

Detection Methods for CVE-2026-33213

Indicators of Compromise

HTTP access logs containing /login?next= values with two or more leading slashes, such as next=//, next=///, or next=////
Redirect responses from /login where the Location header points to a non-Redash domain
Referrer entries on external hosts originating from the Redash /login endpoint
User reports of unexpected redirects to unfamiliar sites after logging into Redash

Detection Strategies

Parse web server and reverse proxy logs for next parameter values matching the regex next=/{2,} or URL-encoded equivalents such as next=%2f%2f
Alert on HTTP 302 responses from /login whose Location header host does not match the Redash canonical hostname
Correlate authentication events with subsequent outbound browser navigation to newly registered or low-reputation domains

Monitoring Recommendations

Enable verbose logging of query parameters on the Redash reverse proxy or WAF
Feed authentication and redirect logs into a SIEM for continuous inspection of next parameter anomalies
Monitor DNS and proxy telemetry for user traffic to look-alike domains impersonating internal Redash portals

How to Mitigate CVE-2026-33213

Immediate Actions Required

Upgrade Redash to a version later than 26.3.0 that contains the patch from commit 9e66f81
Audit /login request logs for exploitation attempts using multiple leading slashes in the next parameter
Notify users of the phishing risk and reinforce verification of destination URLs after login

Patch Information

The fix is delivered in Redash commit 9e66f81673c482d9ae6c425afe009644114605d0. The patch updates redash/authentication/__init__.py to import urlparse and unicodedata, then normalizes the supplied next value so that protocol-relative and Unicode-obfuscated paths cannot escape the Redash origin. Full advisory details are available in the GitHub Security Advisory GHSA-rfgc-hc86-pxrv.

Workarounds

Deploy a WAF or reverse proxy rule that rejects requests to /login when the next parameter contains two or more consecutive leading slashes or URL-encoded variants
Strip or rewrite the next query parameter at the ingress layer to enforce single-slash, same-origin paths only
Restrict access to the Redash /login endpoint through single sign-on that validates redirect targets against an allowlist

bash

# Example NGINX rule to block exploitation of the next parameter
location /login {
    if ($arg_next ~* "^(/{2,}|%2f%2f)") {
        return 400;
    }
    proxy_pass http://redash_upstream;
}