CVE-2026-81901 is a high severity (CVSS 8.7) missing authorization flaw in Concrete CMS 9.2.0 through 9.5.2. The REST API page update endpoint skipped property, template and page type checks, so a content editor could plant script that runs for every visitor. Upgrade to the fixed release named in the project's release notes.
What's affected
The record lists Concrete CMS 9.2.0 through 9.5.2. The endpoint involved is the REST API call that updates a page, under the 1.0 pages path of the API. A user who had been granted only content editing rights on a page could use it to change the page's properties, its template and its page type, none of which that role should be able to touch.
The record names no fixed version in its text, but its only reference is the 9.5.3 release notes, which suggests 9.5.3 is the release to move to. Confirm that against the project's documentation.
Severity note: the record's CVSS 3.1 score is 8.7 (High). The Concrete CMS security team separately scored it 7.2 under CVSS 4.0, and the description says so. Both are in the High band, but the numbers differ, so use the one your policy specifies.
How to check if you're exposed
Find the version of each Concrete CMS site. In the dashboard, the System and Settings area shows the installed version. From a shell on the server, you can read it from the site files or ask Composer if the site was installed that way:
composer show concrete5/core
If the version is anywhere from 9.2.0 up to and including 9.5.2, treat the site as affected. If you are on 9.5.3 or later, check the release notes to confirm the fix for this CVE is listed. The release notes link in the CVE record returned a 404 for me, so the project's current documentation or release page is the place to verify.
Then ask who can use the API. The weakness needs an account that already has edit rights on at least one page, so list those accounts and groups. Also check whether the REST API is switched on at all. A site that has not enabled the API has a smaller exposure.
What to do now
- Upgrade Concrete CMS to the fixed release listed in the project's release notes, and confirm the version afterwards.
- If you cannot upgrade today, turn off the REST API or restrict the API clients and users who can reach it.
- Review which accounts have page edit rights, and remove rights that are no longer needed.
- Look at the header extra content attribute on your pages. It should be empty or contain only code you recognise. Remove anything you did not add.
- Check page version history for edits to properties or templates made by editor accounts that should not make such changes.
Why it matters
This is a missing authorization problem, tracked as CWE-862. The API accepted a valid, logged in user but did not ask whether that user was allowed to change the specific things in the request. Moving the check into the page editing screens but not into the API leaves two doors to one room with only one lock.
The impact grows because of where the data lands. The record says the header extra content attribute is rendered without escaping into the head element of every page. Anything stored there runs in the browser of every visitor, including reviewers with higher privileges who approve page versions. That is how a low privilege editor can reach a high privilege session. The record does not list this CVE as exploited in the wild.
Quick check
Does a visitor need an account to abuse this?
The record says the user needs content editing rights on a page. It is not an anonymous issue, but any compromised or malicious editor account is enough.
Is turning off the API a complete fix?
It removes the endpoint described in the record, but upgrading is the real fix. Treat the shutdown as a stopgap and still check stored content.
Sources
Last reviewed: 18 October 2026.
