CVE-2026-91848 in WuzhiCMS
Summary
by MITRE • 09/15/2026
A vulnerability was identified in WuzhiCMS up to 4.1.0. Affected by this issue is the function article::getDataOfJson of the file /index.php?m=content&f=article&v=getDataOfJson. The manipulation of the argument title/master_table leads to sql injection. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The identified vulnerability in WuzhiCMS versions up to 4.1.0 represents a critical security flaw located within the content management module, specifically affecting the article::getDataOfJson function accessed via the /index.php endpoint with parameters m=content&f=article&v=getDataOfJson. This component is responsible for retrieving and processing data related to articles in JSON format, a common requirement for dynamic web applications that rely on asynchronous requests or API-like interactions. The core technical flaw stems from improper input validation and sanitization of the title and master_table arguments passed by the user. Because these parameters are directly concatenated into SQL queries without adequate escaping or parameterized query mechanisms, an attacker can inject malicious SQL code. This specific type of vulnerability is classified under CWE-89, which denotes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The lack of proper sanitization allows the application to interpret user-supplied input as part of the database query structure rather than as data, fundamentally breaking the separation between code and data that is essential for secure execution.
The operational impact of this vulnerability is severe due to its remote exploitability. Since the affected function is accessible over HTTP/HTTPS without requiring prior authentication in many default configurations or through specific request manipulation, an unauthenticated attacker can interact with the application remotely. The availability of public exploits significantly lowers the barrier to entry for malicious actors, increasing the likelihood of automated attacks and widespread compromise. Successful exploitation allows attackers to execute arbitrary SQL commands against the backend database. This capability enables a range of destructive actions including unauthorized data extraction from sensitive tables such as user credentials or personal information, modification or deletion of existing records, and potentially escalating privileges within the database environment. In some configurations, if the underlying database service runs with elevated system permissions, this vulnerability could even lead to remote code execution on the host server through features like xp_cmdshell in Microsoft SQL Server or similar extensions in other database management systems.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1059, Command and Scripting Interpreter, specifically when used for SQL command injection, and falls under the initial access vector of Exploit Public-Facing Application (T1190). The fact that the project maintainers have been notified but have not yet responded highlights a critical gap in supply chain security and vendor responsiveness. For organizations relying on WuzhiCMS, this lack of immediate patching necessitates proactive defensive measures rather than passive waiting for an official update. Mitigation strategies should focus on network-level controls such as Web Application Firewalls that can detect and block SQL injection patterns targeting the specific endpoint parameters. Additionally, implementing strict input validation rules that reject non-alphanumeric characters in fields expecting simple text data like titles or table names can provide a layer of defense-in-depth. Until an official patch is released, administrators should consider restricting access to the /index.php?m=content&f=article&v=getDataOfJson endpoint via IP whitelisting if it does not need public exposure, or disabling the module entirely if its functionality is not required for their specific use case. Regular database auditing and monitoring for anomalous query patterns can also help in early detection of exploitation attempts.