CVE-2026-75833 in Grav
Summary
by MITRE • 08/18/2026
The Grav API plugin (getgrav/grav-plugin-api, bundled with Grav 2.0's admin-next/API stack) before version 1.0.14 contains an open redirect weakness in SsoController::sanitizeReturnTo(). The function rejects a literal '//' prefix but does not account for browsers normalizing backslashes to slashes in special (http/https) schemes, so a returnTo value such as '/\evil.com' passes the guard and is later resolved by the browser as the protocol-relative URL '//evil.com'. Following a legitimate OAuth login flow, an attacker-supplied returnTo parameter could redirect an authenticated victim to an attacker-controlled site for post-login phishing. Full browser-side exploitability depends on the admin-next SPA's client-side oauth-callback handler and was not independently verified by the reporter.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The Grav API plugin, specifically within versions prior to 1.0.14 bundled with the Grav 2.0 administrative interface, exhibits a critical open redirect vulnerability located in the SsoController::sanitizeReturnTo() function. This flaw arises from an incomplete input validation mechanism designed to prevent malicious redirections during Single Sign-On operations. The developer implemented a safeguard that explicitly rejects URLs containing a literal double-slash prefix '//' which is the standard indicator for protocol-relative URLs or absolute HTTP/HTTPS paths intended to redirect users outside of the application's domain. However, this security control fails to account for browser-specific normalization behaviors regarding backslash characters in URL schemes.
The technical root cause lies in the discrepancy between server-side string validation and client-side URI parsing logic. The sanitizeReturnTo() function checks if the returnTo parameter begins with '//' but does not strip or reject forward slashes that are preceded by a single backslash, such as '/\evil.com'. Modern web browsers adhere to RFC 3986 specifications which dictate that in URIs using http or https schemes, a backslash is treated equivalently to a forward slash. Consequently, when the application passes this unnormalized value to the browser for redirection, the client interprets '\/' as '/', effectively transforming '/\evil.com' into '//evil.com'. This results in a protocol-relative URL that directs the user's browser to an external domain without any warning or indication of a change in origin.
This vulnerability is particularly dangerous because it can be exploited within the context of a legitimate authentication flow, specifically OAuth 2.0 implementations commonly used by Grav for administrative access. An attacker who controls a malicious web server can craft a phishing link that initiates an OAuth login process with Grav but includes a specially crafted returnTo parameter containing the backslash-encoded payload. Upon successful authentication, instead of redirecting the user to their expected dashboard or application page, the browser is instructed to navigate to the attacker's domain. This mechanism allows for sophisticated post-login phishing attacks where the victim has already authenticated, potentially lowering suspicion and increasing the likelihood of credential theft or session hijacking if subsequent interactions occur on the malicious site.
From a classification perspective, this issue aligns with CWE-601, Open Redirect URL Redirection to Untrusted Site ('Open Redirect'). The vulnerability also maps to MITRE ATT&CK technique T1566.002, Spearphishing Link, as it facilitates the delivery of malicious content through trusted authentication channels. While the exploitability is largely dependent on client-side behavior and requires user interaction with a phishing link that leverages the legitimate Grav OAuth flow, the impact remains significant due to the trust relationship established during login. The reporter noted that full browser-side exploitability depends on the specific implementation details of the admin-next SPA's oauth-callback handler, indicating that while the server-side validation is flawed, successful exploitation relies on how the frontend processes and executes the redirect instruction provided by the backend response.
To mitigate this vulnerability, immediate updates to version 1.0.14 or later are required as these versions address the input sanitization logic. For environments where upgrading is not immediately feasible, a temporary mitigation involves implementing stricter URL validation that normalizes backslashes to forward slashes before performing security checks on the returnTo parameter. Additionally, developers should consider using allowlists for valid redirect destinations rather than relying solely on blacklist-based filtering of malicious prefixes. Implementing strict Content Security Policy headers and ensuring that OAuth callback handlers validate the final destination against a whitelist of trusted domains can further reduce the risk of successful exploitation by limiting where users can be redirected after authentication.