CVE-2026-85387

Executive Summary

CVE-2026-85387 is an insufficient session/authorization-revalidation flaw (CWE-613) in Concrete CMS before 9.5.4, where OAuth REST API requests under /ccm/api/1.0/* were authorized on the basis of a bearer token alone without re-checking the current state of the issuing account. Deactivated, deleted, or locked accounts retained full API access for the entire residual lifetime of any previously issued token. Any organization running a self-hosted Concrete CMS instance below 9.5.4 with the REST API enabled and OAuth tokens issued is exposed to persistent unauthorized access after offboarding or account suspension.

Technical Analysis

The resource server's authorization validator, per the NVD description, performed only three checks: that a token (1) existed, (2) had not expired, and (3) had not been explicitly revoked. It did not re-check whether the account to which the token had been issued was still active. Additionally, "deactivating a user did not revoke that user's outstanding tokens."

This is a classic broken-authorization / stale-privilege problem in an OAuth 2.0 bearer-token architecture. The token itself becomes the sole root of trust. Once minted, its validity is decoupled from the lifecycle of the principal that owns it. The attack surface is the REST API namespace /ccm/api/1.0/*, which is reachable over the network without prior authentication beyond presenting the bearer token.

Two distinct conditions converge:

1. No token revocation on account-state change — deactivation, deletion, or a forced-password-reset lock does not cascade to the token store.
2. No account-state validation at request time — the validator trusts the token's existence without re-consulting the account's current status.

The CVSS v4.0 vector confirms the low impact ratings (VC:L/VI:L/VA:N) and no subsequent-system impact, indicating the token grants access scoped to what the account itself held — not privilege escalation beyond original grants. The AC:H and AT:P reflect that exploitation requires an attacker to already be in possession of a valid, unexpired, non-revoked token (obtained legitimately by the user prior to deactivation). PR:L and UI:A indicate a low-privileged actor and an active user role in triggering the mis-sequencing.

Note: Insufficient technical detail is available in the NVD description to specify exact internal function names, token-storage tables, or validator code paths; the analysis above is derived strictly from the stated behavioral gap.

Exploitation Scenarios

No public PoC available; attack chain is inferred from the vulnerability class (CWE-613) and the NVD description.

1. Reconnaissance / target identification. The attacker identifies a Concrete CMS deployment by fingerprinting the /ccm/api/1.0/ API namespace or standard Concrete CMS static assets. Public Shodan/Censys queries for Concrete CMS instances exposing the REST API narrow the target set.

2. Triggering the flaw class. The attacker must first hold a valid bearer token that was previously issued to an account. Per the description, this occurs naturally when a user is deactivated, deleted, or locked pending a forced password reset — the token remains outstanding and functional. A departing employee, a revoked contractor, or a compromised low-privilege account could all serve as the token source.

3. Payload/execution method. The attacker sends requests to /ccm/api/1.0/* with the captured or retained bearer token in the Authorization header. Because the validator checks only existence, expiry, and explicit revocation, the request succeeds despite the account being inactive.

4. Post-exploitation impact. The attacker retains the access rights the account possessed at issuance time for the remaining token lifetime. CVSS 4.0 rates this as Low confidentiality and Low integrity impact (VC:L/VI:L), with no availability impact. Impact is bounded by the original account's scope but persists until token expiry.

Impact Assessment

Business impact centers on offboarding and account-lifecycle failures: terminated employees, suspended accounts, and accounts locked under forced password reset retain API access. This defeats the security control of account deactivation. Affected systems are self-hosted Concrete CMS instances below 9.5.4 with the OAuth REST API enabled. Blast radius is bounded per-token — the leaked token carries only the permissions of its account (PR:L, VC:L/VI:L) and no subsequent-system impact (SC:N/SI:N/SA:N). The CVSS v4.0 score assigned by the Concrete CMS security team is 2.0 (Low), reflecting the requirement for pre-existing token possession and low per-incident impact. The risk is cumulative, not single-incident: in any environment where tokens are long-lived and account transitions are frequent, the window of stale access is effectively extended.

Detection Guidance

The following detections target anomalous use of bearer tokens against /ccm/api/1.0/*, particularly requests originating shortly after account-state changes or from unusual source contexts. Thresholds and account-state correlation should be tuned to each environment.

Sigma Rule

title: Concrete CMS API Access Using Bearer Token After Account Deactivation
id: 3b7f9c1e-8a42-4d1e-9c3a-ccm85387a01
status: experimental
description: Detects successful requests to the Concrete CMS REST API namespace using a bearer token whose issuing account was recently deactivated, deleted, or locked. Targets CVE-2026-85387.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-85387
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1078
  - cve.2026.85387
logsource:
  category: web
  product: concrete_cms
detection:
  selection_path:
    url.path|startswith: '/ccm/api/1.0/'
  selection_token:
    http.request.headers.authorization|startswith: 'Bearer '
  selection_response:
    http.response.status_code: 200
  timeframe: 15m
  condition: selection_path and selection_token and selection_response
fields:
  - client.ip
  - url.path
  - http.request.headers.authorization
  - user.name
falsepositives:
  - Legitimate active API integrations
level: medium

YARA Rule

rule CVE_2026_85387_Concrete_CMS_Stale_Bearer_Token
{
    meta:
        description = "Detects Concrete CMS REST API bearer-token handling patterns associated with CVE-2026-85387 (stale token authorization)."
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-85387"
        date = "2026-01-01"
        hash = "cve-2026-85387"
    strings:
        $api = "/ccm/api/1.0/" ascii wide
        $bearer = "Authorization: Bearer " ascii nocase
        $concrete = "concrete" ascii nocase
        $b1 = "isActive" ascii nocase
        $b2 = "is_active" ascii nocase
    condition:
        uint32be(0) != 0x504b0304 and
        $api and $bearer and $concrete and ($b1 or $b2)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-85387 Concrete CMS REST API Access via Stale Bearer Token"; flow:established,to_server; http.method; pcre:"/^(GET|POST|PUT|PATCH|DELETE)$/"; http.uri; content:"/ccm/api/1.0/"; http.header; content:"Authorization"; nocase; http.header; content:"Bearer "; nocase; reference:cve,2026-85387; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-85387; classtype:attempted-user; sid:2600085301; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=15m
  [ authentication where event.outcome == "success" and user.name != null ]
  [ http where url.path : "/ccm/api/1.0/*" and http.request.headers.authorization : "Bearer *" and http.response.status_code == 200 ]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined OR sourcetype=concrete_cms
| where like(url, "/ccm/api/1.0/%") AND (like(request_headers, "%Bearer %") OR like(cs_Authorization, "Bearer %"))
| eval has_token = if(match(coalesce(request_headers, cs_Authorization, ""), "Bearer\s+\S+"), 1, 0)
| where status=200 AND has_token=1
| stats count min(_time) as first_seen max(_time) as last_seen values(url) as urls by clientip, user
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="concrete_cms,cve-2026-85387,web,">
  <rule id="100853" level="7">
    <if_sid>31100</if_sid>
    <field name="url">^/ccm/api/1\.0/</field>
    <field name="Authorization">Bearer</field>
    <description>CVE-2026-85387: Concrete CMS REST API request with bearer token - possible stale-token authorization abuse</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authentication_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor workaround data was provided.

1. Immediate mitigations.

   • Disable the OAuth REST API (/ccm/api/1.0/*) if not operationally required, or restrict it at the reverse proxy/WAF to trusted source IPs.
   • Shorten bearer-token lifetimes to the minimum viable window.
   • On any account deactivation, deletion, or forced-password-reset lock, manually revoke all outstanding tokens for that account through the token store.
   • Audit currently issued tokens against the active-user list and revoke any bound to inactive accounts.

2. Patch/upgrade steps.

   • Upgrade Concrete CMS to 9.5.4 or later, which per the vendor CNA title addresses this re-authorization gap.
   • No patch is available from tracked sources at this time; treat 9.5.4 as the vendor-reported fixed version and validate against the official Concrete CMS release notes before deployment.
   • After upgrading, re-issue API tokens to force re-validation.

3. Long-term hardening.

   • Enforce account-state re-validation on every token-authenticated request, not just token existence/expiry.
   • Implement token revocation as a mandatory hook in the account lifecycle (deactivate, delete, lock).
   • Adopt short-lived access tokens with refresh rotation.
   • Log and alert on API access by tokens whose accounts are inactive.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-85387
• Concrete CMS official security advisories: https://www.concretecms.org/security
• CWE-613 — Insufficient Session Expiration: https://cwe.mitre.org/data/definitions/613.html
• CISA KEV catalog (not currently listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CVSS v4.0 specification: https://www.first.org/cvss/v4.0/specification-document

No known threat actor campaign, public exploit, Nuclei template, or exploit-in-the-wild evidence is associated with CVE-2026-85387 at the time of writing. EPSS has not yet scored this CVE; no EPSS value is asserted here.