KibanaのFleetでデータ流路を横取りする脆弱性に対応するには？

Elasticは2026年10月6日、KibanaのFleetに関するCVE-2026-102406の修正情報ESA-2026-187を公開しました。委譲されたパッケージ管理権限から、同じKibana環境にある別の利用者・チームのデータ流路へ影響する問題です。CVSS v3.1は8.8、Highです。

確認日は10月18日です。当日発生した侵害事件の報道ではありません。公式告知は影響条件と修正・点検方法を示していますが、今回参照した本文から実環境での悪用は確認できません。重要なのは、更新したことと、すでに変更されたかもしれない流路を確かめることを別に扱う点です。

出典：Elastic：Kibana ESA-2026-187 セキュリティ更新。

ここでいうテナントは別のクラウド顧客ではない

公式は今回の「tenant」を、同じKibanaの導入環境を共有する利用者やチームと説明しています。異なるElastic Cloud組織や顧客の間を越える問題だと読み替えないでください。自社内で部署や顧客のログを同居させている場合も、環境内の境界を点検する理由になります。

成立条件には、Fleetが有効で、完全なsuperuserではない利用者へ、カスタムの統合パッケージをインストールする権限が与えられていることが含まれます。一般閲覧者の全員が同じ操作をできるわけではありません。管理を一部委譲した権限の扱いが焦点です。

本サイトでは、「管理者以外」という大きな分類で済ませず、誰がパッケージを登録できるかを実際のロールで調べる方法を勧めます。職務名、チーム名、画面のメニュー表示だけでなく、有効な権限を根拠として確認します。

所有者を確認しない識別子が流路の変更につながる

告知によると、アップロードされたパッケージが、別の利用者の既存データストリームで使われる識別子を指定できました。所有関係を確かめないまま、生成された索引や取り込みパイプラインの設定が既存基盤へ適用されることが問題です。

その結果、後から取り込まれるデータが、攻撃者の管理する基盤を経由するよう変更され、漏えいや改変、本来の宛先へ届かない状態につながる可能性があります。一般論として、IDが一致することと、そのIDの所有物を変更してよいことは違います。強い管理権限を持つ処理の入口で、その確認を行う必要があります。

ただし、今回の記述から過去のすべてのデータが窃取されたとは言えません。告知が説明する新規取り込みデータへの影響と、環境で実際に起きたことを分けます。自社の調査では、流路が変わった期間と、その間に入ったデータを対応付けることが重要になります。

対象版と修正版を使っている系列で確認する

対象範囲は8.14.0から8.19.21、9.0.0から9.4.6、9.5.0から9.5.3です。修正版は8.19.22、9.4.7、9.5.4で、それ以降にも修正が含まれます。公式は移行先の既知の問題も確認するよう案内しています。

Self-managedとElastic Cloud Hostedの両方が対象条件に含まれます。一方、Elastic Cloud Serverlessは、公表前に修正済みと説明されています。単に「クラウドだから不要」「自社運用だから対象」と二分せず、提供形態と機能と版を組み合わせて判定してください。

本サイトの提案は、環境名、提供形態、版、Fleetの利用、パッケージ登録者、変更担当を一枚の対応票へまとめることです。使っていないと判断した機能も、以前有効だった期間や権限付与の履歴を確認できると、後の調査で役立ちます。

更新できない間はカスタムパッケージの権限を絞る

公式は、更新までの間、他チームのデータを管理するほど信頼していない利用者からカスタム統合パッケージのインストール権限を外し、完全なsuperuserだけに限定する方法を案内しています。Cloud Hostedでもロール管理から同様の制限が可能とされています。

この措置は、登録したパッケージの機能がすべて止まることと同義ではありません。既存の業務で誰が新規登録や更新を行っているかを調べ、正規の作業が必要な場合の窓口を用意します。共有の管理者アカウントを配って代替するのは、別の過大権限を作る方法です。

権限の一時制限には実施時刻と解除条件を残します。修正版を適用したからといって、元の委譲範囲を無条件に戻すのではなく、必要な担当者と操作だけを再承認します。今回の問題はソフトウェアで直しても、不要な管理権限は減らせます。

パッケージの削除だけでは流路が戻らないことがある

