wger EUVD-2026-94333

Requires an authenticated user who holds the gym.gym_trainer permission (or gym.manage_gym / gym.manage_gyms) AND belongs to the SAME gym as the victim - the dispatch() method enforces same-gym membership and returns HttpResponseForbidden for cross-gym targets, so the attack cannot cross gym boundaries. No non-default configuration, feature flag, or user interaction is needed; the deactivate/activate endpoints behave this way by default. The limiting factors defenders should weigh: the attacker must already possess a trainer-or-higher account in the victim's gym (so this is an insider/lower-privileged-role escalation, not remote-unauthenticated), and the amplifying factor is that get_permission_list() always lets a gym manager create trainer accounts, so a manager-provisioned trainer can turn around and disable that manager. Affected: wger prior to 2.6.

This is a genuine but bounded-risk privilege-escalation flaw (CWE-269), not a high-CVSS-but-hollow finding, yet also not an internet-wide emergency. The input CVSS of 7.1 (High) rests on CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N: network-reachable, low attack complexity, and only low-privilege authentication (a gym_trainer account) with no user interaction, which makes exploitation trivially reliable for anyone who already holds a trainer role. Countervailing signals keep real-world risk moderate: no EPSS score was provided, the CVE is NOT on CISA KEV ('no public exploit identified' does not apply - a PoC IS published), and the product's deployment footprint is low (niche self-hosted open-source fitness manager). The threat model is therefore insider/lower-tier-operator abuse within a shared gym, not mass remote exploitation. One metric tension to verify: the input assigns C:L, but account deactivation discloses no data - this analysis assesses C:N and treats the true impact as integrity (unauthorized modification of account state), so the 7.1 may slightly overweight confidentiality. Bottom line: prioritize patching for any multi-tenant/multi-role wger deployment, but the limited product prevalence and required trainer-level access cap the blast radius.

An attacker holding only the gym_trainer role (which a gym manager can themselves create, enabling a created-trainer-turns-on-creator scenario) sends a single GET request to /en/user/<manager_user_id>/deactivate for a gym_manager or general_gym_manager in the same gym, immediately setting is_active=False and locking that higher-privileged user out. A working proof-of-concept and attack steps are published in the GHSA advisory. The CVSS AV:N/AC:L/PR:L/UI:N profile means the attack is a low-complexity, no-interaction web request requiring only low-privilege authentication.