Splunk更新後もEdge Processorの再導入が必要｜配布認証を切り替える条件

Splunk Enterpriseを10月の修正版へ更新したチームでも、Edge Processorを使っている場合は配布経路の追加対応を確認してください。10月21日の勧告SVD-2026-1007には、認証されていない利用者がパッケージ配布APIへ要求を繰り返し、過剰な資源消費を引き起こすCVE-2026-76290が含まれます。修正版への更新に加え、既存インスタンスの準備、配布認証の有効化、再起動が案内されています。

重要なのは、認証を先にオンにしないことです。Splunkの公式手順「Edge Processorパッケージ配布の認証を有効にする」は、古い起動用コンポーネントが認証に対応できず、次回の自動再起動や更新時にデータ収集を止めるおそれを説明しています。本体を更新しただけでなく、既存Edge Processorをすべて再インストールしてから切り替える順序が必要です。

本稿は2026年10月25日に一次資料を確認した、未掲載の10月21日修正に関する記事です。公表日と確認日は異なり、25日に新たな攻撃が確認されたという意味ではありません。以下の優先順位や確認票は本サイトの提案です。攻撃実証や自社環境での動作試験を実施した結果ではなく、公開資料から実環境の悪用は確定できません。

既報の10月7日更新とは対象と完了条件が変わる

先行記事のSplunkの補助APIと10月7日更新の確認は、Patroni REST APIの問題と10.4.3・10.2.7などへの更新を扱いました。今回の勧告は別の修正集合です。以前の作業票に「対応済み」とあっても、その版のままで10月21日分まで完了したとは判断できません。

Splunk：SVD-2026-1007の集合勧告は、10.4.4、10.2.8、10.0.11、9.4.16以降への更新を案内しています。ただし、個別CVEごとに対象系列や機能が違います。今回中心に扱う76290の対象は10.4.4未満、10.2.8未満、10.0.11未満の該当系列で、9.4系をこのCVEの対象として追加しないでください。

読者との接点は、WebサイトやAPIのログを収集・変換し、不正アクセスを調べる監視基盤です。攻撃で監視基盤が使えなくなるリスクと、対策の順番を誤って正規の収集を止めるリスクを一緒に管理します。一般のSplunk利用者全員へ再インストールを求める話ではなく、顧客管理ホストでEdge Processorを動かしている運用者が主な対象です。

認証不要の配布APIが資源消費の入口になる

CVE-2026-76290は、Splunk Pipeline BuildersアプリのEdge Processorパッケージ配布エンドポイントが入口です。提供元は、認証なしの反復要求によってSplunk daemonが過剰な資源を消費し、応答しなくなる可能性を説明しています。CVSS v3.1は7.5、Highです。認証不要DoSと、同じ勧告にある別のコード実行問題を混同しないでください。

本サイトが勧める初動は、バージョンとPipeline Buildersの利用状況、配布先の全インスタンス、管理面へ到達できる接続元を対応付けることです。普段使う検索画面にログインが必要でも、すべての補助APIが同じ認証境界にあるとは限りません。公開URLだけでなく、VPN、保守ホスト、収集用ネットワークからの経路も運用設定で確認します。

更新できない場合の緩和策として、勧告はPipeline Buildersアプリの停止または削除を挙げています。ただしEdge Processor機能が利用できなくなります。ログ変換や転送のどこが依存しているかを調べずに実行すると、監視の材料を失う可能性があります。暫定措置には対象、担当、停止範囲、再開条件を残し、恒久更新の代わりに放置しません。

再起動や自動更新だけでは配布認証の準備が終わらない

公式手順の適用範囲は、Splunk Enterpriseから顧客管理ホストのEdge Processorへ配布する構成です。Splunk Cloudのパッケージ配布サービスを使う構成には、そのまま適用しません。認証機能は既定では無効で、通常の機能案内では任意とされています。一方、脆弱性勧告では更新後の有効化まで指示されています。機能が選択式であることを、今回の対策が不要という意味へ読み替えないことが大切です。

既存インスタンスを再導入する理由は、起動や必要ソフトウェアの取得を行うコンポーネント自身が自動更新できず、旧版では認証付き配布へ接続できないためです。Splunk Enterpriseの更新後に生成した新しいインストールコマンドを使い、完全なアンインストールと再インストールを行う必要があります。古いコマンドの再利用、単なる再起動、自動更新待ちでは準備完了になりません。

