CVE-2026-86256 in Wger
Summary
by MITRE • 09/06/2026
wger before 2.6 (affected versions <= 2.5.0) contains an open redirect vulnerability in the trainer_login view (wger/core/views/user.py). After a trainer enters impersonation mode, the view redirects to the user-supplied 'next' GET parameter via HttpResponseRedirect() without validating it with url_has_allowed_host_and_scheme(). An attacker who delivers a crafted link to an authenticated trainer can redirect the trainer's browser to an attacker-controlled domain, enabling phishing and leaking the wger URL structure (including the impersonated user's user_pk) via the Referer header.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/06/2026
The vulnerability identified in versions of wger prior to 2.6 represents a classic open redirect flaw located within the trainer_login view found in the core views module for users. This security issue arises from improper validation of input parameters, specifically the next GET parameter used during authentication flows. When an authenticated user with trainer privileges enters impersonation mode, the application constructs a redirection response using Django's HttpResponseRedirect function. Crucially, this process fails to verify whether the target URL provided in the next parameter belongs to an allowed host or scheme. The absence of validation via functions such as url_has_allowed_host_and_scheme allows attackers to supply arbitrary external URLs that bypass standard security checks designed to keep users within the trusted application domain.
From a technical perspective, the flaw stems from the direct use of user-supplied input in HTTP redirect headers without sanitization. In web applications, it is common practice to allow redirection after login or specific actions by passing a next parameter. However, when this mechanism lacks strict validation against an allowlist of trusted hosts and schemes, it becomes exploitable for malicious purposes. An attacker can craft a link containing a specially formatted URL pointing to a domain they control. When the victim trainer clicks this link while in impersonation mode or during the authentication process, their browser is instructed by the server response to navigate away from the wger application entirely. This behavior violates the principle of least privilege and trust boundaries within web applications, as it allows external domains to hijack the user's session context for deceptive purposes.
The operational impact of this vulnerability extends beyond simple navigation manipulation. By redirecting users to a malicious site controlled by an attacker, the flaw facilitates sophisticated phishing attacks where victims may be tricked into entering credentials or sensitive data on a fake login page that mimics the legitimate wger interface. Furthermore, because the redirection occurs from within the context of the authenticated session, the Referer header sent during subsequent requests to the attacker-controlled domain will contain information about the original wger URL structure. This leakage can reveal internal details such as user identifiers including the impersonated user's primary key or other path segments that might aid in further reconnaissance or targeted attacks against specific accounts within the system.
This vulnerability aligns with CWE-601, which defines open redirect vulnerabilities resulting from insufficient validation of input used for redirection logic. It also maps to MITRE ATT&CK technique T1583.002, specifically domain fronting or phishing via redirects, where attackers leverage trusted domains to lend credibility to malicious content. The exploitation chain relies on social engineering elements combined with technical misconfiguration in the authentication flow, making it particularly dangerous for applications handling sensitive user data and administrative functions like trainer impersonation modes.
To mitigate this risk, developers must implement strict validation mechanisms before performing any HTTP redirects based on user input. Specifically, the application should utilize built-in security utilities such as url_has_allowed_host_and_scheme to ensure that only URLs matching predefined trusted hosts and schemes are processed for redirection. Additionally, implementing a whitelist approach rather than relying solely on blacklist filtering provides stronger protection against novel bypass techniques. Regular code audits focusing on authentication flows and redirect logic can help identify similar vulnerabilities across the application stack. Updating to version 2.6 or later resolves this issue as it includes patches addressing these input validation gaps in the trainer_login view.