Rocket.Chat’s users.deactivateIdle function marks a user as inactive for idleness but does not revoke previously issued login tokens. As a result, a deactivated user can continue to call authenticated REST endpoints using the old token, effectively maintaining unauthorized access. The flaw allows any party that possesses a valid token of an idle‑deactivated account to perform actions on behalf of that user until the token expires or is otherwise invalidated.

The vulnerability affects Rocket.Chat, specifically versions earlier than 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12. These releases allow the deactivation process to leave existing authentication tokens valid.

With a CVSS score of 2.3, the technical severity is considered low. The EPSS score is unavailable, and the vulnerability is not listed in CISA’s KEV catalog, indicating no known exploitation in the wild. Inferred from the description, the likely attack vector requires an attacker to possess a valid, inactive user’s token—obt token leakage, or a compromised account—after which they can execute authenticated API calls. The risk is limited to the lifespan of the token and the permissions granted to the account. Nonetheless this presents an opportunity for covert abuse of privileged operations while a user is marked inactive.