Rocket.Chat’s users.deactivateIdle function marks a user as inactive for idleness but does not revoke previously issued login tokens. Users deactivated through this method can continue to call authenticated REST endpoints using the old token, allowing unauthorized access until the token expires or is manually invalidated. The vulnerability exists in all versions prior to 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, and permits any party possessing a valid token to perform actions on behalf of that idle‑deactivated account.

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—obtained through 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.