公式告知は、悪意あるパッケージを削除しても傍受が続く場合があり、影響を受けた基盤の別途の修復が必要だと説明しています。これが今回の対応で特に見落としたくない点です。「怪しいパッケージはもうない」だけを完了条件にしないでください。

本サイトの運用案は、ソフトウェアの修正、登録物の調査、既存流路の復旧、データの影響確認を別の項目にすることです。どれが完了しているかを分ければ、更新だけ済んだ状態を全体対応済みと誤解しにくくなります。

流路の復旧では、現在の設定をただ削除する前に、正しい宛先と変換処理を確認します。誤って必要なパイプラインを消せば、監視の欠落やデータ形式の不整合を招く可能性があります。構成管理や既知の正常な設定と比較し、担当者が変更を判断してください。

調査は登録履歴と既存パイプラインをつなげる

公式の点検案は、レジストリ以外からアップロードされたFleetパッケージの履歴と、予期しないパッケージ登録に伴う既存データストリームのパイプライン変更を確認するものです。自分が作成していない既存のデータストリームと同じdatasetを宣言する登録物にも注意を求めています。

実務では、登録時刻、実行者、対象dataset、変更された設定、承認された作業を対応付けることを提案します。共通のdataset名があるだけで侵害と断定するのではなく、誰がどの範囲を管理する設計だったかと照合します。通常の保守や移行の記録も必要です。

不審な変更が見つかったら、設定と履歴を保全して対応担当へ連絡します。データを無制限に書き出すより、まず対象期間と扱う情報を定めます。顧客別のログや個人情報が含まれる場合には、その調査結果自体のアクセス権も管理してください。

二つのチームを同居させる場合の復旧確認例

説明用に、制作チームと受注システムのチームが一つのKibanaを共有する構成を考えます。制作側へカスタムパッケージの管理を委譲している場合、その権限の目的が自分たちのデータに限られるのかを明確にします。同じ導入環境だから双方の設定を自由に変えてよいという設計にはしません。

復旧の確認では、両チームの代表データについて、正しい保存先、利用するパイプライン、閲覧できる担当を対応付けます。一方のチームだけでテストが成功しても、もう一方の新規データが誤った経路へ流れていないかは別に確認します。データの内容を他チームへ公開せずに確認できる、無害なテスト用識別子を用意します。

変更された期間が疑われる場合には、その期間のデータを単純にコピーし直す前に、重複、欠落、誤った変換の有無を調べます。正しい宛先へ再送できるかは収集元の保持と業務条件に依存します。再送しても、誤った宛先へ渡った可能性が消えるわけではないことも、調査と復旧を分ける理由です。

判断の記録には、変更を直した担当と、その結果を確認したデータ所有者を残します。これにより、基盤の設定だけ直した状態と、各チームが必要なデータを正常に受け取る状態を区別できます。パッケージのインストール権限を継続するなら、その委譲範囲を定期的に見直す運用へつなげます。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
提供形態	Self-managed・Hosted・Serverless	公式の対応範囲へ正しく対応付け
委譲権限	カスタム統合を登録できる利用者	他者のデータ管理との境界を確認
登録履歴	実行者・dataset・承認記録	予期しない既存流路への変更を調査
既存設定	索引・パイプライン・正しい宛先	パッケージ削除だけで復旧としない
データ確認	対象期間と各所有者の検証	新しいデータの到達と権限を確認

正常に見えるダッシュボードだけでは検証できない

更新・復旧後の確認は、表示だけでなく取り込み元から保存先まで追います。説明用の試験では、識別可能なテスト記録を対象の流路へ送り、想定したパイプラインと保存先で確認します。別チームの領域へ入っていないことも、許可された範囲で検証します。

重要なのは、過去の記録が表示されることと、新しい記録が正しい場所へ届くことを分けることです。通知や集計が別の派生データを使う場合もあります。データの到着、変換、可視化、通知のどこを確認したかを残します。

今回の教訓は、パッケージ登録を単なる画面の設定として扱わないことです。共有の基盤へ設定を適用する権限は、他者のデータ流路へ届き得ます。修正済み版を使い、所有関係と変更履歴を管理し、残存する設定まで確認することが対応の要点です。