CVE-2026-32252
Received Received - Intake
Authorization Bypass in Chartbrew Allows Cross-Team Data Access

Publication date: 2026-04-10

Last updated on: 2026-04-14

Assigner: GitHub, Inc.

Description
Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 4.9.0, a cross-tenant authorization bypass exists in Chartbrew in GET /team/:team_id/template/generate/:project_id. The GET handler calls checkAccess(req, "updateAny", "chart") without awaiting the returned promise, and it does not verify that the supplied project_id belongs to req.params.team_id or to the caller's team. As a result, an authenticated attacker with valid template-generation permissions in their own team can request the template model for a project belonging to another team and receive victim project data. This vulnerability is fixed in 4.9.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-10
Last Modified
2026-04-14
Generated
2026-05-07
AI Q&A
2026-04-11
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
depomo chartbrew to 4.9.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-285 The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-32252 is a cross-tenant authorization bypass vulnerability in Chartbrew versions prior to 4.9.0. The issue occurs in the GET endpoint /team/:team_id/template/generate/:project_id, where the access control function checkAccess is called without awaiting its promise, and the code does not verify that the requested project_id belongs to the specified team_id or the caller's team.

As a result, an authenticated attacker with valid template-generation permissions in their own team can request and receive template data for projects belonging to other teams, leading to unauthorized data exposure.


How can this vulnerability impact me? :

This vulnerability can lead to severe data leakage across teams within the Chartbrew application. An attacker with valid permissions in their own team can access sensitive project data from other teams.

  • Exposure of victim chart names and variables.
  • Disclosure of dataset and data request structures.
  • Leakage of decrypted connection hosts.
  • Exposure of decrypted request headers and bodies, including bearer tokens, API credentials, and other secrets.

Because sensitive authentication tokens and secrets can be leaked, this vulnerability poses a high confidentiality risk and can compromise the security of affected systems.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by testing the vulnerable endpoint GET /team/:team_id/template/generate/:project_id for unauthorized access to projects belonging to other teams. Specifically, an authenticated user with template-generation permissions in their own team can attempt to request template data for a project from a different team.

A practical detection method involves sending a GET request to the endpoint using a valid bearer token for one team but specifying a project_id that belongs to another team. If the response returns HTTP 200 OK with template data including sensitive information such as chart names, variables, decrypted connection hosts, headers, or bodies, the system is vulnerable.

Example command using curl to test the vulnerability (replace placeholders accordingly):

  • curl -H "Authorization: Bearer <attacker_token>" https://<chartbrew_instance>/team/<attacker_team_id>/template/generate/<victim_project_id>

If the response contains victim project data or secrets, the vulnerability exists.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading Chartbrew to version 4.9.0 or later, where the vulnerability is fixed.

The fix involves:

  • Ensuring the access control function checkAccess is properly awaited to enforce authorization checks.
  • Verifying that the project_id in the request belongs to the caller's team by comparing the project's team_id with the user's teamRole.team_id, rejecting requests with a 401 Unauthorized error if they do not match.
  • Converting the GET /generate/:project_id route handler to an asynchronous function to properly await access checks and project retrieval.
  • Sanitizing template data to exclude sensitive fields such as decrypted DataRequest headers and bodies, and sensitive connection information.

If upgrading immediately is not possible, consider restricting access to the vulnerable endpoint and monitoring for suspicious requests attempting cross-team template generation.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows an authenticated attacker to bypass authorization controls and access sensitive project data belonging to other teams, including decrypted connection hosts, request headers, bodies, bearer tokens, API credentials, and other secrets.

Such unauthorized disclosure of sensitive and potentially personal data can lead to violations of data protection regulations and standards like GDPR and HIPAA, which require strict access controls and protection of confidential information.

Because the vulnerability results in high confidentiality impact through secret disclosure, it undermines compliance with these standards that mandate safeguarding sensitive data against unauthorized access.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart