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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-11-06T21:17:11.373Z",
  "pubdate": "2026-11-06T21:17:11.373Z",
  "executiveSummary": "Chartbrew versions prior to 5.2.3 are susceptible to an Insecure Direct Object Reference (IDOR) and broken access control vulnerability originating from improper validation of authorization scopes. The flaw allows authenticated users with administrative privileges within their own team to manipulate project ownership and access controls across team boundaries.\nThe vulnerability resides in the application's permission check logic for project routes, which erroneously trusts a user-supplied team_id rather than verifying the internal relationship between the specified project and the authenticated user's authorization context. By crafting requests that pair a victim project ID with the attacker-controlled team_id, an attacker can bypass team isolation protocols.\nThe impact of this vulnerability is critical, as it enables unauthorized re-parenting of any target project into the attacker's team. This grants the attacker full read and write administrative privileges over the victim's data, including the ability to alter public visibility, disable security configurations such as password protection, or permanently delete the project. Exploitation requires a registered account with team ownership or administrative roles, which are easily obtainable via the application's default self-signup functionality.",
  "technicalDetails": "The root cause of this vulnerability is a breakdown in authorization enforcement within Chartbrew's project management modules. The system architecture processes request bodies containing a team_id field to determine authorization context. In the vulnerable versions, the application logic incorrectly trusts the user-provided team_id and proceeds with the teamOwner/teamAdmin execution branch without performing a backend integrity check to confirm that the project identifier in the URL or request body actually belongs to the specified team.\nExploitation follows a specific sequence of operations targeting the project routes. First, an authenticated attacker—possessing a standard account with an owner or admin role—identifies a target project ID. The attacker then constructs a malicious request, such as an update or delete command, incorporating the target project identifier while substituting the team_id parameter with their own team identifier. Because the backend validation routine treats the user-provided team_id as a trusted reference for authorization, it mistakenly grants the attacker's session the permissions associated with the target project, effectively re-parenting the resource.\nFurthermore, the update path exhibits a lack of robust input filtering; it mass-assigns the request body fields directly to the project model without implementing an allow-list for project fields. This missing validation, combined with the flawed permission check, allows the attacker to not only take ownership but also perform arbitrary property modifications. For instance, an attacker can toggle visibility settings or remove access controls, facilitating data exposure.\nThe vulnerability extends to the shared delete route, which also fails to validate the ownership relationship between the user, the team, and the project, allowing cross-tenant deletion of victim projects. The attack is effective because the authorization check is evaluated against the attacker-selected team rather than the project’s legitimate owner. Since self-signup facilitates the acquisition of the required 'team owner' or 'team admin' role, the prerequisite for exploitation is trivial to satisfy. This vulnerability allows for unauthorized resource hijacking, loss of data integrity, and total compromise of project confidentiality across the Chartbrew platform."
}