Concrete CMS CVE-2026-8205

Exploitation requires two concurrent conditions: the target must be running Concrete CMS 9.5.0 or below, and the site must have a Calendar Block deployed with event-level access restrictions configured on at least one calendar (i.e., some events are marked restricted or private). The AT:P designation in the CVSS 4.0 vector formally encodes this prerequisite - default or open-access calendar deployments are not impacted because there is no restricted data to disclose. Authentication is not required (PR:N in CVSS 4.0), and no user interaction is needed. The practical limiting factors are the specific Calendar Block configuration and the sensitivity of the calendar data; organizations not using Concrete CMS Calendar Blocks with access controls have no exploitable surface regardless of version.

The vendor-assigned CVSS 4.0 score of 6.3 Medium is consistent with the impact profile: low confidentiality impact on the vulnerable component (VC:L), zero integrity or availability impact, and no scope change to subsequent systems. The AT:P attack requirement is the most significant risk-limiting signal - sites that deploy Calendar Blocks with entirely public events gain no exploitable surface, meaning a non-trivial portion of the installed base is unaffected. No EPSS probability score was provided in the source data, so quantitative exploitation likelihood cannot be stated. The absence of a CISA KEV listing and the lack of any reported public exploit code further reduce immediate urgency. Cross-referencing AV:N/AC:L/PR:N/UI:N against the AT:P constraint yields a realistic threat profile: low-effort opportunistic scanning is feasible for any attacker who can reach the endpoint, but impact is bounded to calendar event metadata rather than credentials, PII, or system access. This is a genuine but low-priority remediation item for most organizations unless restricted calendar data is operationally sensitive.

An unauthenticated attacker identifies a Concrete CMS 9.5.0 installation with a Calendar Block deployed on a publicly accessible page, where the site administrator has restricted visibility of certain events. The attacker sends a direct HTTP GET or POST request to the action_get_events endpoint - no credentials, session token, or special tooling required - and receives the restricted event payload in the response because canView is never checked. No exploit code has been publicly released, but the attack requires only knowledge of the endpoint URL pattern, which is consistent across Concrete CMS deployments.