CVE-2026-85387 is a high severity flaw in Concrete CMS before 9.5.4. The REST API accepted OAuth bearer tokens without rechecking the account, so a deactivated user could keep API access until their tokens expired. Upgrade to 9.5.4 or later and revoke tokens for people who have left.
What's affected
- Product: Concrete CMS, OAuth REST API under
/ccm/api/1.0/. - Affected: versions before 9.5.4.
- Fixed: 9.5.4. The release notes page named in the record returned a not found error when I fetched it, so confirm the version on the Concrete CMS release page.
- The same gap applied to accounts that were deleted or locked pending a forced password reset.
Severity in the record: High, CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). The record carries 7.1 under CVSS v3.1. The Concrete CMS security team, quoted in the record, scored it 2.0 under CVSS v4.0, which is Low. The two scores differ a lot, so read both before setting your priority.
Weakness class: CWE-613 (Insufficient Session Expiration).
How to check if you're exposed
- Find your Concrete CMS version in the dashboard, or with
composer show concrete5/coreif you installed through Composer. - If it is below 9.5.4, you are affected.
- Ask whether you issue OAuth tokens to API clients, and whether any belong to people who left or were deactivated.
- Review API access logs for requests to
/ccm/api/1.0/from accounts that are marked inactive.
What to do now
- Upgrade Concrete CMS to 9.5.4 or later.
- Revoke OAuth tokens for accounts that were deactivated, deleted or locked, and review the list of active API clients.
- Shorten token lifetimes where the application allows it.
- Add a step to your offboarding checklist that removes API access explicitly.
- Check API logs for use of tokens belonging to inactive accounts since the account was disabled.
Why it matters
The resource server asked only three questions: does the token exist, has it expired, has it been revoked. It never asked whether the account behind the token was still allowed to act. Deactivating a user did not revoke their tokens. That is insufficient session expiration, CWE-613.
The practical risk depends on how long your tokens live and how much your API exposes. A former contractor with a valid token could keep reading and editing content. Offboarding should end every credential at once, and APIs should recheck the account on each request or at least on refresh. The record does not claim exploitation in the wild.
Quick check
Why do the two severity scores differ so much?
The record's 7.1 uses CVSS v3.1. The vendor's 2.0 uses CVSS v4.0 with different inputs, such as attack requirements and user action. Both are worth reading, and the fix is the same.
Sources
Last reviewed: 18 October 2026.
