Concrete CMS versions older than 9.5.3 allow an authenticated dashboard user who has permission to edit a single Page Type to modify the configuration of any other Page Type. The flaw occurs because the Page Type update controller loads the target type by a user‑supplied identifier without calling the canEditPageType() authorization check. The update_page_type token is validated, but it is only action‑scoped, so it does not restrict which Page Type can be targeted. This bypass lets an authorized user extend their privileges to other Page Types, compromising the integrity of content structure and potentially enabling further attacks. The weakness is categorized as CWE-639 and CWE-862The CVSS v4.0 score of 5.1 indicates moderate severity, while the EPSS score of less than 1% suggests a very low likelihood of exploitation. The vulnerability is not listed in CISA KEV. Exploitation requires a logged the ability to submit the update form, so the attack vector is primarily internal or through a compromised administrative account. Although the exploitation probability is low, the ability to modify configuration beyond authorized scope represents a significant internal risk for organizations using broad-ranging dashboard permissions.

All installations of Concrete CMS running any version older than 9.5.3 are affected. The issue resides in the core CMS and is not limited to a specific module or add‑on.

Risk assessment indicates a moderate CVSS score of 5.1 and an EPSS probability of less than 1%, suggesting exploitation is unlikely but still possible. The lack of an Object‑level authorization check allows a malicious or misconfigured dashboard user to change the configuration of any Page Type they are not normally permitted to modify, escalating their operational impact within the CMS. Because the vulnerability requires the user to be authenticated and possess a valid edit‑page type token, the attack vector is internal or via a compromised administrative account, and the vulnerability is not recorded in CISA KEV.