CVE-2026-81895 in Concrete CMS
Summary
by MITRE • 09/15/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.3 represents a critical stored SQL injection flaw within the Document Library block component. This security issue stems from an insufficient validation of input data, specifically regarding file-set identifiers submitted via the fsID[] parameter. When administrators or users with appropriate permissions configure this block by setting its mode to any value other than restricted options that might trigger different code paths, the application fails to enforce strict type checking on these identifiers. Instead of validating that the provided values are strictly integers, the system accepts them as raw strings and proceeds directly into database query construction logic without proper sanitization or parameter binding mechanisms.
The technical root cause lies in how the block processes configuration data during page rendering. The function btDocumentLibrary.setIds is responsible for handling these identifiers, but it concatenates each stored identifier directly into a SQL filter query string rather than utilizing prepared statements with bound parameters. This architectural decision allows an authenticated attacker to inject arbitrary SQL syntax into the block's configuration settings. Because this malicious payload is persisted in the database as part of the page structure, it does not require repeated exploitation attempts against the input vector itself; instead, the injection occurs passively whenever a visitor loads or renders the published page containing the compromised Document Library block.
This mechanism classifies the vulnerability as a stored, time-based blind SQL injection. The term stored indicates that the malicious code is saved on the target server and executed later by other users, while time-based blind implies that the attacker can infer database contents based on response delays caused by conditional execution of injected commands. Although direct data exfiltration might be more challenging due to the blind nature of the attack, an adversary with high privileges who has access to add or edit blocks can leverage this flaw to extract sensitive information from the backend database, manipulate application logic, or potentially escalate privileges depending on the underlying database engine's capabilities and configuration.
From a risk perspective, the Concrete CMS security team assigned this vulnerability a CVSS v4.0 score of 8.5, indicating a high severity level. The vector string 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 highlights that while the attack requires network access and local context with no user interaction required for execution, it demands high privileges to initially inject the payload. However, once injected, the impact on confidentiality and integrity is severe because every page view triggers the malicious query. This aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, specifically highlighting failures in input validation and parameterized query usage. Furthermore, this behavior maps to ATT&CK technique T1059 Command and Scripting Interpreter through database commands, as well as potential data exfiltration vectors under T1048 if the blind injection is refined for data retrieval.
Mitigation strategies must prioritize immediate patching of Concrete CMS to version 9.5.3 or later where these validation checks have been strengthened. For environments unable to update immediately, administrators should restrict access to Document Library block configuration to only those users who absolutely require it, thereby reducing the attack surface. Additionally, implementing a Web Application Firewall with rules capable of detecting SQL injection patterns in POST requests related to block configurations can provide an additional layer of defense. Long-term remediation involves enforcing strict input validation at the framework level and mandating the use of parameterized queries for all database interactions involving user-supplied data to prevent similar classes of vulnerabilities across other modules.