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.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.
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Python (PyPI) | wger | <= 2.1 | no fix |
References
- https://github.com/wger-project/wger/security/advisories/GHSA-42cr-w2gr-m54q
- https://nvd.nist.gov/vuln/detail/CVE-2026-27838
- https://github.com/wger-project/wger/commit/e964328784e2ee2830a1991d69fadbce86ac9fbf
- https://github.com/wger-project/wger
- https://pypi.org/project/wger
- https://github.com/advisories/GHSA-42cr-w2gr-m54q
- CVSS vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N- Weakness (CWE)
CWE-639- Platform
- Python (PyPI)
- Package
wger- Disclosed
- 26.02.2026
- Updated
- 11.10.2026 14:18
Sources and licenses
OSV / GitHub Advisory Database - PYSEC-2026-3418 - PyPA Advisory Database; CC BY 4.0
OSV / GitHub Advisory Database - GHSA-42cr-w2gr-m54q - CC BY 4.0
Vulnerability history: wger
All published vulnerabilities of this package (Python (PyPI)), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 20
- First → latest
- 11.2022 10.2026
- Without a fix
- 16
- Exploited in attacks
- 0
Severity breakdown
- Critical 2
- High 8
- Medium 9
- Low 1
Disclosures per year
- 2022: 1
- 2023: 2
- 2024: 0
- 2025: 0
- 2026: 17
-
wger: IDOR via user-unscoped cache keys on routine API actions exposes workout data this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.