本文へ移動
English version →
高 8.8

Chartbrewに認証済みユーザーが他社のプロジェクトを乗っ取れる脆弱性

CVE-2026-85712 SecPulse初出

概要

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

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく