CVE-2026-40904
Received Received - Intake
Chartbrew Team-Level Privilege Escalation in Dataset Access

Publication date: 2026-04-30

Last updated on: 2026-04-30

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. In version 4.9.0, Chartbrew exposes multiple dataset and dataRequest endpoints that authorize low-privileged project members at the team level instead of binding the requested dataset_id, dataRequest id, and connection_id to the caller's allowed projects. An authenticated attacker who only has access to one project inside a team can read, execute, create, update, and delete datasets and data requests that belong to other projects in the same team. The issue is exploitable remotely with ordinary project-level credentials and leads to cross-project data disclosure and unauthorized use of victim-side database or API connections. This issue has been patched in version 5.0.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-30
Last Modified
2026-04-30
Generated
2026-05-07
AI Q&A
2026-04-30
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
chartbrew chartbrew to 5.0.0 (exc)
chartbrew chartbrew 5.0.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-284 The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-40904 is a vulnerability in Chartbrew versions 4.9.0 and earlier where the application incorrectly enforces access control on dataset and dataRequest endpoints.

Instead of restricting access to datasets and data requests based on the specific project the user belongs to, the system only checks if the user has team-level access. This means an authenticated user with access to one project in a team can access, modify, or delete datasets and data requests belonging to other projects within the same team.

The flaw arises because permission checks do not verify that the requested dataset_id, dataRequest id, or connection_id actually belong to the caller's allowed projects, allowing cross-project unauthorized actions.


How can this vulnerability impact me? :

This vulnerability can have serious impacts including unauthorized disclosure and modification of data across projects within the same team.

  • An attacker with access to one project can read sensitive data from other projects.
  • They can execute data requests on behalf of other projects, potentially running queries against victim-owned database or API connections.
  • Attackers can create, update, or delete datasets and data requests in other projects, leading to data tampering or disruption of data retrieval processes.

Overall, this leads to significant confidentiality and integrity risks, though availability is not affected.


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

Detection of this vulnerability involves verifying whether an authenticated user with access to one project can access datasets or data requests belonging to other projects within the same team. Since the issue arises from improper access control on dataset and dataRequest endpoints, testing unauthorized cross-project access attempts can reveal the vulnerability.

Specifically, an attacker with valid credentials for one project can attempt to read, execute, create, update, or delete datasets or data requests from other projects by using the dataset_id, dataRequest id, or connection_id of those projects.

While no explicit commands are provided, detection can be performed by making authenticated API requests to the dataset and dataRequest endpoints with IDs from other projects and observing if access is granted.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade Chartbrew to version 5.0.0 or later, where this vulnerability has been patched.

Until the upgrade can be performed, restrict access to the affected endpoints by limiting project-level user permissions and monitoring for suspicious cross-project access attempts.

Additionally, review team and project membership to ensure that only trusted users have access, and consider temporarily disabling or restricting API access to dataset and dataRequest routes if feasible.


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

This vulnerability allows an authenticated attacker to access, modify, and execute data requests and datasets across different projects within the same team, leading to unauthorized disclosure and tampering of potentially sensitive data.

Such unauthorized access and data disclosure can violate data protection principles required by common standards and regulations like GDPR and HIPAA, which mandate strict controls on data confidentiality, integrity, and access authorization.

Therefore, exploitation of this vulnerability could result in non-compliance with these regulations due to improper access control and potential exposure of sensitive personal or health-related data.


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