機械学習基盤の Kubeflow Pipelines（Kubernetes 上で ML パイプラインを回す OSS）の API サーバに、高深刻度（CVSS いずれも 7.5）の脆弱性が2件見つかり、2.18.0 で修正された。実行ログの無認可アクセス（CVE-2026-118759）と、アップロードの解凍爆弾による DoS（CVE-2026-118761）だ。この記事は、GHSA を一次情報に、Kubeflow Pipelines 脆弱性の正確な前提（インターネット直公開ではなく「バックエンドに到達できる」こと）と、自分の環境の確認・緩和を整理する。攻撃の再現手順（PoC）は扱わない。今すぐ確かめることは一つ——稼働中の Kubeflow Pipelines が 2.18.0 以上かどうかだ（確認手順は後述）。

WHAT HAPPENED2件・ともに2.18.0で修正

Kubeflow Pipelines のAPIサーバに2つの穴

  1. 2026-10-29 GHSA公開

    ML基盤 Kubeflow Pipelines のAPIサーバに2件の高深刻度(CVSS 7.5)。ともに 2.18.0 で修正、2.17.3 までが影響

  2. ① ログの無認可アクセス

    CVE-2026-118759。run-logエンドポイントがRunへの権限を確認せず、他Podのログを読める(CWE-862/200)

  3. ② 解凍爆弾でDoS

    CVE-2026-118761。アップロードしたアーカイブを認可前に解凍、小さなZIPでメモリ枯渇(CWE-409)

  4. 前提はバックエンド到達

    どちらも『APIサーバに到達できる』ことが前提。外部認証ゲートやネットワークポリシーで到達性を絞るのが設計前提

出典: GHSA-wg5q-x4j9-qm54 / GHSA-8fmv-6rg5-5924（2026-11-02 確認）。公開2026-10-29

30秒でわかる（2026-11-02確認）

  • ・Kubeflow Pipelines の API サーバに高深刻度(7.5)が2件。ともに 2.18.0 で修正、2.17.3 までが影響。
  • ・① ログ無認可アクセス(CVE-2026-118759)：Runへの権限を確認せず、他Podのログ(機密・認証情報を含みうる)を読める。
  • ・② 解凍爆弾DoS(CVE-2026-118761)：アップロードを認可前に解凍、小さなZIPでメモリ枯渇。
  • ・前提はバックエンド到達。インターネット直公開ではなく、到達できる内部者・侵入済みワークロード・緩い到達制御が主な脅威。

基盤ソフトの脆弱性がどう広がるかの全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。今回はその中でも、ML/MLOps のコントロールプレーンという、権限境界が曖昧になりやすい層の話だ。

何が起きたのか：APIサーバの2つの穴

2026年10月29日、Kubeflow Pipelines のセキュリティアドバイザリが2件公開された。どちらも API サーバ（バックエンド）の問題で、CVSS 3.1 は 7.5（High）。まず、2件の性格の違いを押さえる。

TWO BUGS何が起きるか

ログが読まれる／メモリが枯れる

① ログ無認可 (CVE-2026-118759)

② 解凍爆弾DoS (CVE-2026-118761)

① ログ無認可 (CVE-2026-118759): GET .../runs/{id}/nodes/{node}/log が権限確認なし

② 解凍爆弾DoS (CVE-2026-118761): アップロードのアーカイブを認可より先に解凍

① ログ無認可 (CVE-2026-118759): Run IDとPod/ノードIDを知る到達者がログを読む

② 解凍爆弾DoS (CVE-2026-118761): 小さなZIP/gz-tarで展開後が肥大しメモリ枯渇

① ログ無認可 (CVE-2026-118759): ログに機密データや認証情報が混じりうる

② 解凍爆弾DoS (CVE-2026-118761): APIサーバが停止しサービス中断(可用性)

出典: 両GHSAの説明（2026-11-02 確認）。CVSSは各7.5(①C:H ②A:H)。必ず落ちるアーカイブが在るわけではない
  ① CVE-2026-118759 ② CVE-2026-118761
