KubernetesのFaaSフレームワーク「Fission」ルーターに深刻な脆弱性 CVE-2026-46614

Kubernetes上で動作するオープンソースのFaaS（Function as a Service）フレームワーク「Fission」のルーターコンポーネントに、深刻な認証バイパス脆弱性（CVE-2026-46614・Critical）が発見されました。

本脆弱性は、FissionのルーターがすべてのFunctionオブジェクトに対して内部向けルートをHTTPTriggerの設定に関わらず自動的に登録し、しかもそのルートをユーザー定義のHTTPTriggerと同一の公開リスナー（ポート8888）上にマウントしてしまうという設計上の根本的な問題です。これにより、ルーターにネットワークアクセスできる攻撃者は誰でも、本来HTTPTriggerで非公開にしているはずのあらゆるFunctionをメタデータ名を推測するだけで呼び出せる状態になっていました。

さらに同日（2026年5月21日）には、フェッチャーサービスアカウントトークンが関数ユーザーコンテナに自動マウントされてしまう特権昇格脆弱性（CVE-2026-46617・High）も公開されており、FissionをKubernetes環境で利用しているすべての組織に影響します。両脆弱性はFission v1.23.0で修正されています。

今回公開された主要な脆弱性

• 影響を受けるバージョン：Fission v1.23.0未満のすべてのバージョン
• 修正済みバージョン：v1.23.0（2026年5月公開）
• GHSAのバリアント: GHSA-3g33-6vg6-27m8（CVE-2026-46614の認証バイパス）
• 攻撃の前提条件：Fissionルーター（svc/router・ポート8888）へのネットワークアクセスと対象FunctionのKubernetesメタデータ名（および名前空間）の知識

Fissionとは—「Kubernetes上のサーバーレス」の仕組み

本題の脆弱性を理解するために、まずFissionというプラットフォームの基本的な動作を把握しておく必要があります。

Fission（フィッション）は、Kubernetes上でサーバーレス関数（FaaS）を実行するためのオープンソースフレームワークです。AWS LambdaやGoogle Cloud Functionsと同様のサーバーレス体験をKubernetesクラスター上で実現します。開発者はPython・Node.js・Go等で関数コードを書き、fission function createコマンドで登録するだけで、Kubernetesの複雑さを意識せずに関数を実行できます。

Fissionの主要コンポーネントとして以下が含まれます。Function（関数オブジェクト）として、実行するコードと設定を表すKubernetesカスタムリソース（CRD）です。HTTPTrigger（HTTPトリガー）として、どのHTTPパス・ホスト・メソッドでどの関数を実行するかを定義するルーティング設定です。Router（ルーター）として、受信したHTTPリクエストを対応する関数にルーティングするサービスです（svc/router、ポート8888）。Executor（エグゼキューター）として、関数を実行するためのPodを管理するコンポーネントです。

設計の意図では、HTTPTriggerで明示的に設定されていない関数はルーターから到達できないはずです。しかし今回の脆弱性はその前提を根底から覆しました。

CVE-2026-46614の技術詳細—「公開リスナーと内部ルートの混在」

脆弱なコードの場所と動作

GitLab Advisory Database（GHSA-3g33-6vg6-27m8）の公式説明によれば、問題のある実装はpkg/router/httpTriggers.goの280〜284行にあります。

Fissionのルーターは起動時、クラスター内のすべてのFunctionオブジェクトに対して以下の2つのURLパターンの内部ルートを自動登録します。

/fission-function/<function-name>
/fission-function/<namespace>/<function-name>

この登録は当該FunctionにHTTPTriggerリソースが存在するかどうかに関わらず無条件に行われます。そして問題の核心は、これらの内部ルートが、ユーザー定義のHTTPTriggerをすべて処理する公開リスナー（svc/router、ポート8888）と同一のリスナー上にマウントされていることです。

攻撃者が悪用できること

DailyCVEの分析によれば、ルーターへのネットワークアクセスを持つ攻撃者は、対象FunctionのKubernetesオブジェクト名（metadata.name）と名前空間を推測するだけで、次のことが可能です。

HTTPTriggerでホスト・パス・メソッド・許可リスト制限によって公開しないよう設定した関数を呼び出すことができます。KubewatcherターゲットやTimerターゲットなど、本来は内部でのみ実行されるべき管理用関数も呼び出せます。呼び出した関数が持つ権限内で任意の処理を実行できます（データベースへのアクセス・内部APIの呼び出し・他のサービスへの横展開等）。

