CVE-2026-73431: Vulnerability-Lookup Auth Bypass Flaw

CVE-2026-73431 Overview

CVE-2026-73431 is an authentication weakness in Vulnerability-Lookup affecting its account activation and password-recovery workflows. The application generated stateless signed tokens containing only the user's login. The signature and age were validated, but the application did not record whether a token had already been consumed. A captured activation or recovery link therefore remained valid for the entire TOKEN_VALIDITY_PERIOD, even after the password had been changed. The same token mechanism was reused across activation and recovery, since tokens were not bound to a specific purpose. This flaw is classified under [CWE-294: Authentication Bypass by Capture-replay].

Critical Impact
An attacker who captures a single valid activation or recovery link can replay it to reset the victim's password repeatedly and take over the account, without needing the existing password or an authenticated session.

Affected Products

Vulnerability-Lookup (pre-patch versions of the account activation and password-recovery flow)
Deployments issuing stateless signed tokens without single-use enforcement
Instances relying on TOKEN_VALIDITY_PERIOD as the sole invalidation control

Discovery Timeline

2026-08-12 - CVE-2026-73431 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73431

Vulnerability Analysis

The vulnerability stems from stateless token handling in the account activation and password-recovery flows. Tokens carried only the user's login and relied on signature validity plus an age check. The server never tracked whether a token had been redeemed. As a result, a token remained a valid credential-reset artifact for its full validity window, even after being successfully used to change a password. Because tokens were not scoped to a purpose, an activation link could be substituted into the recovery workflow and vice versa. Exploitation does not require the victim's password or session, only possession of a currently valid link obtained through interception, logs, referrer leakage, or shared URLs.

Root Cause

The root cause is missing state tracking on issued tokens. The design assumed that signature and expiry validation were sufficient. There was no per-token nonce stored on the user record, and no consumption step tied to the password-setting operation. In addition, a single token type served multiple workflows, breaking purpose-binding assumptions.

Attack Vector

An attacker who obtains a valid activation or recovery URL replays it against the password-set endpoint within TOKEN_VALIDITY_PERIOD. Each replay sets a new password of the attacker's choosing. The victim's own password change does not invalidate the captured token. The attacker can therefore reacquire control after the victim recovers the account, as long as the original token has not expired.

python

            if not user:
                return jsonify({"error": "Invalid API token"}), 403

+            # Enforce the same account-state gate as the REST API
+            # (see website/web/api/v1/common.py:auth_func): an inactive or
+            # unconfirmed account must not reach the stream, otherwise a key
+            # issued before confirmation could subscribe to pre-moderation data.
+            if not user.is_active:
+                return jsonify({"error": "Account is not active."}), 403
+            if not user.is_confirmed:
+                return jsonify({"error": "Account is not confirmed."}), 403
+
            # Store the authenticated user in Flask's `g` object
            g.current_user = user
        except SQLAlchemyError as e:

Source: Vulnerability-Lookup commit bef8372. This patch fragment enforces active and confirmed account state on the SSE stream, part of the broader authentication hardening (AUTH-VULN-01) that accompanies the token single-use fix.

Detection Methods for CVE-2026-73431

Indicators of Compromise

Multiple successful password-set operations for the same account within a single TOKEN_VALIDITY_PERIOD window
Repeated requests to the activation or recovery endpoint carrying identical token values
Password changes originating from IP addresses or user agents that differ from the account owner's baseline
Account recovery events immediately followed by further password changes without user-initiated recovery requests

Detection Strategies

Correlate application logs for reuse of the same activation or recovery token across separate HTTP requests
Alert when a password-set operation succeeds for an account that already completed one within the token validity window
Flag cross-workflow token use where a token issued for activation is presented against the recovery endpoint or vice versa

Monitoring Recommendations

Ingest Vulnerability-Lookup web logs into a centralized log platform and retain them for the full TOKEN_VALIDITY_PERIOD
Monitor for anomalous bursts of password-reset activity and unexpected is_active or is_confirmed state transitions
Track new API key issuance following password changes to detect attacker persistence after account takeover

How to Mitigate CVE-2026-73431

Immediate Actions Required

Update Vulnerability-Lookup to the patched revision that introduces purpose-bound tokens and single-use nonces
Invalidate all outstanding activation and password-recovery tokens after upgrade
Force password resets for any accounts suspected of exposure to captured recovery links
Rotate API keys and session tokens tied to affected accounts

Patch Information

The fix is available in the upstream commit bef8372. The patch introduces purpose-bound tokens and a random nonce whose SHA-256 digest is stored on the user account. The nonce is invalidated after a successful password change, making tokens single-use. Issuing a new token invalidates any previously issued token, and the password-setting operation explicitly consumes the token before committing the account change. The same commit also gates the SSE stream on active and confirmed account state.

Workarounds

Shorten TOKEN_VALIDITY_PERIOD to the minimum operationally acceptable value to reduce the replay window
Restrict access to the activation and recovery endpoints behind network controls where feasible
Instruct users to avoid forwarding, pasting, or archiving activation and recovery URLs

bash

# Configuration example: reduce token validity window as a temporary control
export TOKEN_VALIDITY_PERIOD=900   # 15 minutes, in seconds
# Restart the Vulnerability-Lookup service after applying the change
systemctl restart vulnerability-lookup