EUVD-2026-39098Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Deactivated user requires own OAuth token (PR:L); bearer use is trivial (AC:L); no user interaction needed; limited confidentiality and integrity impact, no availability impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Rocket.Chat is an open-source, secure, fully customizable communications platform. 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, Rocket.Chat does not revoke OAuth bearer or refresh tokens when a user is deactivated. A deactivated user can continue using an existing OAuth access token, and can also mint a fresh access token from an existing refresh token. This vulnerability is fixed in 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.
AnalysisAI
Insufficient OAuth token revocation in Rocket.Chat allows deactivated user accounts to maintain persistent, unauthorized access to the platform. Affected 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 fail to invalidate bearer or refresh tokens upon account deactivation, meaning a deactivated user can continue accessing resources with an existing bearer token or mint entirely new bearer tokens from a retained refresh token. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the post-deactivation access window is unbounded unless tokens naturally expire.
Technical ContextAI
The vulnerability is rooted in CWE-613 (Insufficient Session Expiration), a class of flaws where an application does not properly invalidate authentication credentials when a session or account lifecycle event occurs. In OAuth 2.0, bearer tokens grant time-limited access while refresh tokens allow minting new bearer tokens without re-authentication. Rocket.Chat's deactivation flow - intended to revoke a user's access - does not trigger revocation of either token type in its authorization server logic. This means the OAuth token store is not synchronized with the account state store, breaking a fundamental security assumption: that deactivating an account immediately terminates all active sessions and authorization grants. CPE data is not provided in the input, but the advisory scope covers the Rocket.Chat server application across multiple maintained release branches (7.x and 8.x).
RemediationAI
Upgrade Rocket.Chat to one of the patched releases: 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, or 7.10.12, selecting the version that corresponds to the currently deployed release branch. Full details and links are available in the GitHub Security Advisory at https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-39hg-492f-3c4f. If immediate patching is not feasible, administrators should manually audit and revoke active OAuth tokens for any deactivated accounts via the Rocket.Chat admin panel or directly in the database (the oauth_tokens collection in MongoDB) as a compensating control - note this requires identifying all deactivated users and is operationally error-prone as a sustained practice. Additionally, configuring short bearer token TTLs at the OAuth application level reduces the exploitation window for the bearer-token vector, though it does not address the refresh-token minting path without also purging refresh tokens. Deleting (rather than deactivating) accounts forces immediate session invalidation but may have data-retention implications depending on organizational policy.
Same weakness CWE-613 – Insufficient Session Expiration
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today