wger EUVD-2026-94335

Requires (1) a valid authenticated account on the target wger instance, (2) the attacker owning at least one Routine of their own to satisfy the routine ownership check, and (3) knowledge or enumeration of the victim's numeric SlotEntry ID, submitted as the 'slot_entry' field in a POST /api/v2/workoutlog/ request. No user interaction or non-default configuration is needed - it works against default wger behavior. Exploitation is inherently limited to multi-user/shared instances (a single-user self-hosted deployment has no other user to target) and to integrity of workout-progression data only; it grants no read access, code execution, or availability impact.

This is a medium-severity authorization flaw (CWE-639, IDOR) whose real-world risk is moderate and bounded. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, base 6.5) is internally consistent with the description: network-reachable REST API, low attack complexity, and a requirement that the attacker hold a valid account (PR:L) - correctly NOT PR:N, since the attacker must authenticate and own at least one Routine to pass the partial ownership check. Impact is integrity-only (C:N/A:N): no data is read or exfiltrated and no availability is lost; the attacker can only corrupt a victim's auto-generated progressive-overload weight/repetition targets, so I:H reflects total corruption of a narrow data set rather than system-wide integrity loss. No EPSS score, SSVC decision, or CISA KEV entry was provided in the input, so exploitation-probability and automatability signals are UNKNOWN. A detailed proof-of-concept (full HTTP request) is published in the GHSA advisory, so working exploit code is effectively public, but public PoC is not the same as active exploitation - there is no evidence of in-the-wild use. Net assessment: a legitimate bug worth patching on multi-user instances, but a low-priority, low-urgency item relative to RCE/credential-theft classes - the authentication requirement, integrity-only impact, and niche multi-tenant deployment pattern all cap the real-world risk well below what a raw 'network, low-complexity' reading might suggest.

On a shared/multi-tenant wger instance, an authenticated user who knows or enumerates another user's sequential SlotEntry ID sends a single POST /api/v2/workoutlog/ request referencing their own Routine (to satisfy the ownership check) but the victim's slot_entry. The server never validates slot_entry ownership, so the forged log is persisted and silently folded into the victim's progression calculations, corrupting their recommended weights/reps. A copy-paste-ready PoC request is published in the vendor's GHSA advisory.