CVE-2026-61851: Chartbrew SQL Injection Vulnerability

CVE-2026-61851 Overview

Chartbrew is an open-source web application that connects to databases and APIs to generate charts. CVE-2026-61851 affects the AI orchestrator's runQuery() implementation in server/modules/ai/orchestrator/tools/runQuery.js. The function attempts to enforce read-only database access using a blocklist of only seven SQL keywords. Authenticated users with AI feature access can submit dangerous statements or database functions absent from that blocklist. Depending on the database engine, configuration, and database-user privileges, an attacker can read or write files, reach internal network resources, alter privileges, execute commands, or modify data. The issue is fixed in Chartbrew version 5.2.2.

Critical Impact
Authenticated users with AI access can bypass the read-only guardrail and execute arbitrary SQL, including file I/O, privilege changes, and command execution on supported database engines.

Affected Products

Chartbrew versions prior to 5.2.2
Deployments exposing the AI orchestrator runQuery tool to authenticated users
Backends using PostgreSQL, MySQL, or ClickHouse connectors with elevated database privileges

Discovery Timeline

2026-09-21 - CVE-2026-61851 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-61851

Vulnerability Analysis

The flaw is an incomplete denylist [CWE-184] in the AI orchestrator's query execution path. Chartbrew exposes a runQuery() tool that allows the AI agent to execute SQL against connected data sources on behalf of authenticated users. To keep the tool read-only, the pre-patch implementation compared incoming SQL against a static list of seven forbidden keywords. Any statement or function not on that list passed the guard and was sent to the backend database. The bypass requires no SQL injection or keyword obfuscation, only a legitimate authenticated session with AI feature access.

Root Cause

The root cause is reliance on an incomplete keyword blocklist for security enforcement. Read-only intent should be enforced at the database session or connection layer, for example by binding a role with SELECT-only privileges or by parsing the SQL and rejecting non-SELECT parse trees. Denylist filtering cannot enumerate the full attack surface of a modern SQL dialect, which includes DDL, DML, privilege statements, stored procedure invocations, and vendor-specific file and network functions.

Attack Vector

An authenticated user submits a prompt or crafted payload that causes the AI orchestrator to invoke runQuery() with SQL outside the blocklist. On PostgreSQL, functions such as pg_read_file, pg_ls_dir, lo_export, and COPY ... TO PROGRAM enable file access or command execution. On MySQL, LOAD_FILE(), INTO OUTFILE, INTO DUMPFILE, and LOAD DATA reach the filesystem. Statements such as GRANT, REVOKE, CALL, and EXECUTE alter privileges or run stored routines. Impact scales with the privileges of the database account Chartbrew connects with.

javascript

// Security patch: server/modules/ai/orchestrator/tools/runQuery.js
// Adds an expanded pattern list to block dangerous SQL constructs
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](https://github.com/chartbrew/chartbrew/commit/8c8412edce56093e81b524e0235a796c7dd42336)

Detection Methods for CVE-2026-61851

Indicators of Compromise

Chartbrew AI orchestrator logs showing runQuery() invocations containing keywords such as GRANT, REVOKE, COPY, INTO OUTFILE, or pg_read_file.
Database audit logs recording DDL, DML, or privilege statements originating from the Chartbrew service account.
Unexpected outbound network connections from the database host, indicating use of functions that reach internal resources.
New or modified files in database data or export directories created by the Chartbrew database user.

Detection Strategies

Enable and centralize query logging on PostgreSQL (log_statement = 'all'), MySQL general query log, and ClickHouse query_log for the Chartbrew connection user.
Alert on any non-SELECT statement executed by the Chartbrew database account.
Review Chartbrew application logs for AI tool invocations that include patterns from the patched DANGEROUS_SQL_PATTERNS list.

Monitoring Recommendations

Baseline expected query shapes from Chartbrew and flag deviations, particularly file, network, and privilege operations.
Monitor filesystem changes on database hosts using integrity monitoring focused on export and data directories.
Track authentication and role changes on connected databases to detect misuse of GRANT or REVOKE.

How to Mitigate CVE-2026-61851

Immediate Actions Required

Upgrade Chartbrew to version 5.2.2 or later on all environments exposing the AI orchestrator.
Rotate credentials for any database accounts used by Chartbrew if AI features were enabled prior to upgrade.
Restrict the Chartbrew database user to SELECT-only privileges on required schemas.
Review AI feature access and remove it from users who do not require query capabilities.

Patch Information

The fix is included in Chartbrew 5.2.2, released via GitHub Release v5.2.2. The corrective commit 8c8412e adds row-limit normalization and expands SQL source guards for the run query orchestrator. Full advisory details are available in GitHub Security Advisory GHSA-cp8j-2xwc-hxg8.

Workarounds

Disable the AI features in Chartbrew until the upgrade is applied.
Enforce database-side read-only roles so that runQuery() cannot execute DDL, DML, or file functions regardless of application checks.
Deploy the Chartbrew backend in a segmented network that cannot reach sensitive internal services from the database host.

bash

# Configuration example: create a read-only PostgreSQL role for Chartbrew
CREATE ROLE chartbrew_ro WITH LOGIN PASSWORD 'REPLACE_ME';
REVOKE ALL ON DATABASE analytics FROM chartbrew_ro;
GRANT CONNECT ON DATABASE analytics TO chartbrew_ro;
GRANT USAGE ON SCHEMA public TO chartbrew_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO chartbrew_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO chartbrew_ro;
-- Ensure the role cannot use dangerous functions
REVOKE EXECUTE ON FUNCTION pg_read_file(text) FROM chartbrew_ro;
REVOKE EXECUTE ON FUNCTION pg_ls_dir(text) FROM chartbrew_ro;