種類 ログの無認可アクセス（情報漏えい） 解凍爆弾による DoS
CWE CWE-862 / CWE-200 CWE-409
CVSS 3.1 7.5（C:H／機密性） 7.5（A:H／可用性）
原因 run-log エンドポイントが Run への権限を確認せず アップロードを認可前に展開上限なく解凍
何が起きる 他 Pod のログ（機密・認証情報を含みうる）を読める 小さな圧縮ファイルでメモリ枯渇、API 停止
修正 PR #13684（readLog 認可＋ラベル照合） PR #14171/#14186（展開・走査の上限）

① ログの無認可アクセス（CVE-2026-118759）。 問題は GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log というエンドポイントだ。ここが、呼び出し元がその実行（Run）に対する権限を持つかを確認せずにログを返していた。ライブログの場合、ノードIDが名前空間内の Pod 名として扱われ、その Pod が本当にその Run に属するか検証されない。結果、API サーバの Pod ログ権限によっては、無関係な Pod の main コンテナのログまで読めてしまう。ログには学習データや認証情報が混じりうるため、情報漏えいだ。

② 解凍爆弾による DoS（CVE-2026-118761）。 パイプラインのアーカイブをアップロードする経路で、API サーバが展開後のデータサイズを制限せずに解凍していた。やっかいなのは、マルチパートのアップロードでは名前空間の認可より先に解凍が走るため、パイプライン作成権限すら不要だった点だ。小さな ZIP や gzip 圧縮 tar でも、展開後が極端に大きくなればメモリを食い潰し、API サーバを止めうる。ただし「必ず落ちるアーカイブが存在する」わけではない、ともアドバイザリは慎重に書いている。

なぜ「7.5・権限不要」を鵜呑みにしないか

両者の CVSS ベクトルは AV:N（ネットワーク）・PR:N（権限不要）で、数字だけ見ると「ネット越しに誰でも」と読めてしまう。だがここは前提を外さないことが大切だ。アドバイザリは明確に、攻撃者が API サーバ（バックエンド）に到達できることを前提とし、外部の認証ゲートやネットワークポリシーで到達性を制限している構成を想定している。公開インターネットへの露出や、Run ID の列挙までは前提に含まれていない。

つまり現実的な脅威は、同じクラスタ／ネットワークから API サーバに届く内部者、侵入済みのワークロード（横移動）、そして到達制御が緩い環境だ。マルチテナントの ML 基盤では、テナント間の境界がこのコントロールプレーンに集約されるため、「権限不要でログが読める」「権限不要でサービスを止められる」ことの意味は小さくない。過大評価も過小評価もせず、到達できる面を絞りつつ、確実に 2.18.0 へ上げるのが妥当な温度感だ。開発基盤を狙う攻撃の近接事例はCursor 改ざん拡張のSSHバックドアやVercel Domains のレジストラ乗っ取りも参考になる。

自分の環境を確認し、緩和する

まず稼働中の Kubeflow Pipelines の版を確認する。影響は 2.17.3 までで、最初に影響を受けた版は特定されていない（＝古いほど対象だと思って確認する）。

# APIサーバ(またはmanifest)のイメージタグから版を確認する例
kubectl -n kubeflow get deploy ml-pipeline \
  -o jsonpath='{.spec.template.spec.containers[0].image}'; echo
# 稼働中Podのイメージを一覧して版を突き合わせる
kubectl -n kubeflow get pods -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

表示されたタグが 2.18.0 以上なら修正済み、下回っていれば未対応だ。ただしこの版表示だけでは判断できないこともある——到達制御が十分か、すでにログが読まれていないか、は版番号には表れない。版が古いと分かったら、更新と並行して到達面の見直しと（心配なら）アクセスログの監査も要る。恒久策はアップグレードで、① は readLog 認可と Pod ラベル照合、② は展開データと tar 走査の上限で直る。

CHECK & FIX確認と対策

