Chartbrew CVE-2026-61851

Requires an authenticated Chartbrew account whose team has the AI feature enabled and configured with an OpenAI model, plus a database connection of type postgres, mysql, or clickhouse (the source types routed through the SQL normalization path). The attacker submits a query through the AI orchestrator's runQuery() tool; the pre-5.2.2 read-only enforcement only blocked seven keywords (DROP, DELETE, UPDATE, INSERT, TRUNCATE, ALTER, CREATE), so any dangerous statement or DB function outside that list (file/network/privilege functions, EXEC/CALL, GRANT/REVOKE) passes through. LIMITING FACTORS: exploitation demands valid authentication with AI-feature access (PR:L, not unauthenticated); actual impact is bounded by the privileges of the configured database user (a least-privilege read-only account greatly reduces damage) and by the database engine and its configuration (e.g., whether file/program functions are permitted). No user interaction by a victim is required.

This is a genuine but access-gated integrity/confidentiality issue rather than a mass-exploitation emergency. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H, score 6.5) deliberately models the impact on the SUBSEQUENT system (the connected database), keeping vulnerable-system VC/VI/VA at N - a defensible choice since the flaw abuses Chartbrew to attack the backing DB. PR:L confirms authentication is required (a user with AI feature access), and there is no user-interaction requirement. There is NO EPSS score, NO CISA KEV listing, and NO public exploit provided - so exploitation status is 'no public exploit identified at time of analysis,' though the fix commit (8c8412ed) publicly enumerates the exact bypass payloads (pg_read_file, lo_export, COPY...TO PROGRAM, INTO OUTFILE, LOAD_FILE, GRANT, EXEC/CALL), which materially lowers the bar for exploit development. Realized impact is conditional and self-described as 'depending on the database engine, configuration, and database-user privileges' - meaning a least-privilege read-only DB account sharply limits blast radius, while a permissive DB account could yield file access, internal network pivoting, privilege changes, or command execution. Net: a real priority for any Chartbrew operator who has enabled the AI feature and connected privileged DB accounts, but not a drop-everything internet-wide threat given the authentication gate and niche footprint. Note the score tension: my own component-impact reading lands higher than 6.5, but that is a modeling difference (impacted component = the DB), not a contradiction.

An authenticated Chartbrew user who has access to the AI query feature asks the AI orchestrator to run a query and supplies a SELECT statement embedding a dangerous database function or statement not covered by the seven-keyword blocklist (e.g., PostgreSQL pg_read_file()/lo_export(), or MySQL LOAD_FILE()/INTO OUTFILE). Because no SQL injection or obfuscation is needed, the runQuery() tool forwards it to the connected database, and if the database user is sufficiently privileged the attacker reads/writes server files, reaches internal network resources, or alters data. No public POC exists, but the patch diff publicly documents the exact bypass payloads.