EUVD-2026-39097Severity 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
AV:N for REST API access, AC:H because exploitation depends on the specific idle-deactivation workflow and retained token; PR:L because the attacker previously held valid user credentials on the instance.
Primary rating from Vendor (github).
CVSS VectorVendor: github
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
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 allows users deactivated through users.deactivateIdle to keep using already-issued login tokens. A user that an administrator has marked inactive for idleness can still access authenticated REST endpoints with the old 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 session expiration in Rocket.Chat allows users administratively deactivated via the users.deactivateIdle mechanism to continue accessing authenticated REST API endpoints using previously-issued login tokens that were never invalidated. All Rocket.Chat deployments across the 7.x and 8.x release branches prior to the fixed versions are affected. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires three specific, concurrent conditions: (1) an administrator must have deactivated the target user account specifically via the users.deactivateIdle administrative API - this does not apply to manual deactivation through the admin UI or account deletion, which may follow different token-handling code paths; (2) the deactivated user must still hold a previously-issued, unexpired login token from a session that was active before deactivation; and (3) the user must be aware of their deactivation and choose to continue using the old token against the REST API. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 score of 2.3 (AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N) accurately reflects a low-priority issue. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A former employee whose Rocket.Chat account was deactivated by an administrator using the users.deactivateIdle API retains their login token from an active session. Because the platform does not invalidate the token on idle-deactivation, the user continues to send REST API requests - reading messages, accessing files, or modifying channel content - as if their account remained active. … |
| Remediation | Upgrade to one of the vendor-patched releases: 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, or 8.0.6 in the 8.x branch, or 7.13.8 and 7.10.12 in the 7.x branch. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-613 – Insufficient Session Expiration
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today