具体的な攻撃確認コマンドとして、DailyCVEは以下を示しています。

# ルーターへのネットワークアクセスがある場合に、
# 本来非公開のはずの関数を呼び出す例（確認用）
kubectl run test-pod --rm -it --image=alpine/curl --restart=Never -- \
curl -v http://fission-router.fission:8888/fission-function/default/my-secret-function

CVE-2026-46617—同時公開の特権昇格脆弱性

CVE-2026-46614の認証バイパスと同日に公開された**CVE-2026-46617（High）**も、Fissionを使用するすべての環境で確認が必要な重大な問題です。

DailyCVEの分析によれば、FissionのExecutorコンポーネントはFunction実行用Podを作成する際に、サイドカーのfission-fetcherが使用するサービスアカウント（fission-fetcher SA）のトークンをKubernetesのデフォルト仕様により関数のユーザーコンテナにも自動マウントしてしまいます。

これにより、関数コードを展開または更新できるユーザーは、このfission-fetcherサービスアカウントのトークンを読み取り、そのKubernetes API権限を継承することができます。Function.spec.secretsの許可リストで意図的に制限しているはずのKubernetesシークレットやConfigMapにも、名前空間内のすべてのリソースにアクセスできてしまいます。

v1.23.0の修正内容——「リスナーの分離とHMAC認証」

Fission v1.23.0では、CVE-2026-46614に対してアーキテクチャレベルの根本的な修正が施されています（Fission公式v1.23.0リリースノート）。

修正前（脆弱な状態）：

Port 8888 (公開リスナー)
├── ユーザー定義のHTTPTrigger （意図通り）
└── /fission-function/<ns>/<name> （本来内部専用のはずが公開されていた）

修正後（v1.23.0）：

Port 8888 (公開リスナー) ← 外部アクセス可能
├── ユーザー定義のHTTPTrigger
├── /router-healthz
└── /_version

Port 8889 (内部リスナー・ClusterIPのみ) ← 外部アクセス不可
└── /fission-function/<ns>/<name> ← HMAC署名による認証必須

公開リスナー（ポート8888）からは/fission-function/ルートが完全に削除されました。内部リスナー（ポート8889）はKubernetes ClusterIPのみに制限されており、外部から到達できません。さらに内部リスナーへの呼び出しにはクラスターマスターシークレット（service router-internal）から生成されたHMAC署名が必須となりました。また同リリースでNetworkPolicyが追加され、内部リスナーへの到達可能性が必要な内部Podのみに制限されました。

CVE-2026-46617（特権昇格）については、AutomountServiceAccountToken: falseをコンテナレベルで設定し、サイドカーのトークンはProjected Volumeを使って提供する方式に変更されました。これにより関数のユーザーコンテナにはトークンが渡されなくなりました。

v1.23.0へのアップグレードで注意すべき破壊的変更

Fission公式リリースノートは以下の**破壊的変更（Breaking Changes）**を明記しています。

「ルーターの公開リスナーは/fission-function/<ns>/<name>を提供しなくなりました。今日これらのパスを公開ルーターURL（通常はIngress経由）で呼び出している外部ツールは、アップグレード後に404を受け取ります。」

Ingress等を経由してこれらの内部パスを直接呼び出している既存の設定がある場合は、アップグレード前に必ず確認が必要です。

影響範囲—「クラスター内の全Functionの権限外呼び出し」が可能に

本脆弱性の影響が特に深刻なシナリオを整理します。

マルチテナント環境として、複数の開発チームや顧客がFunctionを展開している共有Kubernetesクラスターでは、あるテナントが他テナントの非公開Functionを呼び出すことができます。テナント分離の前提が崩壊します。管理用Functionの悪用として、KubewatcherやTimerによってトリガーされる内部管理用Functionは、通常ビジネスロジックや状態変更を実行するものです。これらが外部から無制限に呼び出せる状態は、システムの整合性を脅かします。ルーターがインターネットに露出している場合として、Fissionルーターがクラスター外からアクセスできる設定になっている場合（LoadBalancer ServiceやIngress経由）は、インターネット上の任意の攻撃者が全Functionを呼び出せる状態です。

暫定緩和策（v1.23.0への即時アップグレードが困難な場合）

