Rocket.Chat versions prior to 8.5.0, 8, 8.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12 do not invalidate existing OAuth bearer or refresh tokens when a user account is deactivated. As a result, a deactivated account can continue to use an old access token for authentication and can generate a new access token from an existing refresh token, enabling unauthorized access to the system. This flaw stems from inadequate token revocation logic and is classified under CWE‑613.

Rocket.Chat instances running any of the affected releases listed above are susceptible. The flaw involves OAuth token handling, a feature available in all Rocket.Chat installations.

The CVSS score of 2.3 indicates low overall severity, largely because the flaw does not enable remote code execution or compromise of confidentiality beyond the scope of a deactivated user that already possesses a token. However, in scenarios where an attacker has previously compromised an account and has updated it to deactivated status, the attacker can continue to use the still‑valid token to access APIs and potentially sensitive data. The EPSS score is not available, so the likelihood of exploitation is unknown, but the issue is not listed in the CISA KEV catalog, suggesting no widespread exploitation has been reported. The attack vector is likely local or remote access through any OAuth‑enabled endpoint that accepts bearer tokens, and the vulnerability is exploitable in any environment where authentication tokens are issued and not tied to the current active status of the user account.