CVE-2026-85708

In Chartbrew 5.2.2, the AI SQL blocklist omitted sibling PostgreSQL filesystem functions and failed to match double-quoted identifier forms of denied functions. A team Owner or Admin using an AI-enabled PostgreSQL connection can cause generated SQL to use an unlisted sibling function or a double-quoted denied function, bypassing the denylist. AI features must be enabled and the user must have elevated Chartbrew privileges.

Chartbrew prior to 5.2.3 stores public dashboard passwords in plaintext, accepts them through a URL query parameter, and validates them without effective attempt throttling. An unauthenticated attacker can repeatedly submit candidate passwords or obtain password-bearing server or proxy logs. The vulnerability affects public dashboards with password protection enabled.

Chartbrew prior to 5.2.3 stored attacker-chosen absolute SSL and SSH file paths during connection creation or update and later passed those stored paths to fs.unlink without a path restriction during connection cleanup. A user with createOwn and deleteOwn permissions on their own team can store a target path in a connection and delete the connection to unlink the referenced file, such as /code/.env or application source.

Chartbrew prior to 5.2.3 inserted a date-typed MongoDB variable placed inside a quoted query placeholder as an unescaped string, unlike the safely escaped string, number, and Boolean branches. An unauthenticated user can supply a crafted URL filter to a public, shareable, or embedded MongoDB chart, break out of the quoted literal, change query logic, and use the returned row count as a Boolean oracle to extract any field from the queried collection.

Chartbrew prior to 5.2.3 trusted a caller-controlled team_id in the shared project permission check and let the teamOwner/teamAdmin branch continue without confirming that the target project belonged to that team. An authenticated owner or admin of their own team can submit a victim project id with their own team_id, and the update path mass-assigns the request body without a project field allow-list, allowing the attacker to re-parent the victim project into their own team and gain full access.

In Chartbrew prior to 5.2.1, the outbound URL guard did not recognize IPv4 addresses embedded in NAT64 prefixes. An authenticated user with API connection management privileges could supply a hostname or redirect resolving to a NAT64 address embedding a private or link-local IPv4 destination, allowing access to internal resources including the 169.254.169.254 cloud metadata endpoint after NAT64 translation.

In version 4.9.0 of Chartbrew, a vulnerability allows low-privileged attackers to access data from other projects within the same team. This vulnerability enables reading, executing, creating, updating, and deleting datasets and data requests that the attacker should not have access to.

In version 4.9.0 of Chartbrew, a vulnerability exists that allows access to the POST /api/chart/:chart_id/query endpoint without authentication. An attacker who knows the chart identifier can trigger a data refresh and access private charts.

In version 4.9.0 of Chartbrew, authenticated users with access to one project can update or delete a SharePolicy record belonging to another project. The issue arises from the lack of verification that policy_id belongs to the specified project.

In version 4.9.0 of Chartbrew, there is a vulnerability that allows public access to chart data, even if they are hidden. This issue arises from improper verification of access permissions for charts in public projects.