この点はセキュリティ上の完了条件を変えます。管理画面の本体版が新しくても、旧コンポーネントが残れば認証を安全に要求できません。台帳には論理的なEdge Processor名だけでなく、その下の各インスタンスとホストを列挙します。全件が再導入済みかを確認し、所在不明の一台を「たぶん自動更新済み」で閉じないようにします。

収集を残しながら全インスタンスを入れ替える

公式資料は、複数インスタンス構成なら残りの系で処理を続けながら段階的に再導入する方法を案内しています。単一系は一時的な追加系を用意するか、停止時間と送信元のバッファー・配送動作を計画します。これは単なる無停止化の工夫ではなく、対策中に攻撃検知用の記録が欠落する範囲を把握するための判断です。

本サイトの提案として、再導入前に送信先の切り替えと滞留状況を確認します。残りの系が正常という表示だけでなく、実際に想定する入力を受けられるかを見ます。保守対象へデータが流れ続けている状態で停止すると、メモリーやキューにあるデータを失う可能性があります。UDPなど配送保証のない経路は、送信元に残るはずだと仮定しません。

再導入先は、元と同じ論理的なEdge Processorです。公式手順は論理グループ自体を削除しないよう注意しています。管理画面からインスタンスを消しただけなのか、ホスト側のプロセスも止まったか、再導入後に正しいパイプラインと共有設定を受け取れたかを別々に確認します。機密値を含み得るコマンドは、公開チケットや一般チャットへ貼り付けません。

認証の有効化は全件確認後に行う

すべての既存インスタンスの再導入と確認が終わってから、パッケージ配布のAuthentication requiredを有効にし、Splunk Enterpriseを再起動します。公式資料には画面操作とrestmap.confを使う方法があります。構成管理を使う環境では、手動設定が次回配信で戻らないよう変更元にも反映します。

設定後は、認証要求が有効であること、Needs reinstallationの対象が残っていないこと、すべてのインスタンスがHealthyであること、各パイプラインでデータが流れることを確認します。本サイトでは、既存の正常な送信経路を使い、識別可能な無害の確認イベントを入力から検索結果まで追う方法を提案します。本番にDoSの実証要求を送って修正を確認する必要はありません。

もし旧系を残したまま切り替えた場合、認証設定だけを元へ戻すと収集は復旧する可能性がありますが、認証不要の配布状態も戻ります。復旧操作を対策完了と記録せず、公開・到達範囲の制限と残りの再導入を含めた暫定状態として管理してください。実行前に公式手順と保守担当へ照会し、停止と露出の両方を判断します。

同じ更新の予約検索とSecure Gatewayも確認する

今回の集合勧告には、予約検索のschedule_search能力を持つ利用者が危険なSPLコマンドへの保護を迂回できるCVE-2026-76291も含まれます。また、CVE-2026-76292と76295はSecure Gatewayの更新も必要です。各系列の修正版は3.10.12、3.9.26、3.8.73以降と案内されています。本体、関連アプリ、配布認証の三つを別の作業行にすると、更新通知だけで誤って完了にしにくくなります。

本サイトの提案は、アカウントの名前やadmin以外という区分だけで安全と判断せず、実際の能力、予約検索、アプリ権限を見直すことです。侵害調査が必要なら、予約検索の作成・変更、ロールの変更、管理APIへの要求を、保守作業の時刻と照合します。これらは調査の観点であり、今回その手口が実際に使われたという報告ではありません。

対応を閉じるための証拠をそろえる

今回の完了条件は、対象系列を修正済みにした記録だけではありません。全インスタンスの再導入、認証要求の状態、再起動、収集・変換・検索の確認、Secure Gatewayなど関連更新の要否がそろうことです。未対応の系には責任者と次の作業を付けます。一般的な適用手順は、緊急パッチの資産確認・検証・切り戻しランブックも参照してください。

Webサービスが動いていても、その監視が止まれば不正アクセスの発見や被害範囲の判断が遅れます。今回は監視基盤の防御を強める設定変更が、古い配布コンポーネントを残すと収集停止につながる点が要点です。修正版の配布と、認証付きの経路へ移行できたことを、別々に証明してから対応を閉じます。