CVE-2026-61852 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 interpolates the AI tool's row_limit parameter into a SQL LIMIT clause without runtime integer validation. The read-only keyword check runs before this value is appended, so an authenticated user who can influence a model-generated non-integer row_limit can add SQL that bypasses the earlier check. Successful exploitation can execute arbitrary statements against the connected database, including reading or changing data and, where database permissions permit, accessing files or executing operating-system commands. This issue is fixed in version 5.2.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
Chartbrew serves as an open-source web application designed to facilitate data visualization by connecting directly to various databases and APIs. The software allows users to create charts based on the retrieved data, making it a valuable tool for analytics and reporting. However, prior to version 5.2.2, the application contained a critical security flaw within its artificial intelligence integration module. Specifically, the runQuery function located in server/modules/ai/orchestrator/tools/runQuery.js exhibited improper input validation when handling parameters generated by AI models. This vulnerability stems from how the system processes the row_limit parameter, which is intended to restrict the number of rows returned by a database query.
The technical root cause of this vulnerability lies in the sequence and nature of input sanitization checks performed on user-influenced data. The application implements a check for read-only keywords to prevent write operations such as updates or deletions. However, this security control is executed before the row_limit parameter is interpolated into the SQL LIMIT clause. Crucially, there is no runtime integer validation applied to ensure that the value provided by the AI model is strictly numeric. This architectural oversight creates a window for exploitation where an authenticated user can manipulate the context of the query through the AI tool's output.
An attacker who has valid authentication credentials and access to the AI features can exploit this flaw by influencing the model-generated row_limit parameter. By crafting inputs that cause the AI to generate non-integer values or malicious SQL fragments, the attacker can bypass the read-only keyword check. Since the validation occurs before the interpolation into the LIMIT clause, the subsequent SQL statement may contain arbitrary commands rather than a simple numeric limit. This allows the injection of additional SQL statements that are executed against the connected database with the privileges of the application's database account.
The operational impact of this vulnerability is severe, as it effectively results in an Unrestricted Upload of Code with Execute Permissions or more accurately, Remote Code Execution via Database Interaction. Successful exploitation enables an attacker to execute arbitrary SQL commands. This includes reading sensitive data from the database, modifying existing records, and potentially dropping tables. Furthermore, depending on the specific database management system and its configuration permissions, this could escalate to accessing files stored on the server's file system or executing operating-system level commands through built-in database features such as xp_cmdshell in Microsoft SQL Server or similar functions in other databases like PostgreSQL or MySQL.
This vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The failure to validate and sanitize user-controllable input before its use in a SQL command allows for the injection of malicious syntax. Additionally, from a tactical perspective related to the MITRE ATT&CK framework, this exploitation technique falls under T1059 Command and Scripting Interpreter via database commands or T1213 Data from Information Repositories if used primarily for data exfiltration. The lack of strict type checking on dynamic inputs represents a significant deviation from secure coding practices recommended by industry standards such as OWASP Top 10, specifically under Injection vulnerabilities.
To mitigate this risk and prevent similar issues in future development, it is imperative to implement robust input validation at the point of use rather than relying solely on pre-checks that can be bypassed through ordering flaws. Developers should enforce strict integer type casting for parameters like row_limit before they are interpolated into SQL queries. Utilizing parameterized queries or prepared statements where possible further reduces the risk of injection attacks by separating code from data. Additionally, implementing a whitelist approach for allowed characters in dynamic inputs and applying defense-in-depth strategies such as least-privilege database accounts can limit the blast radius if an exploitation attempt occurs.
Organizations currently using Chartbrew versions prior to 5.2.2 are advised to upgrade immediately to version 5.2.2 or later, where this issue has been resolved. The patch addresses the validation logic by ensuring that integer constraints are enforced correctly and that input sanitization is applied in a manner that prevents bypass through ordering anomalies. Until an update can be deployed, administrators should restrict access to the AI features of Chartbrew to only those users who absolutely require it, thereby reducing the attack surface available for exploitation. Continuous monitoring of database logs for anomalous query patterns may also help detect attempted exploits during this transition period.