Redash CVE-2026-42093

Exploitation requires an authenticated Redash account (versions after 8.0.0 through pre-26.9.0) holding at least view-only access to BOTH the Query Results data source AND the referenced data source. The attacker must invoke the Query Results query runner using param_query_N_{key=value} parameters, which route through the vulnerable replace_query_parameters() raw-substitution path that bypasses ParameterizedQuery schema validation and omits the is_safe permission check. The primary limiting factors are the dual data-source access requirement and the need for valid authentication (PR:L), meaning this is realistically an insider or compromised-account scenario rather than anonymous remote exploitation; environments where low-privilege users are granted view-only access to sensitive referenced data sources are most at risk.

This is a genuine, prioritizable issue rather than a high-CVSS paper risk, though not a drop-everything emergency. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, score 8.7) indicates a network-reachable, low-complexity attack requiring only low privileges and no user interaction, with high impact to confidentiality, integrity, and availability of the referenced data source. The key limiting signal is PR:L: exploitation requires an authenticated Redash user who holds at least view-only access to BOTH the Query Results data source and the referenced data source, so this is an insider/privilege-escalation-within-the-app risk, not an anonymous internet attack. EPSS is not provided in the input, so exploitation probability cannot be quantified. This is NOT on CISA KEV and no public exploit was supplied - only the fixing commit and GHSA advisory - so there is no evidence of active exploitation. The confirmed source-code diff (removal of raw replace_query_parameters() in favor of ParameterizedQuery with an is_safe/not_view_only permission check) strongly corroborates the vulnerability as described and real. Net: credible, well-evidenced authenticated SQLi worth patching promptly in any multi-tenant/shared Redash deployment, but the PR:L gating keeps real-world mass-exploitation risk below that of an unauthenticated flaw.

A low-privileged but authenticated Redash user with view-only access to the Query Results data source and a referenced query crafts a request supplying param_query_N_{key=value} parameters containing SQL metacharacters. Because the old code path performed raw string substitution via replace_query_parameters() and skipped both schema validation and the is_safe permission check, the attacker-controlled text is injected directly into the referenced query's SQL and executed with that data source's privileges, enabling data exfiltration or modification beyond the user's intended view-only scope. No public exploit code was provided, but the fixing commit diff reveals the vulnerable code path precisely.