GHSA-f3g8-9xv5-77gv: Open Redirect in Saltcorn via Incomplete URL Validation

The @saltcorn/server package, a core component of the Saltcorn no-code application builder, exposes an open redirect vulnerability in its authentication routing subsystem. The vulnerability resides specifically within the handling of the dest parameter submitted to the POST /auth/login endpoint. This parameter is intended to seamlessly redirect users back to their originally requested internal page following a successful authentication event.

To ensure users are only redirected to safe, internal routes, the application employs a custom validation function to verify that the destination URL is strictly relative. This function acts as a security boundary preventing external redirections. However, the implementation relies on a rudimentary string-matching approach that functions as a denylist, looking for specific protocol substrings.

An attacker can construct a crafted login URL containing a destination parameter formatted with backslash characters. The target server validates this input, classifies it as a safe relative URL, and issues an HTTP 302 redirect. Due to standardized browser parsing behavior, the victim's client normalizes the backslash payload into a valid cross-origin request, completing the redirection to the attacker-controlled server.

The root cause of this vulnerability is an inadequate implementation of the is_relative_url validation function located in packages/server/routes/utils.js. The function attempts to restrict inputs to relative paths by actively searching for patterns indicative of absolute URLs. Specifically, it checks for the presence of standard scheme indicators (:/) and protocol-relative indicators (//).

The validation logic is fundamentally flawed because it assumes an exhaustive list of URL scheme delimiters but fails to account for backslash characters (\). Modern web browsers, adhering to the WHATWG URL standard, process backslashes differently than basic string parsers. When a browser encounters a backslash in the authority component of special schemes (such as http and https), it automatically normalizes the character to a forward slash (/).

When the is_relative_url function evaluates the payload /\evil.com/path, it returns true because the literal strings :/ and // are absent. The server consequently reflects this string unmodified in the Location header of the HTTP 302 response. The victim's browser receives Location: /\evil.com/path, normalizes the leading characters to //evil.com/path, and executes a protocol-relative cross-origin navigation to the malicious domain.

The vulnerability is exposed through the interaction of two specific code paths. First, the validation function in packages/server/routes/utils.js defines the security constraint:

const is_relative_url = (url) => {
  return typeof url === "string" && !url.includes(":/") && !url.includes("//");
};

Second, the authentication handler in packages/server/auth/routes.js utilizes this function to process post-login redirection. The code retrieves the dest parameter from the request body, decodes it, and passes it to the flawed validator:

} else if (
  (req.body || {}).dest &&
  is_relative_url(decodeURIComponent((req.body || {}).dest))
) {
  res.redirect(decodeURIComponent((req.body || {}).dest));
} else res.redirect("/");

The reliance on includes for security validation constitutes an ineffective denylist. The attacker provides dest=/%5Cevil.com. The decodeURIComponent function translates this to /\evil.com. The is_relative_url function evaluates /\evil.com, finds no matches for :/ or //, and authorizes the redirection. The res.redirect method then outputs the unvalidated backslash sequence directly to the client.

Effective remediation of this code path requires abandoning the string-matching denylist. The patch must either implement an explicit allowlist of known-good internal routes, utilize a robust URL parsing library to verify the absence of a hostname component, or strictly reject inputs containing backslash characters.

Exploitation requires the attacker to construct a malicious hyperlink and deliver it to the intended victim. The attack relies on social engineering or phishing to induce user interaction. The attacker begins by configuring a rogue server to impersonate the legitimate Saltcorn application, typically hosting a fake login page designed to capture credentials.

The attacker crafts a URL targeting the legitimate Saltcorn instance. This URL incorporates the malicious destination payload into the login flow. A standard payload is structured as https://target-saltcorn.com/auth/login?dest=/%5Cevil.com/login-failed. The URL is distributed via email, malicious documents, or embedded in external web pages.

Upon clicking the link, the victim authenticates against the genuine Saltcorn server. The server processes the authentication, executes the vulnerable validation logic, and issues the 302 redirect. The browser follows the redirect to evil.com. The attacker's infrastructure then presents the victim with a secondary authentication prompt, citing a session error, and successfully harvests the subsequently entered credentials.

This vulnerability is assessed with a CVSS v4.0 base score of 5.1 (Medium). The scoring vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N accurately reflects the specific conditions and consequences of the flaw. The attack requires no prior privileges or complex network access, but it mandates active user interaction.

The primary system (the Saltcorn server) experiences no direct loss of confidentiality, integrity, or availability. The vulnerability does not permit the execution of arbitrary code, the reading of server files, or the disruption of database operations. The impact is entirely constrained to the client side and the user's subsequent session state.

The vulnerability facilitates high-fidelity phishing campaigns. Because the initial login occurs on the legitimate domain, the user relies on valid TLS certificates and expected site behavior. This established trust significantly increases the probability that the user will interact with the attacker's secondary payload upon redirection, leading to credential theft and subsequent unauthorized account access.

System administrators must update the @saltcorn/server package immediately. The maintainers have released corrected logic in versions 1.4.6, 1.5.6, and 1.6.0-beta.5. These updates deploy a comprehensive URL validation mechanism that accurately parses and sanitizes redirect destinations before execution.

If immediate patching is not technically feasible, security teams should implement interim mitigations at the edge layer. Web Application Firewalls (WAF) or reverse proxies can inspect incoming POST requests to the /auth/login endpoint. Rules should drop or sanitize requests where the dest parameter contains the backslash character (\) or its encoded equivalent (%5C).

Additionally, security operations teams should audit application logs to identify historical exploitation attempts. Queries should search access logs for POST /auth/login requests featuring dest query strings that begin with anomalous characters. Identifying these patterns will highlight potential ongoing phishing campaigns targeting the organization's user base.