Backstage は、開発者ポータル(社内のサービスや文書、作成の手順をまとめた社内のサイト)を作るオープンソース の仕組みです。このBackstageに、認可の脆弱性 (CVE-2026-106495)が公表されました。管理者が設定で外したアクション(操作)を、ログインした利用者が実行できたものです。
深刻度は中程度(CVSS 4.3)で、直した版は8月28日に出ています。GitHub の脆弱性データベース は日本時間10月16日、この告知を確認済みとして載せました。Backstageの告知、修正のコード、公式の文書で確かめた内容だけを書きます。
Backstageの「アクション」とは
Backstageの裏側(バックエンド)では、各プラグイン(機能の部品)が「アクション」を登録できます。アクションは、カタログの情報を調べる、といった操作の単位です。IDは「catalog:fetch-user-info」のように、プラグインの名前で始まります。
MCPは、AIと外の道具をつなぐ決まりです。BackstageのMCP Actions Backendは、登録されたアクションを、MCPの道具としてAIに渡します。文書では、アクションの仕組みは試験的な機能(alpha)の扱いです。
どのアクションを使わせるかは、設定ファイル(app-config)で絞れます。backend.actions.pluginSourcesは、アクションを登録してよいプラグインの一覧です。backend.actions.filterは、IDの型や、destructive(壊す操作か)などの性質で、含めるものと外すものを決めます。
Backstageの文書のActionsの設定の節。アクションを絞る設定の例が並ぶ 出典: Backstage (引用) 何が起きていたか
告知の説明は短く、次のとおりです。
An authenticated user could invoke actions that an operator had excluded through action configuration. Existing action permissions and downstream authorization remain enforced.
出典: Backstage「Improper access control in backend action invocation」
ログインした利用者が、管理者がアクションの設定で外したアクションを呼べた、という意味です。アクションに付けた権限の確認と、その先の認可は効いたままだったとしています。
修正のコードを読むと、仕組みが分かります。修正の前は、設定による絞り込みは、呼ぶ側(Actionsのサービス)が一覧を作るときにだけ効いていました。実行の要求はそのまま各プラグインの窓口(パスに/.backstage/actions/を含むもの)に届き、窓口は設定を見ていませんでした。
修正後は、各プラグインの窓口でも同じ設定を見ます。外したアクションは一覧に出ず、呼ぶと「見つからない」が返ります。
GitHubのデータベースのBackstageの告知。対象と直した版、回避策が並ぶ 出典: GitHub(GitHub Advisory Database) (引用) CVSSの内訳では、ネットワーク越しに狙え、ログイン(低い権限)が要り、相手の操作は要りません。影響は改ざんが「低」で、情報の漏えいと停止は「なし」です。米国CISAの評価(SSVC)は、悪用が「なし」、自動で繰り返せるかが「いいえ」、影響が「部分的」です。
困るのは、危ない操作を設定の絞り込みだけで止めていた場合です。たとえば「destructiveがtrueのアクションを外す」設定で、AIに消す操作をさせないようにしていても、ログインした人はその操作を呼べました。アクションに権限(visibilityPermission)を付けていれば、その確認は効いていました。
MCPの窓口ごとの絞り込み(mcpActions.serversのfilter)は、AIに見せる道具を分けるためのものです。文書は、既定の窓口(/api/mcp-actions/v1)はいつも、登録されたすべてのアクションを出すと書いています。止めたい操作は、backend.actionsの設定や権限で止めます。
対象の版と直した版
部品・リリース
対象
直した版
@backstage/backend-defaults
0.17.8より前
0.17.8(8月28日)
Backstage全体のリリース
1.54.6より前(CVEの記録)
1.54.6(8月28日)
Backstageは、リリースごとの部品の版の一覧(versionsリポジトリ)を公開しています。これによると、1.54.6に入るbackend-defaultsは0.17.8です。9月15日の1.55.0には0.18.0が入っていて、編集部がコードを見たところ、この修正も入っています。
1.54.6のリリースノートにCVEの番号は無く、「バックエンドのアクションの扱いの改善」と書かれています。
古い系列の修正のリリースには注意が要ります。次の版に入るbackend-defaultsは、どれも告知の対象の範囲に入ります。
1.51.3(8月29日): 0.17.2
1.50.7(9月25日): 0.17.0
1.49.6(8月29日): 0.16.1
悪用について、告知に記載はありません。米国CISAのKEV(悪用が確認された脆弱性の一覧)には、10月16日版で載っていません。NVD(米国の脆弱性データベース)は、10月17日時点で分析の前です。
同じ0.17.8で直るほかの告知
Backstageの告知の一覧で、公開日が8月28日のものは、この件を含めて37件あります。そのうち、backend-defaultsの0.17.8が直した版に挙がっているのは、次の4件です。
告知
中身(告知の要約)
CVSS
GHSA-cq7v-rfgc-5c7v(CVE-2026-106492)
制限を付けた外部の呼び出し用の資格情報が、プラグインどうしの呼び出しの経路を通すと、制限を越えられた
7.6(High)
GHSA-7649-wm97-w3j3(CVE-2026-106494)
Backstageが使うクラウドのストレージに書き込める人が、名前を細工して、出力先の守るべきファイルと重ねられた
4.4(Medium)
GHSA-3xr5-8w6c-p5gw(CVE-2026-106495)
設定で外したアクションを実行できた(この記事の件)
4.3(Medium)
GHSA-xvh9-35w9-42m4(CVE-2026-106493)
AzureとAWSのストレージからカタログを読む機能が、決めた範囲の外を読めた(カタログの部品の更新も要る)
3.0(Low)
いちばん深刻なGHSA-cq7vは、accessRestrictionsを使う会社に関わります。accessRestrictionsは、外部の道具に渡す固定のトークンなどに付ける、使えるプラグインや権限の制限です。読み取りだけに制限したはずの資格情報で、書き込みもできたと告知は書いています。
MCPの文書の設定例も、AIのクライアントに渡す固定のトークンにaccessRestrictionsを付けています。GHSA-cq7vの告知は、上げるまでのつなぎに、バックエンドのAPIへの接続を信頼できる呼び出し元だけにすることなどを挙げています。0.16系では、0.16.1でも直っています。
認証の部品の別の脆弱性は、Backstageの認証部品に脆弱性、実験機能の設定と修正版を確認 で扱いました。こちらは実験的な機能の設定が条件で、直す部品も別(@backstage/plugin-auth-backend)です。
影響する会社・しない会社
影響する: Backstageを自社で動かし、backend-defaultsが0.17.8より前で、設定(backend.actionsのpluginSourcesかfilter)でアクションを外している会社
影響する: とくに、MCP Actions BackendでAIのクライアントにアクションを渡し、危ない操作を設定で外している会社です
影響しない: backend-defaultsを0.17.8以降にした会社(この件について)。Backstageのリリースでは1.54.6以降です
影響しない: アクションを外す設定をしていない会社は、この件で新しく呼べる操作はありません(編集部の整理)。ただし、同じ版で直るほかの告知があるので、更新は要ります
影響しない: Backstageを使っていない会社
確認が要る: 1.49〜1.51系など、古い系列のリリースに留まっている会社。その系列の最新の修正のリリースでも、backend-defaultsが0.17.8より前のことがあります
確認が要る: 開発会社や委託先がBackstageを運用している会社。版と設定は、運用している側に聞きます
情シスが今日やること
Backstageを使っているか、誰が運用しているかを確かめます。 開発部門や委託先に聞きます。社外から開けるかどうかも確かめます。@backstage/backend-defaultsの版を確かめます。 運用の担当者に、依存関係の一覧(yarn.lockなど)にある版を聞きます。0.17.8より前なら対象です。Backstage全体のリリースの版だけで判断しないでください。設定を書き出します。 app-configのbackend.actions(pluginSources・filter)、mcpActions、backend.auth.externalAccessのaccessRestrictionsを開きます。何を外し、何を制限しているかを一覧にします。上げるまでの守りを入れます。 告知の回避策は、アクションの実行の窓口への接続を、信頼できるサービスからの呼び出しだけに絞ることです。中継のサーバー(リバースプロキシ)で絞る場合は、MCPなどの正規の呼び出しが止まらないかを、検証用の環境で確かめます(編集部の補足)。1.54.6以降へ上げる日を決めます。 担当者と期限を決め、開発部門に知らせます。上げた後も、危ないアクションは設定の絞り込みだけに頼らず、権限(visibilityPermission)でも守ります(編集部の補足)。 
