CVE-2026-111685 in IceCMS
Summary
by MITRE • 10/16/2026
IceCMS through 4.1.5 contains an unauthenticated sql injection vulnerability that allows remote attackers to inject SQL by supplying a crafted num path parameter to /WebResource/findresourcebynum. Attackers can append SQL after the LIMIT clause concatenated via QueryWrapper.last() to extract database contents using union-based or blind techniques.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The IceCMS software, specifically through version 4.1.5, contains a critical unauthenticated SQL injection vulnerability located within the /WebResource/findresourcebynum endpoint. This flaw stems from improper input validation and sanitization of the num path parameter supplied by remote attackers. The underlying technical issue involves the use of MyBatis QueryWrapper.last() method to append user-supplied data directly into an SQL query string after a LIMIT clause without adequate protection against injection attacks. Because this vulnerability is unauthenticated, any external actor on the network can exploit it without needing valid credentials or prior authentication sessions, significantly lowering the barrier for entry and increasing the potential attack surface considerably.
From a technical perspective, the exploitation mechanism relies on appending malicious SQL syntax after the LIMIT clause of an existing query. The attacker crafts a specific value for the num parameter that terminates the intended logic and injects additional SQL commands. This allows for both union-based extraction techniques, where the attacker can retrieve data from other tables by combining result sets, and blind injection techniques, which rely on observing application responses to infer database structure or extract data character by character. The lack of proper escaping or type checking in the QueryWrapper.last() implementation means that special characters such as single quotes are not neutralized effectively, allowing the injected payload to be interpreted as executable SQL code rather than literal string data.
The operational impact of this vulnerability is severe and multifaceted. Successful exploitation enables remote attackers to read sensitive information from the backend database, which may include user credentials, personal identifiable information, configuration details, or proprietary business logic stored within IceCMS instances. Beyond simple data exfiltration, an attacker with sufficient privileges in the underlying database could potentially modify existing records, delete critical data, or even execute operating system commands depending on the specific database engine and its permissions settings. This compromises the confidentiality, integrity, and availability of the affected systems, leading to potential regulatory non-compliance if personal data is involved, as well as significant reputational damage for organizations relying on IceCMS for their web resource management needs.
This vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. In the context of the MITRE ATT&CK framework, this exploitation technique falls under T1059 Command and Scripting Interpreter or more specifically data exfiltration techniques such as T1005 Data from Local System if the attacker is extracting stored information. The unauthenticated nature of the flaw also relates to CWE-287 Improper Authentication, although the primary vector remains SQL injection rather than a failure in credential verification per se.
To mitigate this vulnerability, immediate action should be taken by upgrading IceCMS to a patched version where the developer has implemented proper parameterized queries or prepared statements instead of relying on string concatenation via QueryWrapper.last(). If an upgrade is not immediately feasible, administrators can implement web application firewall rules to detect and block SQL injection patterns in the num path parameter. Additionally, applying strict input validation that rejects any non-numeric characters for this specific field would prevent most exploitation attempts. Regular security audits and static code analysis focused on database interaction layers are recommended to identify similar flaws before they can be exploited by malicious actors.