CVE-2026-85712
HighCVSS 8.8Summary
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.
Risk Assessment
An attacker can take over a victim project, gain full read and write access, expose it publicly, remove password protection, or cause its loss; the shared delete route also permits cross-tenant deletion.
Recommendation
Update Chartbrew to version 5.2.3 or later.
Other vulnerabilities in Chartbrew
See all- CVE-2026-69128Medium
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.
- CVE-2026-68933High
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.
- CVE-2026-85736High
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.
- CVE-2026-85726High
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.
- CVE-2026-85708High
In Chartbrew prior to 5.2.3, chart share and embed tokens were signed with CB_SECRET, which could be a known or shipped-default value in stock Docker Compose installs. An attacker who knows the secret can forge a Chart-subject token for a private chart and, without authentication, enumerate integer ids to read arbitrary private chart data including chartData.
- CVE-2026-54589High
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.
- CVE-2026-40904High
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.
- CVE-2026-40601High
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.
- CVE-2026-40600High
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.
- CVE-2026-40595High
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.
Original NVD description (English source)
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.3, the shared project permission check trusted a caller-controlled team_id and let the teamOwner/teamAdmin branch continue without confirming that the target project belonged to that team. The vulnerable surface is project routes and related authorization checks that accepted user-controlled project identifiers. An authenticated user who is an owner or admin of their own team submits a victim project id together with the attacker's own team_id in the request body; default self-signup grants the required role on the user's own team. Authorization is evaluated against the attacker-selected team instead of the target project's team, and the update path mass-assigns the request body without a project field allow-list. The attacker needs a valid Chartbrew account, an owner or admin role on their own team, and a victim project identifier; requests without the body team_id trick are rejected. The attacker can re-parent the victim project into their own team, gain full read and write access, expose it publicly, remove password protection, and cause the victim to lose it; the shared delete route also permits cross-tenant deletion. This issue is fixed in version 5.2.3.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS