GHSA-V25J-WQCW-FVHJ: Uncontrolled Resource Consumption via Unbounded Date Sequences in wger

wger is an open-source web application designed to manage personal workouts, routines, and nutritional plans. The core functionality relies on generating and tracking dates for exercise routines over defined periods. The application exposes a REST API allowing users to programmatically create and modify these workout schedules.

A vulnerability identified as GHSA-V25J-WQCW-FVHJ exists within the routine processing logic, specifically categorized as CWE-400 (Uncontrolled Resource Consumption). The vulnerability occurs when the application parses user-supplied start and end dates for a given routine.

By supplying abnormally large date ranges, an authenticated user forces the application to compute massive date sequences in memory. This unbounded computation directly exhausts server resources. The resulting Denial of Service (DoS) affects all users of the specific instance by consuming available application worker threads.

The root cause lies in the algorithmic complexity of the date_sequence property within the Routine model. This property generates an iterative sequence of dates spanning the provided start and end boundaries. Historically, this generation was implemented using an iterative loop mechanism without an artificial bound.

The application previously validated only that the end date occurred chronologically after the start date. No constraints restricted the total mathematical difference between the two dates. This oversight allowed the creation of timebounds spanning several centuries.

When a routine with a massive date range is queried, the backend initiates a sequence generation that executes tens of thousands of loop iterations. Each iteration performs resource-intensive database lookups and object instantiation for workout slots, log entries, and user configurations.

The combination of unbounded iterations and heavy per-iteration computational cost causes the application worker handling the request to hang indefinitely. This locks the underlying thread, eventually starving the web server of available workers to serve legitimate traffic.

Prior to the patch, the application lacked proper duration bounds checking at the API boundary. The database model's clean() method was incomplete and did not sufficiently protect the endpoints driven by the Django REST Framework. This permitted malicious objects to persist in the database.

The remediation introduced in commit 5f07a4473e2c32d298c8cdd31d78e5107840039c enforces a hard limit of 120 days on any newly created or modified routine. The fix centralizes this logic within the RoutineSerializer class.

# Patch implementation in RoutineSerializer validate method
if (end - start).days > Routine.MAX_DURATION_DAYS:
    raise serializers.ValidationError(
        {'end': f'A routine cannot span more than {Routine.MAX_DURATION_DAYS} days.'}
    )

While the serializer validation prevents external creation via the API, the underlying date_sequence loop remains algorithmically unconstrained. If an attacker bypasses the API layer or preexisting malicious data exists in the database, the iteration loop will still trigger the resource consumption condition.

Exploitation requires the attacker to possess a valid, authenticated session within the target wger application. The attacker initiates the exploit by sending a crafted POST request to the /api/v1/routine/ endpoint. The payload contains a start and end date with a massive differential.

Once the malicious routine record is committed to the database, the attacker must trigger the sequence generation logic. The attacker accesses endpoints such as /api/v1/routine/<id>/date-sequence-display/ or /api/v1/routine/<id>/stats/. These views attempt to render the requested data, firing the vulnerable property.

A proof-of-concept exists within the developer's regression tests. The PoC establishes a routine starting in the year 2024 and ending several centuries later. Accessing the created object locks the processing thread immediately.

Because the vulnerability ties up application workers rather than crashing the process, the server simply stops responding to subsequent requests. Administrators observe high CPU usage and full connection queues at the reverse proxy layer.

The primary impact is a severe degradation of availability. A single authenticated request can fully consume a worker thread. A low-bandwidth attacker making concurrent requests can rapidly exhaust all available web workers.

The condition creates an Application Exhaustion Flood, mapped to MITRE ATT&CK technique T1499.003. Since the malicious routine persists in the database, the Denial of Service condition becomes persistent if automated background processes attempt to aggregate statistics across all system routines.

The vulnerability does not directly compromise confidentiality or integrity. No arbitrary code execution or data exfiltration is achieved. The blast radius is limited strictly to system availability.

Remediation efforts may require system downtime. Administrators must identify and manually remove the offending records from the underlying database before normal operation can resume if the exploit was triggered persistently.

System administrators must update their wger deployments to a version incorporating commit 5f07a4473e2c32d298c8cdd31d78e5107840039c. The patch enforces a 120-day maximum duration limit on routine creation via the application's REST framework.

Because the patch relies on the Django REST Framework serializer, administrators must sanitize existing database entries. Any pre-existing routines with durations exceeding the 120-day limit remain viable vectors for resource exhaustion.

Administrators should execute SQL queries against the manager_routine table to identify anomalous records. Records where the mathematical difference between the end and start dates exceeds expected limits should be truncated or deleted to restore full application stability.

Network administrators can implement Web Application Firewall (WAF) rules to inspect incoming POST and PATCH requests directed at the /api/v1/routine/ endpoint. The WAF can block payloads containing unusually long date ranges before they reach the backend application.