CVE-2026-27838Low· 3.1▾ Sunlitwger: IDOR via user-unscoped cache keys on routine API actions exposes workout data
▾ Sunlit zone — Low / medium · no exploitation signal
impact 17.1 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.2%
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.
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/
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.
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.
wger <= 2.1Refer to the advisory for the patched release.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-86257Medium· 5.4wger before 2.6 fails to sanitize first_name and last_name fields in the gym member TSV export endpoint, allowing any gym member to inject spreadsheet formulas
CVE-2026-86256Medium· 5.4wger before 2.6 (affected versions <= 2.5.0) contains an open redirect vulnerability in the trainer_login view (wger/core/views/user.py)
CVE-2026-86255Medium· 6.5wger before 2.5 fails to validate the maximum duration of routine date ranges, allowing authenticated users to create routines spanning arbitrarily long periods
CVE-2026-40474High· 7.6wger has Broken Access Control in Global Gym Configuration Update Endpoint
CVE-2026-27835Medium· 4.3wger: IDOR in RepetitionsConfig and MaxRepetitionsConfig API leak other users' workout data
CVE-2026-27839Medium· 4.3wger: IDOR in nutritional_values endpoints exposes private dietary data via direct ORM lookup