0037235: Open Redirect with `return` parameter in login_page.php - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0037235	mantisbt	security	public	2026-06-03 05:04	2026-06-04 09:08

Reporter	dracosectech	Assigned To	dregad
Priority	high	Severity	major	Reproducibility	always
Status	resolved	Resolution	no change required

Summary	0037235: Open Redirect with `return` parameter in login_page.php
Description	This finding is a bypass of the fix for CVE-2017-7620, which addressed mixed-slash URLs (`\/evil.com`) by converting backslashes to `%5C`. The protocol-relative shape (`//evil.com`) was not covered by that fix. Details Incomplete URL sanitization in `string_sanitize_url()` (`core/string_api.php`, lines 265-332) allows an attacker to craft a login page URL with a protocol-relative redirect target (e.g., `//evil.example.com/`) in the `return` parameter. The sanitizer's rejection regex (`(?:[^:])?:/`) requires a `:` character to identify off-site URLs, so protocol-relative URLs (which contain no scheme or colon) pass through unmodified. When an already-authenticated user visits `login_page.php?return=%2F%2Fevil.example.com%2F`, they are silently redirected to the attacker-controlled host. The `login_page.php` caller (line 89) passes the sanitized return value to `print_header_redirect()` with `$p_sanitize=false` and `$p_absolute=true`, which emits it directly as a `Location` header without further validation. By contrast, other callers of `print_header_redirect` elsewhere in the code (e.g., `account_prefs_reset.php`, line 91) pass `$p_sanitize=true`, which triggers a second sanitization pass that prepends the MantisBT host prefix (neutralizing any redirect). The login pages do not use this safer pattern, leaving them exposed. Impact An attacker distributes a link to the legitimate MantisBT login page with a crafted `return` parameter, after the victim logs in (or if already logged in), the victim's browser navigates to the URL (without specifying scheme e.g.: `https:`) set in the `return` parameter.
Steps To Reproduce	Login to MantisBT with any user account Visit the MantisBT path with return parameter set to `//ANY_WEBSITE`: /login_page.php?return=%2F%2FANY_WEBSITE The server returns HTTP 302 response, with `Location` header set to the given `//ANY_WEBSITE`. The browser follows the redirect and navigates to `http://ANY_WEBSITE/` (inheriting the current page's scheme, if is `https`, then redirect to `https://ANY_WEBSITE`), leaving the MantisBT origin entirely.
Additional Information	Reference: https://mantisbt.org/bugs/view.php?id=22816 (0022816: CVE-2017-7620: Open redirection vulnerability in /login_page.php) Credit: Dracosec Research Limited (Chris Chan, Krecendo Hui, William Lam)
Tags	No tags attached.
Attached Files	open-rdr.png (113,102 bytes) open-rdr.png (113,102 bytes)

dregad 2026-06-03 06:38 developer ~0071216	Hello, and thanks for the report. I'm trying to reproduce the problem, but failing get a redirection to an external site with the given instructions. https://mantisbt.org/bugs/login_page.php?return=%2F%2Fexample.com From Firefox console: GET https://mantisbt.org/bugs/login_page.php?return=//example.com => 302 Found Location header: /example.com => 404 Not Found Am I missing something ?

dracosectech 2026-06-03 08:14 reporter ~0071217	Hi dregad, Thanks for your prompt reply. Turns out this finding has been patched on (May 25, 2026) due to another issue: https://mantisbt.org/bugs/view.php?id=37133 (or https://github.com/mantisbt/mantisbt/pull/2224) The patch (commit: 2006074) omitted the leading `/`, such that, this finding cannot be reproduced on versions after that commit. While this finding was found based on the commit (59f25925) on May 21, 2026 but reported today, that explained why the result is different.

dregad 2026-06-03 11:19 developer ~0071218	Thanks for the feedback. That explains why I could not reproduce earlier, even though I did test both with the current stable (2.28.3) and master branches (at 8ce3dfd6). With this additional information, I'm now able to confirm the described behavior. Running Git bisect identifies the first bad commit as MantisBT master ad1be12b, and the it was indeed fixed by :mantisbt:2006074b1fed82a9fa6028983059ed45b1de7b7e as you pointed out. This means the vulnerability only ever existed for a few days on the master branch (i.e. the development version), between May 17th and 24th. I'm therefore not going to request a CVE for this, as we only do so for security issues affecting official releases. This issue will be closed. Security tests should be performed against on the latest release tag (or the master-X.Y branch), even though it's good practice to confirm whether an issue is still present in master.

raspopov 2026-06-04 00:01 reporter ~0071221	Oh my gosh... Don't be lazy about writing tests—it pays off...

dregad 2026-06-04 09:08 developer ~0071222	@raspopov it's great that you did write them eventually. Thanks to you for thus catching and fixing the bug before it was bundled in a release.