CVE-2026-27838: wger: IDOR via user-unscoped cache keys on routine API actions exposes workout data
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.
Other sources
wger is a free, open-source workout and fitness manager. Five routine detail action endpoints check a cache before calling self.getobject(). In versions up to and including 2.4, ache 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. Commit e964328784e2ee2830a1991d69fadbce86ac9fbf contains a patch for the issue.
— NVD
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2026-27838?
CVE-2026-27838 is classified as a medium severity vulnerability due to its potential for information disclosure through IDOR.
How do I fix CVE-2026-27838?
To fix CVE-2026-27838, ensure that cache keys are scoped by user ID along with the primary key to prevent unauthorized access.
What are the potential impacts of CVE-2026-27838?
The potential impacts of CVE-2026-27838 include unauthorized access to sensitive workout data by exploiting user-unscoped cache keys.
Which versions of wger are affected by CVE-2026-27838?
CVE-2026-27838 affects wger versions up to and including 2.1.
Is CVE-2026-27838 related to API security?
Yes, CVE-2026-27838 is directly related to API security, particularly how it handles caching and user data segregation.