CVE-2026-46438: Broken Object Level Authorization in wger Workout Log Endpoint

The open-source fitness manager wger exposes standard REST API endpoints to facilitate the tracking of workouts, routines, and user logs. Within its multi-tenant architecture, isolation is enforced at the controller level to prevent cross-user data interference.

In versions prior to 2.6, the api validation layer failed to enforce appropriate object-level authorization on several relational fields. Specifically, the model controller representing workout logs neglected to map parent-child relationships for the slot_entry entity.

Consequently, an authenticated user could issue requests containing database identifiers referencing assets owned by unrelated accounts. The backend accepted and committed these associations, breaking logical boundaries between tenants and enabling unauthorized state modification.

The Django REST Framework integration in wger uses a custom superclass named WgerOwnerObjectModelViewSet to automate owner-based authorization checks during model creation and modification. This controller interceptor evaluates properties provided in the API request against a registration list returned by get_owner_objects().

Prior to the implementation of the security patch, the WorkoutLogViewSet class in wger/manager/api/views.py only evaluated Routine and WorkoutSession fields for ownership validation. The slot_entry parameter, which links a specific log entry to a scheduled slot, was omitted from the list.

Because of this omission, when an authenticated client submitted a POST request containing a foreign slot_entry identifier, the system only validated ownership of the auxiliary routine identifier. The database saved the record, creating an Insecure Direct Object Reference (IDOR) state.

A secondary failure point exists in the query logic of the calculation engine located in wger/manager/models/slot_entry.py. The SlotEntry.get_config_data() method loaded all logs connected to the slot entry without validating their ownership. This design defect allowed the attacker's unauthorized records to pollute the automated training statistics generation pipeline.

To understand the technical changes, we examine the diff from the security patch applied to the code repository. The primary vulnerability resided in the registration parameters of the REST API controller.

# Vulnerable configuration in wger/manager/api/views.py
class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):
    def get_owner_objects(self):
        return [(Routine, 'routine'), (WorkoutSession, 'session')]

The patched viewset updates the return value of get_owner_objects to enforce validation checks against both the slot_entry and the recursive next_log fields.

# Patched configuration in wger/manager/api/views.py
class WorkoutLogViewSet(WgerOwnerObjectModelViewSet):
    def get_owner_objects(self):
        return [
            (Routine, 'routine'),
            (WorkoutSession, 'session'),
            (SlotEntry, 'slot_entry'),
            (WorkoutLog, 'next_log'),
        ]

Furthermore, model-level security guarantees were added within the database persistence interface in wger/manager/models/log.py. This ensures that even if API controllers are bypassed, direct model updates fail authorization validation.

# Patched validation in wger/manager/models/log.py
def save(self, *args, **kwargs):
    if self.routine and self.routine.user != self.user:
        return
    if self.slot_entry and self.slot_entry.slot.day.routine.user != self.user:
        return

An attacker requires a valid authenticated session to exploit this vulnerability. The vulnerability requires no administrative privileges and can be triggered using a standard client connection.

The attack process initiates with sequential scanning of integer identifiers associated with targeted slot_entry objects. Because these identifiers are auto-incrementing, discovery is straightforward.

Upon identifying a target identifier, the attacker constructs a POST payload specifying a legitimate routine identifier owned by the attacker alongside the target slot_entry identifier owned by the victim. The application server processes the request, bypasses checking on the slot_entry property, and logs the malicious telemetry.

The primary impact of this vulnerability is unauthorized data manipulation and integrity corruption within user profiles. Because wger automates progress tracking via calculation engines, the presence of unauthorized workout logs corrupts the statistical baseline of the targeted athlete.

Specifically, the progressive-overload scheduling module relies on historical weight and repetition limits to project upcoming goals. Injecting extreme or incorrect values forces the application to calculate unreachable targets, impairing the usability of the software.

While the vulnerability does not lead directly to arbitrary code execution or data extraction, the complete loss of multi-tenant integrity across relational workout records introduces a significant trust barrier in shared deployments.

The primary remediation mechanism is the installation of wger version 2.6. This release closes the authorization gap in the API controllers and enforces defensive validation constraints inside the underlying models.

For system administrators who cannot perform immediate platform updates, temporary relief is achievable by auditing database transactions and filtering suspicious logs. Running targeted database queries can expose instances where log records point to incompatible parent accounts.

Additionally, Web Application Firewalls (WAF) can be configured to block suspicious requests directed at the API endpoint. Inspecting incoming request bodies for mismatching parameters helps reduce the potential attack surface.