Critical Refresh Token Rotation Flaw Allows Token Reuse After Legitimate Rotation

A critical security vulnerability in the `POST /auth/refresh` endpoint fails to invalidate refresh tokens after rotation, allowing intercepted tokens to remain functional even after legitimate users have already rotated them. The flaw undermines the fundamental security guarantee of refresh token rotation—a mechanism designed to limit the window of exposure if a token is compromised.

The vulnerability operates through a documented exploitation sequence. When a user submits a valid refresh token (token_A), the server correctly issues a new access token and a fresh refresh token (token_B). However, the old token_A is not invalidated or is only unreliably invalidated. An attacker who obtained token_A through a compromised client, network interception, or exposed logs can subsequently call `POST /auth/refresh` with token_A and receive their own valid token pair—maintaining an active session even after the legitimate user has rotated credentials.

Security researchers flag this as a fundamental failure of token rotation as a defensive control. Effective rotation requires immediate and irrevocable invalidation of the previous token upon issuance of a new one. Without that guarantee, the rotation mechanism fails to prevent replay attacks, leaving authenticated sessions exposed to unauthorized access. Any application relying on this endpoint for session management faces elevated risk of account takeover if refresh tokens are intercepted through any attack vector.