CVE-2026-27835: 
Python vulnerability analysis and mitigation

CVE-2026-27835 is a Broken Object-Level Authorization (BOLA/IDOR) vulnerability in the wger workout manager application affecting versions up to and including 2.4. The flaw allows any authenticated user to read other users' repetition and max-repetitions workout configuration data via unfiltered API endpoints. It was disclosed on February 26, 2026, by researcher ByamB4 via a GitHub Security Advisory. The vulnerability carries a CVSS v3.1 base score of 4.3 (Medium) (Github Advisory, wger Advisory).

The root cause is a missing user-ownership filter in two Django REST Framework viewsets — RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet — located in wger/manager/api/views.py (lines 499 and 518). Both viewsets call RepetitionsConfig.objects.all() and MaxRepetitionsConfig.objects.all() respectively, returning every user's records instead of filtering by the authenticated user. This is classified as CWE-639 (Authorization Bypass Through User-Controlled Key). All sibling viewsets in the same file (e.g., WeightConfigViewSet, SetsConfig, RestConfig, RiRConfig) correctly apply the filter slot_entry__slot__day__routine__user=self.request.user, making this an isolated oversight. Because wger allows open registration by default and uses sequential integer IDs, full enumeration of all users' workout configurations is trivially achievable (wger Advisory).

Successful exploitation results in unauthorized disclosure of other users' workout structure data, including slot entry IDs, iteration values, operations, step counts, repeat flags, and requirements JSON. The vulnerability is limited to confidentiality impact — no data modification or deletion is possible, and there is no availability impact. While the exposed data is workout metadata rather than highly sensitive personal information, it constitutes a privacy breach for all registered users of an affected wger instance (wger Advisory, Github Advisory).

A public proof-of-concept is included in the security advisory itself, consisting of simple authenticated HTTP GET requests to /api/v2/repetitions-config/ and /api/v2/max-repetitions-config/. No exploit kits or advanced tooling are required. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.04% (0.000250), placing it in the 12th percentile for exploitation likelihood (Github Advisory).

1. Register or obtain credentials: Register an account on the target wger instance (registration is open by default) or use any existing low-privilege account to obtain an API token.
2. Retrieve API token: Authenticate via the wger API or web interface to obtain a valid token (e.g., Token YOUR_TOKEN).
3. Query the vulnerable endpoint: Send an authenticated GET request to the repetitions config endpoint:

   GET /api/v2/repetitions-config/
   Authorization: Token YOUR_TOKEN

4. Enumerate all users' data: The API returns all users' repetition configurations without filtering. Use the sequential IDs in the response to enumerate specific records via /api/v2/repetitions-config/<id>/.
5. Repeat for max-repetitions: Send the same request to /api/v2/max-repetitions-config/ to retrieve all users' max-repetitions configurations.
6. Extract workout structure: Parse the JSON response to extract slot entry IDs, iteration values, operations, step counts, repeat flags, and requirements JSON belonging to other users (wger Advisory).

• Network: Unusual or high-volume GET requests to /api/v2/repetitions-config/ or /api/v2/max-repetitions-config/ from a single authenticated user, especially with sequential ID enumeration patterns.
• Logs: API access logs showing a single user token repeatedly querying repetitions config endpoints and accessing records belonging to other users' routines; requests returning large paginated result sets from low-privilege accounts.
• Behavior: A newly registered account immediately querying repetitions or max-repetitions config endpoints without prior workout data creation activity.

The fix is available in wger version 2.5 and later, introduced via commit 1fda5690b35706bb137850c8a084ec6a13317b64. The patch adds the correct user-ownership filter to both affected viewsets:

def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

Instances unable to upgrade immediately should implement API-level access controls or a reverse proxy rule to restrict access to these endpoints, and review access logs for unauthorized enumeration activity prior to patching (wger Advisory, Patch Commit).

The vulnerability was reported by researcher ByamB4 and published by wger maintainer rolandgeider on February 26, 2026. The advisory was picked up by standard vulnerability tracking feeds including Red Hat CVE database, ENISA EUVD, and GitLab advisory databases shortly after disclosure. No significant broader media coverage or notable researcher commentary beyond the original advisory has been identified (wger Advisory).