CVE-2026-81915 Overview
CVE-2026-81915 is an Insecure Direct Object Reference (IDOR) vulnerability in Concrete CMS versions below 9.5.3. The flaw resides in the Types::submit() dashboard controller, which loads and saves a Page Type based on a user-supplied ptID parameter without invoking canEditPageType(). A signed-in dashboard user with permission to edit one Page Type can modify the configuration of Page Types outside their assigned authorization boundary. The associated update_page_type CSRF token is action- and user-scoped rather than object-scoped, so it does not restrict which Page Type may be targeted. The Concrete CMS security team assigned this issue a CVSS v4.0 base score of 5.1.
Critical Impact
Authenticated dashboard users can alter Page Type configurations they were never authorized to edit, undermining tenant and role separation in Concrete CMS deployments.
Affected Products
- Concrete CMS versions below 9.5.3
- Concrete CMS dashboard Types controller (Types::submit() method)
- Deployments relying on Page Type role separation for multi-editor environments
Discovery Timeline
- Vulnerability reported by Andrew Gonzalez to the Concrete CMS security team
- 2026-09-11 - CVE-2026-81915 published to NVD
- 2026-09-15 - Last updated in NVD database
Technical Details for CVE-2026-81915
Vulnerability Analysis
The vulnerability is a broken object-level authorization flaw classified under [CWE-639]. Concrete CMS exposes a dashboard endpoint that handles Page Type updates through the Types::submit() controller. The controller trusts the ptID parameter supplied in the request body and loads the corresponding Page Type object directly. It then persists changes without verifying that the authenticated user has permission to edit that specific Page Type.
Because authorization is enforced only at the feature level and not at the object level, any user permitted to reach the Page Type editor can pivot to modify unrelated Page Types. This breaks tenant boundaries in multi-editor Concrete CMS installations where administrators grant scoped Page Type editing rights to different roles or content teams.
Root Cause
The root cause is the absence of a canEditPageType() permission check inside Types::submit() before the loaded Page Type is written back to storage. Authorization logic exists in the CMS but is not invoked on this code path. The update_page_type anti-CSRF token is validated, but the token is scoped to the action and the user rather than to a specific ptID value. As a result, the token does not constrain the object the request operates on.
Attack Vector
An attacker must first hold valid dashboard credentials with permission to edit at least one Page Type. From an authenticated session, the attacker submits a legitimate Page Type update request but substitutes the ptID parameter with the identifier of a Page Type outside their assigned scope. The controller processes the request, and the target Page Type configuration is overwritten. No user interaction from a victim is required, and the attack completes over the network against the dashboard endpoint. See the ConcreteCMS Version 9.5.3 Release Notes for the vendor's description.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-81915
Indicators of Compromise
- Dashboard POST requests to the Page Type update endpoint where the submitted ptID does not match a Page Type the requesting user is authorized to edit
- Unexpected modifications to Page Type configuration entries in the Concrete CMS database, particularly changes performed by low-privilege editor accounts
- Audit log entries showing Page Type edits by users who historically only edit a narrow subset of Page Types
Detection Strategies
- Enable and centrally forward Concrete CMS dashboard audit logs, then correlate the acting user identity against the ptID values in successful update requests
- Build a baseline of which users legitimately edit which Page Types, and alert on deviations from that baseline
- Inspect web server logs for repeated ptID enumeration patterns in requests to the Types::submit() endpoint
Monitoring Recommendations
- Monitor Page Type configuration change events for out-of-hours or bulk modifications by non-administrative accounts
- Track newly created or modified Page Types and compare the acting user to the Page Type's assigned owners and editors
- Alert on HTTP 200 responses to update_page_type submissions immediately followed by unexplained rendering or template changes on production pages
How to Mitigate CVE-2026-81915
Immediate Actions Required
- Upgrade all Concrete CMS installations to version 9.5.3 or later
- Audit existing Page Type configurations for unauthorized changes since the earliest possible exploitation window
- Review and tighten dashboard user permissions so that only trusted roles retain any Page Type editing capability
Patch Information
Concrete CMS addressed the issue in version 9.5.3 by adding the missing object-level canEditPageType() authorization check inside the Types::submit() dashboard controller. Details are documented in the ConcreteCMS Version 9.5.3 Release Notes. Administrators running any 9.x release prior to 9.5.3 should treat the upgrade as the primary remediation.
Workarounds
- Restrict dashboard access to a small, trusted set of administrators until the upgrade to 9.5.3 is applied
- Temporarily remove Page Type edit permissions from lower-privileged editor roles to reduce the attack surface
- Place the Concrete CMS dashboard behind additional network controls such as VPN or IP allowlisting to reduce exposure of the vulnerable endpoint
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