DailyCVEが示す暫定的なNetworkPolicyによる緩和策は以下の通りです。

# Fissionルーターへのアクセスをingress-nginxのNamespaceのみに制限する例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-internal-route
namespace: fission
spec:
podSelector:
matchLabels:
app: router
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-nginx
ports:
- port: 8888
policyTypes:
- Ingress

ただしNetworkPolicyはKubernetesのCNI（コンテナネットワークインターフェイス）プラグインがNetworkPolicyをサポートしていることが前提です。あくまでも暫定措置であり、可能な限り早急にv1.23.0へのアップグレードを実施してください。

正式な対応手順

# Step 1: 現在のバージョンを確認
kubectl get deploy -n fission fission-router -o yaml | grep image

# Step 2: Helmでv1.23.0へアップグレード
helm upgrade fission fission/fission-all \
  --namespace fission \
  --version v1.23.0

# Step 3: KEDAを使用している場合は追加オプションが必要
helm upgrade fission fission/fission-all \
  --namespace fission \
  --version v1.23.0 \
  --set internalAuth.enabled=false  # KEDA使用時のみ（KEDAコネクターが署名に未対応のため）

# Step 4: アップグレード後の確認
# 内部パスに対して404が返ることを確認
kubectl run test-pod --rm -it --image=alpine/curl --restart=Never -- \
  curl -v http://fission-router.fission:8888/fission-function/default/any-function
# → 404 Not Found を確認（修正済みの状態）

日本企業・開発チームへの含意

Fissionは国内でも金融・製造・SaaS企業のKubernetes基盤上のサーバーレス処理に活用されているケースがあります。特に以下の点を確認してください。

Fissionルーター（svc/router）がLoadBalancer Service等を通じてクラスター外部からアクセス可能な状態になっていないかを確認してください。クラスター内から別のPodがFissionルーターに対して/fission-function/パスへのアクセスを行うような設定が残っていないかを確認してください（v1.23.0アップグレード後は404になります）。Functionのメタデータ名（metadata.name）に機密性の高い情報やシステム構造を示す名称を使っていないかを見直してください。

FAQ

Q. Fissionのルーターがクラスター内部からしかアクセスできない場合も危険ですか？ A. はい。クラスター内部の別Podや侵害されたコンテナからも攻撃が可能です。マルチテナント環境ではテナント間の分離が崩壊します。クラスター外部露出がない場合でも深刻度は高いです。

Q. Fission以外のKubernetes FaaSフレームワーク（Knative・OpenFaaSなど）も同様の問題がありますか？ A. 今回の脆弱性はFission固有の実装上の問題です。ただし類似の「内部ルートと公開エンドポイントの混在」という設計パターンは他のフレームワークでも潜在的なリスクとして存在する場合があります。使用しているすべてのFaaSフレームワークの最新セキュリティアドバイザリを定期的に確認することを推奨します。

Q. v1.23.0へのアップグレードで既存の関数が動かなくなる可能性はありますか？ A. Ingress等を通じて/fission-function/<ns>/<name>パスを直接呼び出している設定がある場合に影響が出ます。また、KEDAのmessage-queue triggersを使用している場合は--set internalAuth.enabled=falseの追加指定が必要です。アップグレード前にFission公式のリリースノートのBreaking Changesセクションを確認してください。

Q. 侵害されたかどうかを確認する方法はありますか？ A. Fissionルーターのアクセスログで/fission-function/パスへの予期しないアクセスが記録されていないかを確認してください。Kubernetesの監査ログ（audit log）でFunctionの予期しない実行履歴がないかも調査することを推奨します。

参考情報（1次ソース）

• CVE-2026-46614: Fission router exposes /fission-function/… on its public listener（GitLab Advisory Database・2026年5月21日）
• Fission v1.23.0 リリースノート（Fission公式）
• GitHub Security Advisory GHSA-3g33-6vg6-27m8（GitHub）
• Fission Router, Authentication Bypass（DailyCVE・技術詳細）
• Fission Privilege Escalation CVE-2026-46617（DailyCVE）
• Fission Router Vulnerability Patched（SecurityOnline）
• 【関連記事（当サイト）】GitHubの5,561リポジトリが6時間で侵害——Megalodon攻撃をSafeDepが公開
• 【関連記事（当サイト）】2025〜2026年 サイバー攻撃・情報漏洩の最新事例まとめ