CVE-2026-40603
Information Disclosure in Chartbrew Dashboard
Publication date: 2026-04-30
Last updated on: 2026-04-30
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| chartbrew | chartbrew | to 4.9.0 (inc) |
| chartbrew | chartbrew | 5.0.0 |
Helpful Resources
Exploitability
| 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-40603 is an Incorrect Access Control vulnerability in the Chartbrew application affecting the legacy dashboard route `/api/project/dashboard/:brewName`.
This flaw allows any authenticated user who is a member of the same team to access and read another project's dashboard data, even if they do not have explicit permissions for that project.
The vulnerability occurs because the route only checks the user's team membership but does not enforce project-level authorization, returning the full raw project object including sensitive information like the stored report password.
An attacker can exploit this by sending a GET request to the vulnerable endpoint with a known or guessed project identifier (`brewName`), thereby retrieving unauthorized project data.
How can this vulnerability impact me? :
This vulnerability allows a low-privileged user within the same team to access sensitive project dashboard data they should not see.
- Unauthorized disclosure of project dashboard content.
- Exposure of sharing configurations.
- Leakage of stored report passwords.
Such unauthorized access can lead to information leakage and potential misuse of sensitive project data, posing a moderate security risk.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking for unauthorized access attempts to the legacy dashboard route `/api/project/dashboard/:brewName` in Chartbrew versions up to 4.9.0. An attacker exploits this by sending a GET request to this endpoint with a guessed or known `brewName` to retrieve project data without proper authorization.
To detect exploitation attempts on your system or network, you can monitor HTTP GET requests to the vulnerable endpoint and look for unusual access patterns or requests from low-privileged users accessing project data they should not have.
Example command to check web server logs for suspicious GET requests to the vulnerable route:
- grep "/api/project/dashboard/" /var/log/nginx/access.log
- grep "/api/project/dashboard/" /var/log/httpd/access_log
Additionally, you can use curl to test if the endpoint is accessible and returns project data without proper authorization (replace `<brewName>` with a project identifier):
- curl -i -H "Authorization: Bearer <token_of_low_privileged_user>" https://your-chartbrew-instance/api/project/dashboard/<brewName>
If the response contains raw project data including sensitive information like stored report passwords, the vulnerability is present.
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended mitigation step is to upgrade Chartbrew to version 5.0.0 or later, where this vulnerability has been patched.
If upgrading immediately is not possible, consider restricting access to the legacy dashboard route `/api/project/dashboard/:brewName` by implementing network-level controls such as firewall rules or web application firewall (WAF) rules to block or limit access to this endpoint.
Additionally, review and tighten user permissions and team roles to minimize exposure, ensuring that only trusted users have access to the affected routes.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized access to sensitive project dashboard data, including stored report passwords, by authenticated users within the same team but without specific project permissions.
Such unauthorized access to sensitive information could potentially lead to non-compliance with data protection standards and regulations like GDPR and HIPAA, which require strict access controls and protection of sensitive data.
However, the provided information does not explicitly mention the impact on compliance with these standards or any regulatory consequences.