2.18.0へ、到達性を絞り、上限を設定

  1. 1.版を確認（2.17.3まで影響）

    稼働中の Kubeflow Pipelines の版を確認。2.18.0 以上かを見る。最初に影響した版は特定されていない

  2. 2.2.18.0 へ更新

    恒久策はアップグレード。① は readLog 認可とPodラベル照合、② は展開データとtar走査の上限で修正

  3. 3.バックエンドAPIの到達を絞る

    更新まで、ログ/アップロード/インポートのエンドポイントへのアクセスを外部認証・ネットワークポリシーで制限

  4. 4.2.18の上限設定を見直す

    ② の対策は、2.18 で入ったアップロード/仕様のリミットを自分のリソース予算に合わせて調整する

出典: 両GHSAの対策欄・PR #13684/#14171/#14186（2026-11-02 確認）

すぐに上げられない場合は、到達面を絞るのが当座の緩和だ。ログ・アップロード・インポートのバックエンドエンドポイントへのアクセスを、外部認証や Kubernetes の NetworkPolicy で制限する。あわせて、API サーバに CPU/メモリの limits を設定しておくと、② の影響（1 Pod のメモリ枯渇）がノード全体へ波及するのを抑えられる。これらは面を狭める策であって根本修正ではないので、最終的には 2.18.0 への更新が必要な点は変わらない。

悪用に気づけるか：監査の目のつけどころ

未更新の期間があったなら、「読まれていないか・突かれていないか」を見ておきたい。① については、API サーバのアクセスログで /apis/v1alpha1/runs/.../nodes/.../log への呼び出しを洗い、呼び出し元と対象 Run の持ち主が食い違うもの、短時間に多数の Run/ノードIDを舐めるような連続アクセスを探す。正規の利用でもこのエンドポイントは叩かれるので、単発のアクセスだけで悪用と断定はできない——持ち主との不一致や列挙的なパターンと併せて見るのが筋だ。

② については、API サーバのメモリ使用の急なスパイクや OOM による再起動、そしてアップロード/インポート経路への異常に小さいのに展開が重いアーカイブの投入が兆候になる。Kubernetes 側では Pod の再起動回数（kubectl get pods の RESTARTS）や OOMKilled イベントが手掛かりだ。いずれも確実な証拠ではないが、更新前の窓があったなら、これらを一度さらっておくと安心材料になる。根本策はあくまで 2.18.0 への更新で、監査はその補助だと位置づけてほしい。

影響範囲と結論

影響するのは Kubeflow Pipelines の API サーバを動かしている環境で、とくに複数チーム・複数テナントで共有している ML 基盤ほど、ログ漏えいと DoS の意味が大きくなる。ML のパイプラインログには、前処理に渡したデータの断片、接続先の認証情報、モデルやデータセットの所在といった、そのまま次の攻撃の足がかりになる情報が流れていることが珍しくない。「ログくらい」と軽く見ず、①を情報漏えいとして扱うのが妥当だ。逆に、API サーバを厳重に隔離し、到達できる主体を強く絞っている単一テナント環境では、相対的にリスクは下がる。いずれにせよ修正版は出ているので、更新の計画に乗せるのが確実だ。幸い、対応はカーネルのような再起動を伴う大掛かりなものではなく、コンポーネントのイメージを 2.18.0 系へ上げる通常のアップグレード手順に乗せられる。止められない事情があるなら、まず到達面の遮断で時間を稼ぎつつ、計画的に上げればよい。

この記事の結論

  • ・Kubeflow Pipelines の API サーバに高深刻度2件（各 CVSS 7.5）。①ログ無認可アクセス（CVE-2026-118759）、②解凍爆弾DoS（CVE-2026-118761）。
  • ・ともに 2.18.0 で修正（2.17.3 まで影響）。前提は「API サーバに到達できる」こと＝内部者・横移動・緩い到達制御が主な脅威。
  • ・確認は稼働イメージの版。更新まではバックエンドの到達面を絞り、API サーバに resource limits を設定。
  • ・マルチテナントの共有 ML 基盤ほど優先度が高い。根本策は 2.18.0 への更新。

参照ソース