CVE-2026-81907 is a high severity (CVSS 7.1) cross-site request forgery flaw in Concrete CMS 9.5.2 and earlier. The Express Clear Entries function logs a failed CSRF check but carries on anyway, so an administrator visiting a hostile page could lose every entry of an entity. Upgrade to the fixed release.
What's affected
The record covers Concrete CMS 9.5.2 and below. The affected function is the Express Clear Entries action in the dashboard, handled by the delete_entries controller path under the Express entities section. The controller notes that the CSRF token check failed, but it does not stop. The destructive operation proceeds even when the token is missing or wrong.
An unauthenticated remote attacker still needs a victim. The record says an administrator who is signed in and visits an attacker controlled page can be made to delete all entries of an attacker chosen Express entity. The default Contact Express object ships with a fixed entity identifier, so the target can be found without dashboard access.
Severity note: the record scores this 7.1 on CVSS 3.1. The Concrete CMS security team scored it 6.1 under CVSS 4.0, as the description states. The record points to the 9.5.3 release notes. That page returned a 404 when fetched, so confirm the fix there.
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 see whether you use Express at all. In the dashboard, the Express entities area lists your data objects. Sites that collect contact form submissions through the default Contact object hold data worth protecting here, because that object's identifier is the same on every install.
What to do now
- Upgrade Concrete CMS to the fixed release the project lists, and verify the version.
- Back up the database now, including Express entity tables such as the Contact form entries, and test that the backup restores.
- If entries are business records, export them on a schedule so a clear action cannot remove your only copy.
- Have administrators use a separate browser profile for the dashboard, with no other tabs open.
- Review the logs for the delete_entries path and for CSRF failure messages. A logged failure followed by a deletion is the pattern this bug allows.
Why it matters
The weakness is CSRF, tracked as CWE-352, with a twist. The code did check the token. It wrote down that the check failed, and then ran the operation regardless. That is a logic error in the control flow rather than a missing control, and it is easy to miss in review because the check appears to be present.
The fixed identifier on the default Contact entity makes the target predictable. An attacker does not need to learn anything from the site first. For teams that rely on a contact form as a lead or enquiry inbox, the loss is direct and permanent without backups. The record does not list this CVE as exploited in the wild.
Quick check
The code logs the failure. Isn't that enough?
No. Logging is not enforcement. The request must be rejected when the token is invalid, and here it was not.
Does the attacker need a dashboard login?
No, per the record. They need an administrator who is signed in to visit a page they control.
Sources
Last reviewed: 18 October 2026.
