CVE-2026-27835: wger Information Disclosure Vulnerability

CVE-2026-27835 Overview

A security vulnerability has been identified in wger, the free, open-source workout and fitness manager application. In versions up to and including 2.4, the RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet API endpoints return all users' repetition configuration data due to improper access control. The vulnerable get_queryset() methods call .all() instead of filtering results by the authenticated user, resulting in an Insecure Direct Object Reference (IDOR) vulnerability that allows any registered user to enumerate every other user's workout structure.

Critical Impact

Any authenticated user can access sensitive workout and fitness data belonging to all other users in the system, potentially exposing personal health routines and fitness goals.

Affected Products

• wger Workout Manager versions up to and including 2.4
• wger installations using the vulnerable RepetitionsConfigViewSet API endpoint
• wger installations using the vulnerable MaxRepetitionsConfigViewSet API endpoint

Discovery Timeline

• 2026-02-26 - CVE-2026-27835 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-27835

Vulnerability Analysis

This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), commonly known as an Insecure Direct Object Reference (IDOR). The flaw exists in how the wger application handles API requests for repetition configuration data. When authenticated users query the RepetitionsConfigViewSet or MaxRepetitionsConfigViewSet endpoints, the application fails to scope the database query to only return records belonging to the requesting user.

The vulnerable code returns unfiltered results from the database by calling .all() on the queryset, which retrieves every user's repetition configuration records. This architectural oversight means that user isolation is not enforced at the data access layer, allowing horizontal privilege escalation where users can access data belonging to other users at the same privilege level.

Root Cause

The root cause of this vulnerability lies in the missing user-based filtering in the get_queryset() method implementation within the RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet classes. Instead of filtering the queryset to return only objects owned by the authenticated user (e.g., queryset.filter(user=request.user)), the code returns all objects in the database. This is a common developer oversight in Django REST Framework implementations where ownership checks are accidentally omitted.

Attack Vector

The vulnerability is exploitable over the network by any authenticated user. An attacker would simply need to:

1. Create a valid user account on the wger instance
2. Authenticate to obtain an API token
3. Make API requests to the vulnerable endpoints
4. Receive and parse the response containing all users' repetition configuration data

The attack requires low complexity and no user interaction, making it easily exploitable for data harvesting purposes.

         """
         Return objects to check for ownership permission
         """
-        return [(Routine, 'workout')]
+        return [(Routine, 'routine')]


 class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):

Source: GitHub Commit Update

The fix properly corrects the ownership permission check to use the correct relationship attribute.

Detection Methods for CVE-2026-27835

Indicators of Compromise

• Unusual API request patterns to /api/v2/repetitionsconfig/ or similar endpoints with high frequency
• Single user accounts making bulk data retrieval requests that return significantly more records than expected for a single user
• API access logs showing authenticated users receiving response payloads containing data for multiple user IDs
• Anomalous data export patterns or scraping behavior from authenticated sessions

Detection Strategies

• Implement API request logging that captures response sizes and user IDs contained in responses
• Monitor for authenticated sessions making systematic enumeration requests across API endpoints
• Deploy anomaly detection for API endpoints that flags when response data contains records for users other than the requester
• Review Django REST Framework viewset implementations for missing queryset filtering

Monitoring Recommendations

• Enable detailed API audit logging on all wger ViewSet endpoints
• Set up alerts for API responses exceeding normal payload sizes for single-user operations
• Monitor authentication patterns for accounts that appear to be harvesting data
• Implement rate limiting on repetition configuration endpoints to slow enumeration attempts

How to Mitigate CVE-2026-27835

Immediate Actions Required

• Upgrade wger to a version containing commit 1fda5690b35706bb137850c8a084ec6a13317b64 or later
• If unable to upgrade immediately, restrict API access to trusted users only
• Review API access logs to determine if the vulnerability has been exploited
• Consider temporarily disabling the affected API endpoints until a patch can be applied
• Notify users if unauthorized access to their workout data may have occurred

Patch Information

The wger project has addressed this vulnerability in commit 1fda5690b35706bb137850c8a084ec6a13317b64. The fix implements proper user-based filtering in the affected ViewSet classes to ensure that get_queryset() returns only objects belonging to the authenticated user. Organizations running wger should update to the latest version that includes this security fix.

For detailed patch information, refer to:

• GitHub Commit Update
• GitHub Security Advisory

Workarounds

• Implement API gateway rules to restrict access to the vulnerable endpoints until patching is complete
• Add custom middleware to filter API responses and remove records not belonging to the requesting user
• Temporarily disable the RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet endpoints if they are not critical to operations
• Restrict user registration to prevent new accounts from being created to exploit the vulnerability

# Configuration example - Restrict API access via nginx until patched
# Add to nginx server configuration
location ~ ^/api/v2/(repetitionsconfig|maxrepetitionsconfig) {
    # Temporarily deny access to vulnerable endpoints
    deny all;
    return 403;
}