CVE-2026-85387 in Concrete CMS
Summary
by MITRE • 09/17/2026
Concrete CMS before 9.5.4 re-authorized OAuth REST API requests from the bearer token alone and did not re-check the state of the account the token had been issued to. The resource server's authorization validator confirmed only that a token existed, had not expired, and had not been explicitly revoked, and deactivating a user did not revoke that user's outstanding tokens. As a result, a deactivated user retained full access to /ccm/api/1.0/* for the remaining lifetime of any token already issued to them. The same gap applied to accounts that had been deleted or locked pending a forced password reset. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Myq Larson for reporting.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.4 represents a critical flaw in the implementation of OAuth2-based REST API authentication, specifically concerning the lifecycle management of access tokens relative to user account status changes. The core technical deficiency lies in the resource server's authorization validator logic, which relies exclusively on the presence and validity of the bearer token itself rather than performing real-time checks against the current state of the associated user account. When an application receives a request containing a valid OAuth2 bearer token, the system verifies that the token exists within its database, has not exceeded its expiration time, and has not been explicitly revoked through standard revocation mechanisms. However, this validation process fails to cross-reference the token with the active status of the user identity it represents. Consequently, if an administrator deactivates a user account, deletes a user profile, or locks an account pending a forced password reset, the system does not automatically invalidate any outstanding access tokens previously issued to that specific identity. This architectural oversight creates a significant gap between administrative actions intended to restrict access and the actual enforcement of those restrictions at the API level.
From an operational perspective, this flaw allows deactivated, deleted, or locked users to retain full read and write capabilities over the Concrete CMS REST API endpoints located under /ccm/api/1.0/* for the entire remaining lifetime of their issued tokens. This persistence of access poses severe security risks, particularly in environments where user accounts are frequently disabled due to employee offboarding, policy violations, or compromised credentials awaiting reset. An attacker who has obtained a valid bearer token from such an account can continue to interact with sensitive administrative functions even after the account should logically be inaccessible. The impact is compounded by the fact that these tokens remain functional until they naturally expire according to their configured time-to-live settings, which may range from hours to days depending on system configuration. This delay provides a substantial window of opportunity for unauthorized data exfiltration, modification of content, or further exploitation of other vulnerabilities within the CMS ecosystem using the privileges associated with the compromised account type.
In terms of industry standard classifications, this vulnerability aligns closely with CWE-613, which describes Insufficient Session Expiration, as well as CWE-284, Improper Access Control, because the system fails to enforce proper restrictions on users when their authorization status changes. The attack vector is categorized under MITRE ATT&CK technique T1078, Valid Accounts, specifically relating to the persistence of access through valid credentials that should have been invalidated by administrative action. Although the CVSS v4.0 score assigned by the Concrete CMS security team was relatively low at 2.0 due to high complexity and required privileges for initial token acquisition, this scoring does not fully capture the severity of persistent unauthorized access in enterprise environments where account lifecycle management is critical. The vector indicates that while exploitation requires specific conditions such as a pre-existing valid token and potentially complex setup, once achieved, it results in low confidentiality impact but represents a fundamental failure in identity governance principles.
To mitigate this vulnerability, organizations running Concrete CMS versions earlier than 9.5.4 must upgrade to the patched version immediately where available. For environments unable to patch instantly, administrators should implement compensating controls such as shortening token expiration times to limit the window of opportunity for attackers. Additionally, integrating an external identity provider that supports dynamic client registration and real-time revocation lists can help enforce stricter access policies. It is also advisable to audit API logs regularly to detect unusual activity from deactivated accounts during this transition period. The vulnerability was responsibly reported by Myq Larson, highlighting the importance of thorough testing of authentication flows against account state changes in web application security assessments.