Rodauth EUVD-2026-68126

The attacker must possess at least one valid JWT access token for the target account - the bypass does not work without an existing token, eliminating unauthenticated exploitation. The target application must have Rodauth's jwt_refresh feature explicitly enabled in its configuration; applications using only the core jwt feature without jwt_refresh are not exposed. The application must run Rodauth below version 2.47.0. Non-POST HTTP methods must reach the jwt_refresh route, meaning a reverse proxy or WAF that enforces POST-only on that path would block the attack. The scope is limited to the account associated with the possessed token; there is no privilege escalation or cross-account impact.

The CVSS 4.0 base score of 5.1 (AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N) reflects a network-reachable but limited-impact vulnerability. PR:H signals that exploitation requires prior possession of a valid JWT access token - the attacker must already have authenticated at some point. The low confidentiality and integrity sub-scores indicate the impact is confined to unauthorized session prolongation rather than data exfiltration or system compromise. No EPSS data was provided. The absence of CISA KEV listing and no observed public exploit code suggest this is not being actively mass-exploited. The real-world risk is meaningful primarily in scenarios where short-lived JWT tokens are relied upon as a compensating control - for instance, post-revocation or post-logout access containment - since the bypass undermines that guarantee. For applications that do not use JWT-based sessions or do not have the jwt_refresh route enabled, there is no exposure.

An attacker who obtained a short-lived JWT access token - through legitimate login, session capture, or credential theft - sends a GET request to the application's jwt_refresh endpoint with that token in the Authorization header. Rodauth processes the request, and despite returning a 405 error body, inadvertently includes a fresh JWT in the response Authorization header. The attacker extracts this new token and repeats the process indefinitely, maintaining persistent access even after the original token's intended expiry.