CVE-2026-81902 is a high severity (CVSS 8.1) cross-site request forgery flaw in Concrete CMS 9 through 9.5.2. The orphaned block removal action never validated a CSRF token, so a crafted link opened by an editor could delete all blocks on a page. Upgrade to the fixed release in the project's notes.
What's affected
The record covers Concrete CMS 9 through 9.5.2. The panel action called removeOrphanedBlocks did not validate a CSRF token. An authenticated user who holds edit permission on the target page is the person who has to load the attacker's request.
The consequence described is bad because it is permanent. The request removes every block on the page's current version. Blocks that are not aliased to another page or to a scrapbook entry are also deleted from the global Blocks table and from their block type data table, so the content cannot simply be rolled back from the page versions screen.
Severity note: the record scores this 8.1 under CVSS 3.1. The Concrete CMS security team also gave it 7.1 under CVSS 4.0 and the description says so. As with the related Concrete CMS issues in this batch, the fix is in the 9.5.3 release notes the record points to. That page returned a 404 when I fetched it, so verify the fixed version in the project documentation.
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.
CSRF issues depend on what your editors do, not only on what the server exposes. Ask whether editors browse other sites while signed in to the dashboard, and whether the dashboard sits on a public address. Both raise the chance that a malicious page can reach a signed in session.
What to do now
- Upgrade Concrete CMS to the release the project names as the fix, then confirm the version.
- Take a current database and file backup before and after the upgrade. Content deleted from the Blocks tables is gone unless you have one.
- Ask editors to sign out of the dashboard when they are done and to avoid following unknown links while signed in.
- Restrict dashboard access by network or VPN where you can, so a forged request has less chance of arriving in a live session.
- After upgrading, test the orphaned block action on a staging copy to confirm it now refuses a request without a valid token.
Why it matters
CSRF, tracked as CWE-352, happens when a state changing action trusts the browser's session cookie and nothing else. A token that only the real page knows is the standard defence. Here the check was missing from one panel action, so the browser's cookie alone was enough.
The pattern is common because a CMS has hundreds of actions and each one has to remember to check. A single miss on a destructive action is enough. This one is notable because it is not a cosmetic change. It deletes content and its underlying data, so recovery depends on backups. The record does not say this CVE is exploited in the wild.
Quick check
Who has to click for this to work?
An authenticated user with edit permission on the target page, per the record. The attacker does not need an account.
Why do backups matter here?
Blocks not aliased elsewhere are removed from the shared tables as well, so page version history alone may not bring the content back.
Sources
Last reviewed: 18 October 2026.
