CVE-2026-27838
Insecure Cache Key Allows Unauthorized Data Access in wger
Publication date: 2026-02-26
Last updated on: 2026-03-03
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wger | wger | to 2.4 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in wger, an open-source workout and fitness manager. In versions up to and including 2.4, five routine detail action endpoints use a cache that is keyed only by the primary key (pk) without including the user ID. Because of this, when a user accesses their routine via the API, the cached response for that routine is stored without verifying ownership. An attacker can exploit this by retrieving cached responses for the same pk, gaining access to another user's routine data without proper authorization.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of user-specific workout routine data. An attacker with knowledge of a valid routine primary key can retrieve cached data belonging to other users without needing proper permissions. This compromises user privacy and could expose sensitive fitness information.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
I don't know
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update wger to a version that includes the patch from commit e964328784e2ee2830a1991d69fadbce86ac9fbf or later.
This patch fixes the issue by including user ID in the cache key scope, preventing attackers from retrieving cached responses without ownership checks.