Chartbrew’s project routes trusted a team_id supplied in the request body and failed to confirm that the target project actually belonged to that team. An attacker can submit the victim project’s identifier alongside their own team_id; because the application evaluated the request against the attacker’s team and allowed mass assignment without a project field allow‑list, the victim project can be re‑parented to the attacker’s team. The attacker then gains full read and write privileges, can expose the project publicly, remove password protection, and even delete it through the shared delete route. This flaw falls under CWE‑639, which describes “private data exposure through lack of proper authorization.”

Users running Chartbrew chartbrew with any version earlier than 5.2.3 are affected. The vulnerability is triggered on the application’s /project endpoints and related authorization checks that accept user‑controlled project identifiers.

The vulnerability carries a CVSS score of 8.8, indicating high severity. No EPSS score is available, and the issue is not listed in CISA KEV, but the required conditions—an authenticated account with owner or admin status on the attacker’s own team and a known victim project ID—are typically easy to meet once a user is onboarded. Attackers could perform the takeover over the network with standard HTTP requests, and because the exploit relies on legitimate API paths, detection is unlikely without monitoring for anomalous ownership changes.