CVE-2026-27839: wger Fitness Auth Bypass Vulnerability

CVE-2026-27839 Overview

CVE-2026-27839 is an Insecure Direct Object Reference (IDOR) vulnerability in wger, a free, open-source workout and fitness manager. In versions up to and including 2.4, three nutritional_values action endpoints fetch objects via Model.objects.get(pk=pk) — a raw ORM call that bypasses the user-scoped queryset. Any authenticated user can read another user's private nutrition plan data, including caloric intake and full macro breakdown, by supplying an arbitrary primary key (PK).

Critical Impact

Authenticated users can access sensitive personal health and nutrition data belonging to other users, leading to privacy violations and potential exposure of dietary information.

Affected Products

• wger Workout Manager versions up to and including 2.4

Discovery Timeline

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

Technical Details for CVE-2026-27839

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 the nutrition API views where three nutritional_values action endpoints directly query the database using the user-supplied primary key without verifying that the requesting user has authorization to access that specific nutrition plan.

The vulnerable code pattern uses Django's raw ORM call NutritionPlan.objects.get(pk=pk) which retrieves any nutrition plan from the database based solely on the provided primary key. This bypasses the application's intended user-scoped access controls, allowing any authenticated user to enumerate and retrieve nutrition plans belonging to other users.

Root Cause

The root cause is improper access control implementation in the Django REST Framework API views. Instead of using the framework's built-in get_object() method which respects the view's queryset filtering and permission classes, the code directly queries the NutritionPlan model without any ownership validation. This architectural oversight allows horizontal privilege escalation where authenticated users can access resources belonging to other users.

Attack Vector

An attacker with a valid authenticated session can exploit this vulnerability by manipulating the primary key parameter in API requests to the nutritional_values endpoints. By iterating through sequential or predictable primary key values, an attacker can enumerate and exfiltrate private nutrition plan data from all users in the system. The attack requires network access and low-privilege authentication.

# Vulnerable code pattern (before fix)
# Source: https://github.com/wger-project/wger/commit/29876a1954fe959e4b58ef070170e81703dab60e
         Return an overview of the nutritional plan's values
         """
         serializer = NutritionalValuesSerializer(
-            NutritionPlan.objects.get(pk=pk).get_nutritional_values()['total'],
+            self.get_object().get_nutritional_values()['total'],
         )
         return Response(serializer.data)

Detection Methods for CVE-2026-27839

Indicators of Compromise

• Unusual API request patterns to /api/*/nutritional_values/ endpoints with sequential or randomized primary key values
• Single user accounts making requests for nutrition plan data with diverse primary keys not belonging to their account
• High volume of API requests to nutrition endpoints from a single authenticated session
• Access log entries showing successful responses to nutrition API endpoints where the requested PK differs from the user's own data

Detection Strategies

• Implement API request logging that correlates requested resource PKs with the authenticated user's owned resources
• Monitor for anomalous access patterns where users request resources outside their normal ownership scope
• Deploy Web Application Firewall (WAF) rules to detect IDOR attack patterns including sequential PK enumeration
• Enable audit logging for all nutrition plan access events with user attribution

Monitoring Recommendations

• Configure alerting for high-frequency API requests to nutritional_values endpoints from individual user sessions
• Establish baseline metrics for normal user access patterns to nutrition data and alert on deviations
• Review application logs for successful data retrieval where the requesting user ID does not match the resource owner

How to Mitigate CVE-2026-27839

Immediate Actions Required

• Upgrade wger to a version containing commit 29876a1954fe959e4b58ef070170e81703dab60e or later
• Review application logs to identify potential exploitation attempts prior to patching
• Audit all API endpoints for similar IDOR vulnerabilities where raw ORM queries bypass user-scoped access controls
• Consider notifying affected users if unauthorized data access is detected

Patch Information

The vulnerability has been fixed in commit 29876a1954fe959e4b58ef070170e81703dab60e. The fix replaces the direct ORM query NutritionPlan.objects.get(pk=pk) with the Django REST Framework's self.get_object() method, which properly enforces the view's queryset filtering and ensures users can only access their own nutrition plan data.

For detailed patch information, see the GitHub Security Advisory and the fix commit.

Workarounds

• If immediate patching is not possible, implement additional middleware or decorator-based access control checks on the affected endpoints
• Temporarily disable the nutritional_values API endpoints until the patch can be applied
• Deploy a reverse proxy rule to restrict access to nutrition API endpoints to only allow requests where the PK matches the authenticated user's resources

# Example: Applying the fix pattern in Django REST Framework views
# Replace direct ORM queries with get_object() to enforce proper access control

# Before (vulnerable):
# NutritionPlan.objects.get(pk=pk).get_nutritional_values()

# After (secure):
# self.get_object().get_nutritional_values()
# This ensures the view's get_queryset() filtering is applied