CVE-2026-61852: Chartbrew SQL Injection Vulnerability

CVE-2026-61852 Overview

Chartbrew is an open-source web application that connects to databases and APIs to build charts and dashboards. CVE-2026-61852 is a SQL injection vulnerability [CWE-89] in the runQuery() implementation located at server/modules/ai/orchestrator/tools/runQuery.js. The function interpolates the AI tool's row_limit parameter into a SQL LIMIT clause without runtime integer validation. Because the read-only keyword check runs before the parameter is appended, an authenticated user who can influence a model-generated non-integer row_limit value can inject SQL that bypasses the earlier guard. The issue is fixed in Chartbrew version 5.2.2.

Critical Impact
Successful exploitation allows arbitrary SQL execution against the connected database, enabling data theft or modification and, depending on database permissions, file access or operating-system command execution.

Affected Products

Chartbrew versions prior to 5.2.2
Deployments using the AI orchestrator runQuery tool
Connected databases including PostgreSQL, MySQL, and ClickHouse

Discovery Timeline

2026-09-21 - CVE-2026-61852 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-61852

Vulnerability Analysis

The vulnerability resides in Chartbrew's AI orchestrator, which exposes a runQuery tool to a language model. The tool accepts a row_limit parameter that the model can supply based on user prompts. Chartbrew concatenates this value directly into a SQL LIMIT clause. Before appending the value, the code scans the generated SQL for write keywords to enforce a read-only policy. Because the injected row_limit content is added after the keyword scan, dangerous statements appended through this parameter escape validation. An authenticated user who can steer the model's output can therefore execute arbitrary SQL against any connected data source.

Root Cause

The root cause is missing runtime integer validation on row_limit combined with unsafe string interpolation into a SQL statement. The read-only keyword filter is applied against the initial SQL body only, so payloads reaching the database through the LIMIT clause are never re-scanned before execution.

Attack Vector

Exploitation requires an authenticated Chartbrew user with access to AI-driven query functionality against a supported source (postgres, mysql, or clickhouse). By crafting prompts that steer the model to emit a non-integer row_limit, an attacker can append statements such as DROP, INSERT, UPDATE, COPY ... TO PROGRAM, INTO OUTFILE, or PostgreSQL file functions like pg_read_file() and lo_import().

javascript

// Patch excerpt: server/modules/ai/orchestrator/tools/runQuery.js
const DEFAULT_ROW_LIMIT = 1000;
const MAX_ROW_LIMIT = 10000;
const SQL_LIMIT_SOURCES = ["postgres", "mysql", "clickhouse"];

const DANGEROUS_SQL_PATTERNS = [
  /\bdrop\b/i,
  /\bdelete\b/i,
  /\bupdate\b/i,
  /\binsert\b/i,
  /\btruncate\b/i,
  /\balter\b/i,
  /\bcreate\b/i,
  /\binto\b/i,
  /\bpg_read_file\s*\(/i,
  /\bpg_read_binary_file\s*\(/i,
  /\bpg_ls_dir\s*\(/i,
  /\blo_export\s*\(/i,
  /\blo_import\s*\(/i,
  /\bcopy\b[\s\S]*\bto\s+program\b/i,
  /\binto\s+(out|dump)file\b/i,
  /\bload_file\s*\(/i,
  /\bload\s+data\b/i,
  /\bgrant\b/i,
  /\brevoke\b/i,
  /\bexec(ute)?\b/i,
  /\bcall\b/i,
  /\bfile\s*\(/i,
];

Source: GitHub Commit 8c8412e

Detection Methods for CVE-2026-61852

Indicators of Compromise

Database query logs containing SQL keywords such as DROP, INSERT, UPDATE, TRUNCATE, ALTER, or GRANT originating from Chartbrew service accounts.
PostgreSQL calls to pg_read_file(), pg_ls_dir(), lo_export(), lo_import(), or COPY ... TO PROGRAM from the Chartbrew connection user.
MySQL statements referencing INTO OUTFILE, INTO DUMPFILE, LOAD_FILE(), or LOAD DATA originating from AI-driven queries.
LIMIT clauses in Chartbrew-generated SQL containing non-numeric tokens or trailing statements.

Detection Strategies

Enable full SQL statement auditing on databases connected to Chartbrew and alert on any DDL or DML issued by the Chartbrew service account.
Review Chartbrew AI orchestrator logs for tool invocations where row_limit is not a bounded integer.
Compare pre- and post-patch behavior by inspecting queries against SQL_LIMIT_SOURCES (postgres, mysql, clickhouse).

Monitoring Recommendations

Forward database audit logs and Chartbrew application logs to a central analytics platform for correlation.
Alert on file-system or program-execution SQL functions from any application-tier account.
Track unexpected privilege usage by the database role assigned to Chartbrew.

How to Mitigate CVE-2026-61852

Immediate Actions Required

Upgrade Chartbrew to version 5.2.2 or later on all deployments.
Rotate credentials used by Chartbrew to connect to backend databases in case of prior exposure.
Audit connected databases for unauthorized DDL, DML, or file-system access following the disclosure window.

Patch Information

The fix normalizes row_limit to an integer, enforces DEFAULT_ROW_LIMIT = 1000 and MAX_ROW_LIMIT = 10000, and adds DANGEROUS_SQL_PATTERNS guards evaluated against the final SQL. See the GitHub Security Advisory GHSA-4923-m569-jc42, the GitHub Commit Details, and the Chartbrew v5.2.2 Release.

Workarounds

Restrict the database role used by Chartbrew to least-privilege read-only access on the specific schemas required.
Disable file-system and program-execution SQL functions where possible (for example, revoke pg_read_file execution and disable MySQL secure_file_priv).
Limit access to AI-driven query features to trusted users until the upgrade is applied.

bash

# Configuration example: restrict Chartbrew's PostgreSQL role to read-only
REVOKE ALL ON SCHEMA public FROM chartbrew_user;
GRANT USAGE ON SCHEMA public TO chartbrew_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO chartbrew_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO chartbrew_user;
REVOKE EXECUTE ON FUNCTION pg_read_file(text) FROM chartbrew_user;