CVE-2026-46437: 
Python vulnerability analysis and mitigation

CVE-2026-46437 is an insufficient session expiration and improper authentication vulnerability in wger, a free open-source workout and fitness manager. Bearer-style API credentials — specifically Django REST Framework (DRF) authtokens and JWT refresh tokens — remain valid after a user logs out or changes their password, allowing an attacker who has stolen such a token to continue accessing protected /api/v2/* endpoints indefinitely. The vulnerability affects all wger versions prior to 2.6 and was published on October 7, 2026. It carries a CVSS v3.1 base score of 4.8 (Medium) (Github Advisory, wger Advisory).

The root cause is classified under CWE-287 (Improper Authentication) and CWE-613 (Insufficient Session Expiration). The logout handler in wger/wger/core/views/user.py only clears the Django session cookie via django_logout() and does not revoke DRF authtokens stored in the authtoken_token table. Similarly, the password change flow updates the password hash but neither deletes existing DRF tokens nor invalidates JWT refresh tokens, as there is no server-side revocation list or token versioning in wger/settings/settings_global.py or wger/settings/main.py. An attacker who has previously obtained a victim's Authorization: Token <key> header value or JWT refresh token can replay it against any /api/v2/* endpoint — the DRF token persists until manually deleted, while the JWT refresh token remains usable until its natural expiry (default 86,400 seconds / 24 hours) (wger Advisory).

An attacker who obtains a victim's DRF authtoken or JWT refresh token — for example via a man-in-the-middle attack on a public Wi-Fi network — retains full API-level access to the victim's account even after the victim logs out and changes their password. This allows the attacker to read private fitness and health data (confidentiality impact) and perform any API mutations permitted to the victim's account, such as modifying workout logs or nutrition plans (integrity impact). Availability is not impacted, and the scope is limited to the victim's own account data without lateral movement potential (wger Advisory, Github Advisory).

A Python proof-of-concept exploit is publicly available in the GitHub security advisory, demonstrating token persistence using Django's test client and DRF APIClient against a local wger instance. The PoC is classified as poc_code with high confidence by Feedly threat intelligence. The EPSS score is approximately 0.185% (8th percentile), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog inclusion at this time. Exploitation requires the attacker to have already obtained a valid token (e.g., via network interception), making it non-automatable and requiring high attack complexity (wger Advisory, Github Advisory).

1. Token acquisition: Intercept a victim's API traffic (e.g., via AitM on a shared network) to capture the Authorization: Token <drf_token> header or obtain a JWT refresh token from a /api/v2/token response.
2. Confirm victim changes credentials: Wait for or observe the victim changing their password via POST /en/user/password/change — this is the expected remediation action that should, but does not, invalidate the stolen token.
3. Replay DRF authtoken: Send a GET request to a protected endpoint such as /api/v2/weightentry/ with the header Authorization: Token <stolen_drf_token>. The server returns HTTP 200, confirming continued access.
4. Replay JWT refresh token: Send POST /api/v2/token/refresh with the body {"refresh": "<stolen_refresh_token>"}. The server returns HTTP 200 with a new access token, enabling continued authenticated API calls.
5. Exfiltrate or manipulate data: Use the valid access token to enumerate and read private user data (workout logs, nutrition plans, body weight entries) or perform mutations on the victim's account via any /api/v2/* endpoint (wger Advisory).

• Network: API requests to /api/v2/* endpoints (e.g., /api/v2/weightentry/, /api/v2/token/refresh) originating from IP addresses inconsistent with the legitimate user's known locations, particularly shortly after a password change event.
• Logs: Server access logs showing successful (HTTP 200) authenticated API calls using a DRF token or JWT access token after a corresponding password change event (POST /en/user/password/change returning 302) from the same user account.
• Logs: Repeated POST /api/v2/token/refresh requests using the same refresh token value after a user password change, successfully returning new access tokens.
• Application: DRF authtoken records in the authtoken_token database table that have not been rotated despite recent password change events for the associated user account (wger Advisory).

Upgrade to wger version 2.6 or later, which patches this vulnerability by implementing JWT refresh token rotation on every use combined with blacklist-after-rotation, making refresh tokens single-use so a leaked token is invalidated after the next refresh call. The release notes also recommend setting REFRESH_TOKEN_LIFETIME to a shorter value (e.g., 3000 seconds) in prod.env. As an immediate workaround prior to upgrading, administrators should manually delete all existing DRF authtokens from the authtoken_token table for affected users and review JWT refresh token expiration policies. Users who suspect credential compromise should manually rotate their API key via the user settings page (wger Release 2.6, Github Advisory).