Chartbrewに認証済みユーザーが他社のプロジェクトを乗っ取れる脆弱性
概要
Chartbrewの5.2.3より前のバージョンには、リクエストで指定したteam_idを権限確認に使ってしまう脆弱性(CVE-2026-85712)があります。有効なアカウントを持つ利用者が、他社のプロジェクトを自社に移したり、閲覧・編集・削除したりできるおそれがあり、CVSSは8.8です。修正版の5.2.3で対応できるため、速やかにアップデートしてください。
AI要約
SecPulse が外部の生成 AI を使って作った要約です。誤りを含むことがあります。重要な判断の前に、下の原文と参照URLを確認してください。
Chartbrewの5.2.3より前のバージョンには、リクエストで指定したteam_idを権限確認に使ってしまう脆弱性(CVE-2026-85712)があります。有効なアカウントを持つ利用者が、他社のプロジェクトを自社に移したり、閲覧・編集・削除したりできるおそれがあり、CVSSは8.8です。修正版の5.2.3で対応できるため、速やかにアップデートしてください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
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.
出典: CVE.org (CVE Program・cvelistV5) NVD