Beta9 のマルチテナント環境で、ワークスペーストークンを持つ利用者がワーカーのホスト側ファイルを読み書きできるおそれ（CVE-2026-120306〜120308、CVSS 9.9）: ワーカー 0.1.756 で修正

NVD は 2026-11-01 に、機械学習の処理向けのサーバーレス実行基盤「Beta9」（beam-cloud）の脆弱性 3 件（CVE-2026-120306〜120308）を登録しました。いずれもマルチテナント構成で、ワークスペーストークンを持つ利用者（テナント）が、自分のコンテナの外にあるワーカー（実行ノード）側のファイルシステムに届くという問題です。登録元（CNA）は JFrog で、CVSS v3.1 は 3 件とも 9.9（CRITICAL）です。修正は 2026-09-15 公開のワーカー 0.1.756（CVE-2026-120308 はゲートウェイ 0.1.776 も必要）に入っており、NVD への登録より前に配布されています。

3 件の内容

CVE	内容	CWE
CVE-2026-120306	イメージビルドの RUN 手順が、ワーカーの PID・ネットワーク・IPC・ユーザーの名前空間を共有したまま root で動く。ワーカーのコンテナのファイルシステム（実行用バイナリ、Kubernetes のサービスアカウントトークン、マウントされたホストのディレクトリ）に書き込める	CWE-269
CVE-2026-120307	サンドボックスのファイル API が、コンテナ内のパスをワーカー側のパスに変換する際に「..」を正規化するのが検査のあとになる。ワーカー上の任意のパスの読み取り・書き込み・一覧・削除が root 権限でできる。同じ機械上の他のテナントのファイルも対象	CWE-22
CVE-2026-120308	関数・エンドポイント・タスクキューにボリュームを付ける際、ボリューム識別子が自分のワークスペースのものか検査されない。「..」を含む識別子でワーカーのルートがマウントされ、読み書き可能になる	CWE-22

何が起きるか

• 前提は、ワークスペーストークンを持つこと（権限は低）です。ネットワーク経由で、操作なしに実行できると CNA は評価しています。
• CVE-2026-120306: ワーカーのイメージは Buildah の分離方式を chroot にしており、呼び出しで分離方式を指定していません。そのため RUN 手順は、ルートを切り替えるだけで、ワーカーの Pod と同じ名前空間のまま root（CAP_DAC_OVERRIDE を保持）で動きます。procfs の PID 1 はワーカーの起動プロセスで、その root 経由でワーカーのコンテナのファイルシステムが書き込み可能になります。ワーカーの Pod は特権付きです。Clip v2 の階層ビルドが既定のため、テナントはイメージビルドを 1 回投入するだけで届くと、CNA は書いています。確認された範囲は読み取りだけの検証（共有の名前空間、CAP_DAC_OVERRIDE、ワーカーの runc の可視性）です。
• CVE-2026-120307: マウント先で始まるパス（既定のアップロード用マウント /tmp/.beta9 を含む）は、残りの部分がマウント元に連結され、「..」が連結後に整理されます。十分に長く並べると、ワーカー上の任意の絶対パスを指せます。どのマウントにも一致しないパスは、ワーカー自身のファイルシステムで開かれ、絶対シンボリックリンクがワーカーのルートに対して辿られます。アップロード・ダウンロード・stat・一覧・ファイル内検索・置換・削除のすべてが同じ変換を使います。
• CVE-2026-120308: ゲートウェイは、共有ボリュームのルート・ワークスペース名・ボリューム識別子を連結してホストのパスを作りますが、識別子が自分のワークスペースのボリュームかを検査しません。ワーカーはそのパスを、読み取り専用と明示されない限り読み書き可能でサンドボックスにバインドマウントします。他のテナントのボリュームにも届きます。ゲートウェイ 0.1.769・ワーカー 0.1.745 で確認されたと、CNA は書いています。
• CNA は、読み取りだけの検証でワーカーの Kubernetes サービスアカウントトークンを取得できたと説明しています。同梱のリモートノード用マニフェストでは、そのサービスアカウントに cluster-admin が割り当てられているとのことです。クラスター全体への影響は、この記述に基づく CNA の説明で、本サイトでは再現していません。
• 実際の悪用は確認していません。具体的なパスや手順は載せません。

