The vulnerability allows an attacker to read another user's workout routines via the API when a routine has already been cached. The API checks a cache before calling get_object, but the cache keys are scoped only by the primary key, not the user ID. As a result, once a user accesses a routine, an attacker with knowledge of the primary key can retrieve the cached response without performing an ownership check. This results in unauthorized disclosure of personal fitness data, a breach of confidentiality for users of wger. The weakness maps to CWE‑639.

The flaw affects the wger open-source workout manager compiled under the vendor wger‑project:wger. Versions up to and including 2.4 are impacted, as the code prior to commit e964328784e2ee2830a1991d69fadbce86ac9fbf implements the incorrect cache key. Subsequent releases containing the patch have resolved the issue.

With a CVSS score of 3.1 the vulnerability is classified as moderate. The EPSS score is below 1 %, indicating a very low likelihood of exploitation at present, and it is not listed in the CISA Known Exploited Vulnerabilities catalog. The likely exploitation path requires the attacker to know the routine’s primary key and have access to the API, either by having been authenticated or by observing an authenticated request. If the API is protected, the attacker would need to observe or obtain a valid session; if not, unauthenticated users may still be able to retrieve cached routines. In either case, the missing user ID in the cache key allows the attacker to bypass ownership checks and retrieve confidential user data.