CVE-2026-68531 in Concrete CMS
Summary
by MITRE • 09/15/2026
Concrete CMS 9 before 9.5.3 did not escape SQL LIKE wildcard characters in the keyword search filters used by the file manager, file folders, and page list, allowing an authenticated user with editor-level or higher privileges to submit a crafted search containing many single-character wildcards. Because the keyword input was placed into the LIKE clause without neutralizing its wildcard metacharacters, a short request could force the database to evaluate every row and perform a full-table scan, and repeated or wildcard-dense searches could sustain elevated database CPU and I/O, degrading responsiveness for other users on large installations. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. Thanks noivan for reporting.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.3 represents a significant database performance degradation issue stemming from improper input handling within the application's search functionality. Specifically, the file manager, file folder listings, and page list features utilize SQL LIKE clauses to filter results based on user-provided keywords. In these earlier versions of the software, the system failed to escape or neutralize special wildcard characters inherent to the SQL standard, namely the percent sign (%) representing any sequence of zero or more characters, and the underscore (_) representing exactly one character. This oversight allows an authenticated attacker with editor-level privileges or higher to inject crafted search queries containing a high density of these single-character wildcards. By submitting such inputs, the attacker effectively bypasses the intended filtering logic, forcing the underlying database engine to interpret the query as a request for broad pattern matching rather than specific keyword retrieval.
From a technical perspective, this flaw leads directly to inefficient SQL execution plans that trigger full-table scans on large datasets. When the database encounters a LIKE clause populated with numerous wildcards without proper escaping, it cannot utilize standard index optimizations effectively and must instead examine every row in the relevant tables to determine matches. This results in substantial increases in Central Processing Unit utilization and Input/Output operations as the server processes an exponentially larger number of records than intended. The impact is particularly severe on installations with extensive content libraries or large numbers of files, where a single crafted request can consume significant system resources for an extended period. Unlike typical injection vulnerabilities that aim to exfiltrate data or modify structures, this vulnerability primarily targets availability and performance stability rather than confidentiality or integrity in the traditional sense.
The operational impact of this flaw is characterized by sustained elevated database load which degrades responsiveness for all users sharing the same infrastructure. In a multi-tenant environment or a busy public-facing site, such resource exhaustion can lead to slow page loads, time-out errors, and general unavailability of services for legitimate users. The vulnerability allows for both one-time performance spikes through single crafted requests and sustained degradation if an attacker repeatedly submits wildcard-dense searches over time. This aligns with the ATT&CK technique T1496, Resource Hijacking, where adversaries leverage system resources to cause denial-of-service conditions or disrupt normal operations. Furthermore, it reflects CWE-89 improvements regarding SQL Injection, specifically focusing on the lack of proper neutralization of special elements used in SQL commands within LIKE clauses, which is a common oversight when developers assume that basic authentication checks are sufficient protection against query manipulation.
The Concrete CMS security team has assigned this vulnerability a CVSS v4.0 score of 2.1, indicating low severity primarily due to the requirement for high privileges and the lack of direct impact on confidentiality or integrity. The vector string CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N reflects that while the attack is network-accessible and requires low complexity, it demands authenticated access with high privileges, resulting in only a local impact on availability for other users. Mitigation strategies focus heavily on upgrading to Concrete CMS version 9.5.3 or later, where this input validation issue has been resolved by properly escaping wildcard characters before they are incorporated into SQL queries. For organizations unable to upgrade immediately, implementing strict rate limiting on search endpoints and applying Web Application Firewall rules that detect excessive use of percent signs or underscores in query parameters can provide temporary relief from exploitation attempts until the patch is applied.