The vulnerability identified as CVE-2026-27838 affects wger, a free and open-source workout and fitness management application. The issue arises from improper cache key scoping in versions up to and including 2.4. Specifically, five routine detail action endpoints utilize a caching mechanism that keys cached responses solely by the primary key (pk) of the routine object, without incorporating the user ID. This design flaw means that once a user accesses their routine via the API, the cached response for that routine is stored under a key that does not differentiate between users. Consequently, an attacker who knows or can guess the primary key of another user's routine can retrieve the cached response from the API without any authorization or ownership checks. The vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key). Exploitation requires network access and low privileges but does not require user interaction. The impact is limited to unauthorized disclosure of cached routine details, affecting confidentiality but not integrity or availability. The issue was addressed in a patch (commit e964328784e2ee2830a1991d69fadbce86ac9fbf) that scopes cache keys by both primary key and user ID, ensuring that cached data is only accessible to the rightful owner. No known exploits have been reported in the wild, and the CVSS v3.1 base score is 3.1, reflecting low severity due to limited impact and higher attack complexity.

The primary impact of this vulnerability is unauthorized disclosure of cached workout routine details belonging to other users. While the data exposed may be limited to fitness routines, it could include sensitive personal health or exercise information that users expect to remain private. The flaw does not allow modification or deletion of data, so integrity and availability are unaffected. However, unauthorized access to personal data can undermine user trust and violate privacy regulations, especially in jurisdictions with strict data protection laws. For organizations deploying wger, this could lead to reputational damage and potential compliance issues. The vulnerability requires an attacker to have network access and knowledge of valid primary keys, which may limit exploitation scope. Since no user interaction is needed, automated attacks could be feasible if primary keys are predictable or discoverable. Overall, the impact is low but non-negligible for privacy-conscious environments.

Organizations using wger should immediately upgrade to versions later than 2.4 where the patch has been applied to include user ID in cache keys. If upgrading is not immediately possible, administrators should consider disabling caching on the affected endpoints to prevent unauthorized cache retrieval. Implementing strict access controls and monitoring API access logs for unusual patterns can help detect exploitation attempts. Additionally, reviewing and hardening API authentication and authorization mechanisms to ensure ownership checks are enforced at all layers is recommended. Developers should audit other caching implementations to verify that cache keys are properly scoped by user identity to prevent similar issues. Employing rate limiting and anomaly detection on API endpoints can further reduce risk. Finally, informing users about the vulnerability and encouraging password hygiene can mitigate risks from credential compromise that might facilitate exploitation.