CVE-2026-61851 in Chartbrew
Summary
by MITRE • 09/22/2026
Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.2, Chartbrew's runQuery() implementation in server/modules/ai/orchestrator/tools/runQuery.js attempts to enforce read-only database access with a blocklist containing only seven SQL keywords. An authenticated user with AI feature access can submit dangerous statements or database functions that are absent from the read-only keyword blocklist, causing them to execute without SQL injection or keyword-obfuscation techniques. Depending on the database engine, configuration, and database-user privileges, this can expose or write files, access internal network resources, change database privileges, execute commands, or alter data. This issue is fixed in version 5.2.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
Chartbrew serves as an open-source web application designed to facilitate the creation of charts by connecting directly to databases and APIs. The security flaw identified in versions prior to 5.2.2 resides within the server/modules/ai/orchestrator/tools/runQuery.js module, which is responsible for executing database queries initiated through the AI feature set. This component attempts to enforce a read-only access policy on database interactions by employing a blocklist mechanism that filters out specific SQL keywords deemed dangerous or write-capable. However, this security control relies exclusively on a static list containing only seven SQL keywords, creating a significant gap in defensive coverage against malicious input.
The core technical flaw is an insufficient validation of user-supplied data due to the reliance on a restrictive keyword blocklist rather than parameterized queries or comprehensive allow-listing strategies. An authenticated user who possesses access to the AI features can submit SQL statements that do not contain any of the seven blocked keywords yet still perform destructive actions. Because the mitigation strategy is based solely on excluding specific terms, attackers are able to bypass these restrictions by utilizing alternative syntax, database-specific functions, or command structures that achieve write operations without triggering the predefined filters. This approach fails to account for the vast array of SQL dialects and engine-specific features that can be leveraged to modify data state.
The operational impact of this vulnerability is severe, as it allows an authenticated attacker to execute arbitrary commands with the privileges assigned to the database user configured in Chartbrew's connection settings. Depending on the specific database engine, its configuration, and the level of access granted to the application's service account, the consequences can range from data exfiltration to complete system compromise. Attackers may be able to write files to the server filesystem if the database supports such operations, access internal network resources through out-of-band mechanisms like DNS or HTTP requests initiated by the database engine, change user privileges within the database itself, execute operating system commands via extended stored procedures or similar features, and fundamentally alter application data integrity. This represents a critical failure in input validation that undermines the intended read-only security posture of the AI query tool.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code SQL Injection, as it involves the execution of unintended code within the database engine due to inadequate sanitization of user inputs. Furthermore, from an adversary perspective, this flaw facilitates ATT&CK technique T1059 Command and Scripting Interpreter if the database allows for operating system command execution, or T1213 Data from Information Repositories when used for exfiltration. The lack of robust input validation also touches upon CWE-78 Improper Neutralization of Special Elements used in an OS Command if such capabilities are exposed through the specific database driver being utilized.
To mitigate this risk, organizations running Chartbrew versions prior to 5.2.2 must upgrade immediately to version 5.2.2 or later where these issues have been addressed. In addition to upgrading, administrators should review the principle of least privilege applied to the database user account used by Chartbrew, ensuring it has only the minimum necessary permissions required for its function and does not possess high-level privileges such as xp_cmdshell access in SQL Server or similar elevated capabilities in other engines. Implementing a Web Application Firewall with robust SQL injection detection rules can provide an additional layer of defense, although reliance on WAFs alone is discouraged given that this vulnerability stems from application logic flaws rather than simple pattern matching failures. Regular security audits and code reviews focusing on database interaction layers are recommended to prevent similar issues in future development cycles.