修正の状況

• ワーカー 0.1.756（2026-09-15 公開）: Buildah の RUN 手順（WORKDIR の mkdir を含む）で OCI 分離を使い、PID・IPC・ネットワークの名前空間を分けます。テナントの ARG 値はビルド用コンテナにだけ渡します。サンドボックスのファイル操作とワークスペース同期は os.OpenRoot でパスを開き、親ディレクトリや絶対シンボリックリンクがコンテナのルートやマウント元の外に出られないようにします。
• ゲートウェイ 0.1.776（2026-09-15 公開）: ボリューム識別子とマウントパスを、マウントを作る前に検証します。存在しないボリューム、ワークスペースの所有でないボリュームは拒否します。修正前に保存されたスタブにも検証が働きます。
• 修正のコミットは GitHub の beam-cloud/beta9 の a28bf12（「Handle sandbox edge cases (#1897)」、2026-09-15）です。リポジトリの最新リリースは、2026-11-02 時点でゲートウェイ 0.1.840（2026-10-31）です。

数値と出典（2026-11-02 時点）

項目	内容
CVE	CVE-2026-120306、CVE-2026-120307、CVE-2026-120308
影響版	CVE-2026-120306・120307: ワーカー 0.1.756 未満。CVE-2026-120308: ゲートウェイ 0.1.776 未満、またはワーカー 0.1.756 未満（影響の下限の版は確認できていません）
修正版	ワーカー 0.1.756、ゲートウェイ 0.1.776
CVSS v3.1	3 件とも 9.9 CRITICAL（AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H）。JFrog（CNA）の値
NVD の状態	Received（NVD 自身の評価は未実施）
EPSS	公開直後のため未算出（2026-11-02 に FIRST の API を確認、3 件とも該当データなし）
KEV	掲載なし（CISA の JSON、カタログ版 2026.10.30 で確認）

severity を critical とした理由

CVSS v3.1 は 3 件とも 9.9 で、低い権限のトークンだけで、操作なしにネットワーク越しにワーカーのホスト側へ届きます。マルチテナント基盤では、テナント間の隔離が破れることが設計の前提を崩し、他のテナントのデータにも届きます。一方で、ワークスペーストークンが必要で、この基盤を自分で運用している環境に限られます。修正版は 1 か月以上前に出ており、EPSS は未算出（公開直後の可能性）、KEV にも載っていません。それでも、該当する環境では隔離の破綻が全体に及ぶため critical としました。

対応として考えられること

1. Beta9 を自前で運用しているかを確認し、ゲートウェイとワーカーの版を調べます。
2. ワーカー 0.1.756 未満、またはゲートウェイ 0.1.776 未満があれば、更新します（最新のゲートウェイは 0.1.840）。
3. 更新までの間は、信頼できない利用者へのワークスペーストークンの発行を止めることが考えられます（推定。効果は確認していません）。
4. 修正前の版を、信頼できないテナントに開放していた場合は、ワーカーのサービスアカウントトークンの再発行と、クラスターの監査ログ・ワーカー上のファイルの変更の確認を検討します（推定）。
5. ワーカーのサービスアカウントの権限（cluster-admin の割り当て）を最小限にすることも考えられます（推定）。

未確認の点

• 実際の悪用は確認していません。
• 影響を受ける最初の版は確認できていません。
• サービスアカウントトークンを使ったクラスター全体への影響は、CNA の記述に基づくもので、本サイトでは再現していません。
• 修正版の変更内容の網羅性は検証していません。
• NVD 自身の評価は未実施（Received）です。CVSS は JFrog（CNA）の値です。