Chartbrew EUVD-2026-84212

Requires an authenticated Chartbrew user (PR:L) with access to the AI orchestrator query feature, and a data source of type postgres, mysql, or clickhouse (the only source types where the vulnerable LIMIT-clause interpolation in runQuery.js is applied). The decisive limiting factor is AT:P: the attacker cannot supply row_limit directly - they must influence a MODEL-GENERATED non-integer row_limit, so exploitation hinges on manipulating the LLM into emitting a crafted value that gets appended into the SQL after the read-only keyword check. Escalation beyond data read/write to file access or OS command execution is further gated on the connected database account's permissions. Fixed in v5.2.2; deployments on that version or without the AI query tool enabled are not exposed.

This is a moderate, conditionally-exploitable SQL injection (CWE-89) rather than a drop-everything priority. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N, score 5.8) tells a nuanced story: network-reachable and low attack complexity, but AT:P (attack requirements present) and PR:L (authenticated) meaningfully gate it. Critically, the vector rates the vulnerable system's own C/I/A as N while placing all impact on the SUBSEQUENT system (SC:H/SI:H/SA:H) - meaning Chartbrew itself is not directly compromised, but the connected backend database is, which is the true prize. The AT:P requirement is important and easy to overlook: exploitation depends on an authenticated user influencing a MODEL-GENERATED non-integer row_limit value flowing through the AI orchestrator (server/modules/ai/orchestrator/tools/runQuery.js), so the attacker does not directly control the injected value - they must steer the LLM into emitting a malicious row_limit that is then interpolated into the SQL LIMIT clause after the read-only keyword check has already run. No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence; per precision rules this is 'no public exploit identified at time of analysis.' The one strong signal is a confirmed vendor fix (v5.2.2, commit 8c8412ed, GHSA-4923-m569-jc42) that adds integer validation, a LIMIT-clause check, and a hardened dangerous-pattern blocklist - confirming the root cause and that a patch path exists. Net: real and worth patching for anyone running the AI query feature, but the LLM-indirection gate and authentication requirement make widespread opportunistic exploitation unlikely.

An authenticated Chartbrew team member uses the AI charting assistant against a connected Postgres/MySQL/ClickHouse source and crafts input that steers the model into producing a non-integer row_limit containing appended SQL. Because the read-only keyword check executes before row_limit is interpolated into the LIMIT clause, the smuggled statement bypasses the SELECT-only guard and executes against the backend database, enabling data theft, modification, or - where DB permissions allow - file access or OS command execution. No public proof-of-concept was identified at time of analysis, and exploitation depends on reliably influencing the model output.