CVE-2026-27839: 
Python vulnerability analysis and mitigation

CVE-2026-27839 is an Insecure Direct Object Reference (IDOR) vulnerability in the wger workout manager application, classified as "IDOR in nutritional_values endpoints exposes private dietary data via direct ORM lookup." It affects wger versions up to and including 2.4, and was published on February 26, 2026 by maintainer rolandgeider via a GitHub Security Advisory. The flaw allows any authenticated user to access other users' private dietary and health data by supplying arbitrary primary key (PK) values to three API endpoints. It carries a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory, Github Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): three nutritional_values action endpoints in wger/nutrition/api/views.py perform direct ORM lookups using Model.objects.get(pk=pk) without applying any user-scoped filtering or object-level permissions. In Django REST Framework (DRF), detail actions do not automatically enforce queryset filtering — the correct pattern is to call self.get_object(), which applies the viewset's user-scoped queryset. The three vulnerable endpoints are GET /api/v2/nutritionplan/{pk}/nutritional_values/, GET /api/v2/meal/{pk}/nutritional_values/, and GET /api/v2/mealitem/{pk}/nutritional_values/. Because PKs are sequential integers and user registration is open by default, an attacker can enumerate all records trivially (GitHub Advisory, Patch Commit).

Successful exploitation allows any authenticated user to read sensitive personal health data belonging to other users, including daily caloric intake, protein, carbohydrate, fat, fiber, and sodium intake, as well as full meal composition and ingredient quantities. There is no impact on data integrity or system availability, but the confidentiality breach is significant given the sensitive nature of dietary and health information. An attacker with a valid account could systematically enumerate all nutrition plans across the entire user base, constituting a bulk exposure of private health records (GitHub Advisory).

A proof-of-concept (PoC) exploit is publicly available in the GitHub Security Advisory, demonstrating automated enumeration of all nutrition plans using a simple Python script with a valid API token. No victim interaction is required, and exploitation only requires a low-privilege authenticated account. 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.025% (0.000250), indicating a low near-term exploitation probability (GitHub Advisory, Github Advisory).

1. Obtain credentials: Register or obtain a valid account on the target wger instance (registration is open by default).
2. Retrieve API token: Authenticate to the wger API and obtain a personal API token (e.g., via the user settings page or /api/v2/token/login/).
3. Enumerate nutrition plans: Send authenticated GET requests to /api/v2/nutritionplan/{pk}/nutritional_values/ with incrementing integer PK values (e.g., 1 through 1000), using the attacker's own token in the Authorization: Token <ATTACKER_TOKEN> header.
4. Collect exposed data: For each HTTP 200 response, parse the JSON body to extract the victim's energy (kcal), protein, carbohydrates, carbohydrates_sugar, fat, fat_saturated, fiber, and sodium values.
5. Repeat for meals and meal items: Repeat the enumeration against /api/v2/meal/{pk}/nutritional_values/ and /api/v2/mealitem/{pk}/nutritional_values/ to retrieve full meal composition and ingredient-level data for all users (GitHub Advisory).

• Network: High volume of sequential GET requests to /api/v2/nutritionplan/{pk}/nutritional_values/, /api/v2/meal/{pk}/nutritional_values/, or /api/v2/mealitem/{pk}/nutritional_values/ from a single IP or user account, especially with incrementing integer PK values.
• Logs: API access logs showing a single authenticated user token accessing nutritional_values endpoints for a large number of distinct PKs in a short time window; HTTP 200 responses for PKs not belonging to the requesting user.
• Behavioral: A single user account generating an unusually high number of API requests compared to normal usage patterns, particularly targeting nutritional data endpoints (GitHub Advisory).

Upgrade wger to version 2.5 or later, which replaces the vulnerable direct ORM calls with self.get_object() in all three affected viewsets (NutritionPlanViewSet, MealViewSet, MealItemViewSet). If an immediate upgrade is not possible, apply the fix manually by replacing NutritionPlan.objects.get(pk=pk), Meal.objects.get(pk=pk), and MealItem.objects.get(pk=pk) with self.get_object(), or add explicit user filters such as NutritionPlan.objects.get(pk=pk, user=self.request.user). Administrators should also review API access logs to identify any unauthorized access to nutritional data that may have occurred prior to patching (GitHub Advisory, Patch Commit).