GHSA-7HGR-XVRR-XPW3: Session Persistence After Password Change in Nhost hasura-auth

The hasura-auth service manages identity and token issuance for the Nhost platform. It utilizes a dual-token architecture consisting of short-lived JSON Web Tokens (JWTs) for API access and long-lived refresh tokens stored persistently within the database.

The vulnerability, categorized as CWE-613 (Insufficient Session Expiration), affects the core session revocation lifecycle. Specifically, the password reset and modification routines omit the mandatory invalidation of active refresh tokens associated with the user account.

Standard security models dictate that cryptographic credential changes must uniformly terminate all concurrent sessions across all devices. The failure to enforce this global logout principle fundamentally undermines the utility of a password change as a reliable incident response mechanism.

Attackers who have previously acquired a valid refresh token maintain unimpeded system access regardless of subsequent password rotations. This structural flaw exposes user accounts to prolonged unauthorized access and potential data exfiltration.

The underlying flaw originates in the database queries utilized by the ChangePassword handler inside the hasura-auth Go service. The relevant file, services/auth/go/sql/query.sql, manages the state transition during a user-initiated credential update.

The legacy implementation executed a solitary UPDATE statement targeting the password_hash column within the auth.users table. This instruction accurately mutated the stored credential representation but terminated the database transaction without modifying dependent authentication tables.

Nhost's architecture isolates session state into dedicated relations, specifically the auth.refresh_tokens and auth.oauth2_refresh_tokens tables. Because the password mutation process did not explicitly reference or truncate these tables, all existing cryptographic tokens retained their active status in the database.

When a user presents a refresh token to the /token endpoint, the backend validation logic verifies the token's presence in the auth.refresh_tokens table. Since the password update logic neglected to purge these records, the server evaluates the compromised token as entirely valid and authorized.

Examining the vulnerable codebase reveals a straightforward procedural oversight in the SQL implementation. The original database operation isolated the password modification logic from the broader session management responsibilities.

The following snippet demonstrates the legacy SQL query responsible for executing the password modification. The transaction solely updates the credential hash without interacting with the necessary session state tables.

UPDATE auth.users
SET password_hash = $2
WHERE id = $1
RETURNING id;

Nhost developers addressed this vulnerability via commit 52c70664a7e92031e592b873471939b10ca18079. The remediation introduces a Common Table Expression (CTE) to guarantee atomicity between the password update and the token revocation operations.

The patched SQL logic bundles the user table update with unconditional deletions from both token tables. This ensures any successful credential change immediately invalidates all associated active sessions at the database tier.

WITH updated_user AS (
    UPDATE auth.users
    SET password_hash = @password_hash
    WHERE id = @id::uuid
    RETURNING id
),
revoked_refresh_tokens AS (
    DELETE FROM auth.refresh_tokens
    WHERE user_id = @id::uuid
),
revoked_oauth2_refresh_tokens AS (
    DELETE FROM auth.oauth2_refresh_tokens
    WHERE user_id = @id::uuid
)
SELECT id FROM updated_user;

Exploitation of GHSA-7HGR-XVRR-XPW3 requires an attacker to possess a pre-existing valid refresh token. Threat actors typically acquire these tokens through cross-site scripting (XSS) payloads, endpoint compromise, or the interception of unencrypted network traffic.

Upon discovering anomalous account activity, a prudent user typically initiates a password reset operation. In a standard implementation, this action severs all existing connection states and locks the attacker out of the environment immediately.

Due to the flawed database logic, the attacker retains the stolen refresh token and submits it to the Nhost /token endpoint. The server, finding the token intact within the auth.refresh_tokens table, willingly issues a new, valid JWT access token.

The attacker proceeds to authenticate against downstream API endpoints using the newly generated access token. This continuous issuance cycle allows the adversary to bypass the credential rotation and maintain persistent administrative control over the compromised account.

Mitigating this vulnerability required coordinated modifications across both the backend identity service and the client-side SDK. Relying exclusively on server-side token revocation leaves client applications in an inconsistent state, potentially causing operational loop failures or unexpected user experiences.

The nhost-js SDK received a dedicated architectural update to align client state with the server's post-rotation reality. Developers introduced the updateSessionFromResponseMiddleware component to intercept successful password update operations and trigger a local environment purge.

The typescript middleware evaluates HTTP responses originating from the /user/password endpoint. Upon detecting a successful 200 OK status, the SDK forcefully clears the local storage, mandating that the user authenticate with the newly established credentials.

if (url.endsWith('/user/password') && response.ok) {
  storage.remove();
  return response;
}

Organizations utilizing self-hosted Nhost deployments must upgrade to a version incorporating Pull Request #4192. Administrators managing legacy instances unable to upgrade immediately must manually truncate records within auth.refresh_tokens for any user undergoing a suspected account compromise.