CVE-2026-81901: Concrete CMS 9.2.0 to 9.5.2 is vulnerable to stored XSS due to missing authorization in the `PUT /pages/{cID}` endpoint
In Concrete CMS 9.2.0 through 9.5.2, the REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) did not enforce page-property, page-template, or page-type authorization. A user granted only content-editing rights on a page could therefore alter its properties, template, and type through the API, and could set the headerextracontent attribute, which is rendered unescaped into the head element of every page, to persist JavaScript that executed in the browser of every visitor, including higher-privileged reviewers who approve the page version. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.2 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
Affected Software
Event History
Frequently Asked Questions
Which users can exploit this issue?
A user with content-editing rights on a page can exploit the missing authorization checks. They do not need page-property, page-template, or page-type permissions to alter those settings through the affected API endpoint.
What access and interaction are required for the stored XSS to execute?
The attacker needs authenticated content-editing access to a page and must use the PUT /ccm/api/1.0/pages/{cID} endpoint. They can store JavaScript in header_extra_content; it executes when a visitor loads a page where that unescaped content is rendered, including when a higher-privileged reviewer approves the page version.
How can administrators identify potentially affected content?
Review pages editable by content-only users for unexpected changes to page properties, templates, or page types, and inspect the header_extra_content attribute for untrusted or unexpected script content. The affected release range is Concrete CMS 9.2.0 through 9.5.2.