CVE-2026-81895: Concrete CMS 9.5.2 and below is vulnerable to Stored SQL Injection in Concrete CMS Document Library Block via `fsID[]` in `setMode=any`
In Concrete CMS before 9.5.3, the Document Library block stored the file-set identifiers submitted through fsID[] without validating them as integers, and when the block was configured with setMode set to any it concatenated each stored identifier directly into the file-set filter query instead of casting it or binding it as a parameter. An authenticated user permitted to add or edit a Document Library block could therefore persist SQL syntax in the block configuration (btDocumentLibrary.setIds), and that stored expression was executed every time the published page containing the block was rendered, producing stored, time-based blind SQL injection. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 8.5 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Habib Allah for reporting.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Concrete CMS Document Library blockto a version that resolves this vulnerability.Fixed in 9.5.3 - Configuration
For Concrete CMS versions 9.5.2 and below, do not configure the Document Library block with setMode set to any, since it concatenates stored fsID[] values into the file-set filter query without validating them as integers.
Concrete CMS Document Library block setMode = any (not allowed)
Event History
Frequently Asked Questions
Which configurations are exposed?
The affected path requires a Document Library block configured with setMode set to any. The vulnerable behavior is tied to file-set identifiers stored in that block's configuration.
What level of access does an attacker need?
An attacker must be authenticated and have permission to add or edit a Document Library block. They also need a page containing the configured block to be rendered for the stored SQL expression to execute.
Are default installations necessarily affected?
The issue is not triggered solely by running an affected version. Exploitation depends on a Document Library block using setMode=any and an authorized user being able to save crafted fsID[] values.
How can I identify potentially affected existing blocks?
Review Document Library block configurations on affected installations for blocks using setMode=any, particularly their stored file-set identifier values in btDocumentLibrary.setIds. Non-integer or unexpected SQL-like content in those values indicates potential malicious configuration.
What can be done if upgrading is not immediately possible?
Restrict who can add or edit Document Library blocks, and review or remove affected blocks configured with setMode=any until they can be remediated. The issue is fixed in Concrete CMS 9.5.3.