https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 02:29:51 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-384227 EUVD-2026-384227 https://cve.radiocsirt.org/vuln/euvd-2026-384227 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45161 <p>wger is a free, open-source workout and fitness manager. Prior to version 2.6, the `trainer_login` view in wger accepts GET requests and executes `django_login()` without any CSRF protection, because Django&#39;s `CsrfViewMiddleware` only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single `&lt;img&gt;` tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer&#39;s session to an arbitrary user account. Version 2.6 fixes the issue.</p> <p>wger is a free, open-source workout and fitness manager. Prior to version 2.6, the `trainer_login` view in wger accepts GET requests and executes `django_login()` without any CSRF protection, because Django&#39;s `CsrfViewMiddleware` only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single `&lt;img&gt;` tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer&#39;s session to an arbitrary user account. Version 2.6 fixes the issue.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45161 https://cve.radiocsirt.org/vuln/ghsa-xf64-4pmc-h8qf <p><strong>Affected:</strong> PyPI: wger</p> <p>### Summary</p> <p>The `trainer_login` view in wger accepts GET requests and executes `django_login()` without any CSRF protection, because Django&#39;s `CsrfViewMiddleware` only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single `&lt;img&gt;` tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer&#39;s session to an arbitrary user account.</p> <p>### Details</p> <p>**File**: `wger/core/views/user.py`, approximately lines 161-210</p> <p>```python # VULNERABLE - no @require_POST, no request.method == &#39;POST&#39; guard # CsrfViewMiddleware is bypassed because CSRF enforcement only applies to # unsafe HTTP methods (POST, PUT, PATCH, DELETE) def trainer_login(request, user_pk): ... django_login(request, user, backend=&#39;django.contrib.auth.backends.ModelBackend&#39;) return HttpResponseRedirect(...) ```</p> <p>Because the view handles GET, Django&#39;s CSRF middleware does not validate any token. An attacker can place `&lt;img src=&#34;https://wger.target/en/user/2/trainer-login&#34;&gt;` on any web page. When an authenticated trainer&#39;s browser loads that page, it issues the GET request with the session cookie attached (SameSite=Lax does not block same-site top-level navigation and subresource hops triggered by same-origin redirects). The server executes `django_login()` and issues a new session cookie binding the trainer to the victim user.</p> <p>Playwright-verified in Chromium 147: the SameSite byp…</p> <p><strong>Affected:</strong> PyPI: wger</p> <p>### Summary</p> <p>The `trainer_login` view in wger accepts GET requests and executes `django_login()` without any CSRF protection, because Django&#39;s `CsrfViewMiddleware` only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single `&lt;img&gt;` tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer&#39;s session to an arbitrary user account.</p> <p>### Details</p> <p>**File**: `wger/core/views/user.py`, approximately lines 161-210</p> <p>```python # VULNERABLE - no @require_POST, no request.method == &#39;POST&#39; guard # CsrfViewMiddleware is bypassed because CSRF enforcement only applies to # unsafe HTTP methods (POST, PUT, PATCH, DELETE) def trainer_login(request, user_pk): ... django_login(request, user, backend=&#39;django.contrib.auth.backends.ModelBackend&#39;) return HttpResponseRedirect(...) ```</p> <p>Because the view handles GET, Django&#39;s CSRF middleware does not validate any token. An attacker can place `&lt;img src=&#34;https://wger.target/en/user/2/trainer-login&#34;&gt;` on any web page. When an authenticated trainer&#39;s browser loads that page, it issues the GET request with the session cookie attached (SameSite=Lax does not block same-site top-level navigation and subresource hops triggered by same-origin redirects). The server executes `django_login()` and issues a new session cookie binding the trainer to the victim user.</p> <p>Playwright-verified in Chromium 147: the SameSite byp…</p> https://cve.radiocsirt.org/vuln/ghsa-xf64-4pmc-h8qf