CVE-2026-54349: Chartbrew SQL injection in dashboard filter substitution
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.1, SQL dashboard-variable substitution used attacker-controlled JavaScript replacement strings unsafely across SQL connectors and separately failed to escape backslashes for MySQL and MariaDB quoted contexts. The vulnerable surface is public and embedded dashboard/chart requests that call applyMysqlOrPostgresVariables. An unauthenticated user sends crafted URL filter values to a public or embedded chart backed by a stored SQL query. Replacement-string dollar sequences can alter SQL independently of the database engine, while MySQL and MariaDB backslash handling provides a second quoted-string escape path. The target must expose a public or embedded chart using URL-controlled variables in a SQL query; only the backslash branch is specific to MySQL and MariaDB. Injected SQL can read, modify, or delete data available to the configured database account. This issue is fixed in version 5.2.1.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Chartbrewto a version that resolves this vulnerability.Fixed in 5.2.1
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated exploitation?
A deployment is exposed when it has a public or embedded chart backed by a stored SQL query that uses URL-controlled dashboard variables. Charts that are not public or embedded are not identified as part of this unauthenticated attack surface.
Does the issue affect every supported SQL database in the same way?
The unsafe JavaScript replacement-string handling affects SQL connectors generally and can alter SQL independently of the database engine. The additional quoted-string escape path caused by unescaped backslashes is specific to MySQL and MariaDB.
What access does an attacker need?
The attacker does not need authentication, but must be able to send crafted URL filter values to an exposed public or embedded chart using URL-controlled variables in its SQL query.
What is the impact if exploitation succeeds?
Injected SQL can read, modify, or delete data that the configured database account is permitted to access. The resulting impact is therefore bounded by that database account's privileges.
What should be done to remediate the issue?
Upgrade Chartbrew to version 5.2.1. Until upgrading, remove public or embedded access to affected charts or ensure they do not use URL-controlled variables in stored SQL queries.