CVE-2026-27838: 
Python vulnerability analysis and mitigation

CVE-2026-27838 is an Insecure Direct Object Reference (IDOR) vulnerability in the wger workout manager application, caused by user-unscoped cache keys on routine API endpoints that expose other users' workout data. Affecting wger versions up to and including 2.4, the flaw allows any authenticated attacker to retrieve another user's cached routine details — including workout day sequences, exercise structure, training logs, and statistics — without ownership verification. It was published on February 26, 2026, by maintainer rolandgeider, with credit to reporter ByamB4. The CVSS v3.1 base score is 3.1 (Low) (Github Advisory, Feedly).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): five routine API action endpoints in wger/manager/api/views.py check the cache before calling self.get_object(), which is the ownership verification step. Cache keys are constructed using only the routine primary key (pk), with no user ID included — e.g., routine-api-structure-{pk} — meaning any authenticated user who knows or guesses a routine's numeric ID can retrieve the cached response originally populated by the legitimate owner. The cache TTL is set to one month (4 × 604,800 seconds), giving a wide exploitation window once a victim has accessed their routine. The five affected endpoints are GET /api/v2/routine/{pk}/date-sequence-display/, /date-sequence-gym/, /structure/, /logs/, and /stats/ (Github Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to access sensitive personal health and fitness data belonging to other users, including detailed workout routines, exercise logs, training statistics, and day sequences. The impact is limited to confidentiality — no data modification or service disruption is possible through this vulnerability. While lateral movement is not applicable, the exposure of private health information across the entire user base represents a meaningful privacy breach for multi-user wger deployments (Github Advisory).

A proof-of-concept is publicly documented in the GitHub security advisory itself, demonstrating the attack in two steps. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.036% (11th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Github Advisory, Feedly).

1. Register an account: The attacker registers or obtains a valid account on the target wger instance.
2. Enumerate routine IDs: Since routine IDs are sequential integers, the attacker iterates over plausible pk values (e.g., 1–1000) to identify routines belonging to other users.
3. Wait for cache population: The attack requires the victim (user A) to have previously accessed one of the five vulnerable endpoints, populating the cache. Given the 1-month TTL, this is likely for active users.
4. Send unauthenticated-ownership request: The attacker (user B) sends a GET request to a vulnerable endpoint such as GET /api/v2/routine/5/structure/ using their own valid session token.
5. Receive victim's cached data: Because the cache key is routine-api-structure-5 (no user ID), the server returns a cache hit containing user A's routine structure without performing any ownership check.
6. Repeat for other endpoints: The attacker repeats the process for /date-sequence-display/, /date-sequence-gym/, /logs/, and /stats/ to harvest comprehensive workout and health data for the target user (Github Advisory).

• Network: Repeated authenticated GET requests to /api/v2/routine/{pk}/structure/, /logs/, /stats/, /date-sequence-display/, or /date-sequence-gym/ from a single user account targeting multiple different pk values in rapid succession, especially PKs not owned by that user.
• Logs: Application access logs showing a user account accessing routine API endpoints for routine IDs that do not belong to them; absence of corresponding self.get_object() authorization checks in application logs (cache hits bypass this code path).
• Behavioral: A single account systematically iterating over sequential routine IDs across the five affected endpoints, consistent with automated enumeration (Github Advisory).

The vulnerability is fixed in wger version 2.5, which refactors all five cache key generation functions to include the user ID (e.g., routine-api-structure-{user_id}-{pk}), ensuring cache entries are user-scoped. The patch commit is available at e964328784e2ee2830a1991d69fadbce86ac9fbf. Organizations unable to upgrade immediately should consider disabling caching for the affected routine API endpoints or implementing API-layer access controls to restrict routine endpoint responses to the owning user. Upgrading to wger ≥ 2.5 is the recommended remediation (Patch Commit, Github Advisory).