ログ分析基盤として国内でも広く使われているSplunkが、2026年8月19日付で複数のセキュリティアドバイザリを公開し、多数の脆弱性を修正した。中核製品であるSplunk Enterpriseだけで60件のCVEが並び、最も深刻なものは、脆弱性の深刻度を数値化する共通指標であるCVSSv3.1の基本値で9.4、「緊急（Critical）」に区分される。JPCERT/CCもWeekly Report 2026-08-26号で「複数のSplunk製品に脆弱性」として取り上げており、社内でSplunkを運用している組織はバージョンの確認を急ぎたい。
Splunk Enterpriseで3件のCritical、修正版は4系統
Splunkが公開したアドバイザリ「SVD-2026-0801」は、Splunk Enterprise の複数の脆弱性をまとめたものだ。最高スコアは9.4で、該当するのは埋め込みレポート（Embedded Report）に関するアクセス制御不備3件（CVE-2026-76310、CVE-2026-76311、CVE-2026-76312）である。いずれもCWE-284（不適切なアクセス制御）に分類されている。
続くHigh評価の脆弱性には、REST API経由のリモートコード実行（CVE-2026-76313）、Splunk Web の管理画面設定を通じたコード実行・コードインジェクション（CVE-2026-76314、CVE-2026-76315、CVE-2026-76335）、デプロイメントサーバのブローカー登録を経由したSPLインジェクション（CVE-2026-76316）、Lookup 設定のREST APIにおけるパストラバーサル（CVE-2026-76317）、フェデレーテッドサーチを介したリモートコード実行（CVE-2026-76319）などが並ぶ。スコアはいずれも8.8で、権限を持つユーザーの操作が起点となるものが中心だが、侵入後の権限昇格や横展開に直結しうる内容である。
修正版はSplunk Enterprise 10.4.2、10.2.6、10.0.9、9.4.14。それぞれ10.4系、10.2系、10.0系、9.4系に対応する。なお、CVE-2026-76338とCVE-2026-76352の2件については、バージョンを上げるだけでは不十分で追加の対処が必要だとSplunkは案内している。該当環境では、アドバイザリの記載を確認したうえで作業計画を立てる必要がある。
アプリ／アドオン側にもCVSS 9.1、AI関連コンポーネントが対象に
同じ8月19日には、Splunkのアプリとアドオンを対象としたアドバイザリ「SVD-2026-0808」も公開された。最高スコアは9.1で、対象はSplunk MCP Server app における信頼できないデータのデシリアライズを介したリモートコード実行（CVE-2026-76404）である。修正版は1.2.1。
このアドバイザリでは他に、Cisco Talos Intelligence for Enterprise Security Cloud のREST APIにおけるSSRF（サーバーサイドリクエストフォージェリ。CVE-2026-76389、スコア8.8）、Splunk AI Toolkit のモデル読み込みREST APIにおけるデシリアライズ起因のリモートコード実行（CVE-2026-76395、同8.8）、同ツールキットの認可不備（CVE-2026-76391、CVE-2026-76394、いずれも8.3）、Splunk Connect for Kafka のSSRFなどが修正されている。修正版はSplunk AI Toolkit 6.0.1（5.7系は6.0.0）、Splunk Connect for Kafka 2.2.7、Cisco Talos Intelligence for Enterprise Security Cloud 1.0.3などとされている。
AIツールキットやMCPサーバー向けアプリといった比較的新しいコンポーネントが顔を出している点は、この夏のアドバイザリの特徴といえる。生成AI連携のためにこうしたアプリを追加した環境では、本体だけを見ていると更新漏れが起きやすい。
さらに、ログを横断的に集約・分析して脅威を検知するSIEM製品であるSplunk Enterprise Security についてもアドバイザリ「SVD-2026-0807」が出ている。REST API経由のSPLインジェクション（CVE-2026-76387）と、サーチマクロの権限設定を介した権限昇格（CVE-2026-76388）の2件で、いずれもスコアは8.1。修正版は8.6.1以上となる。加えて別アドバイザリ「SVD-2026-0802」では、Splunk Enterpriseに同梱されるサードパーティパッケージについて33件のCVEが解消されている。
セキュリティ基盤そのものが狙われる前提で
Splunkは、セキュリティ監視やインシデント調査の土台として使われることが多い製品だ。裏を返せば、この基盤に侵入されれば、攻撃者は組織のログを覗き、必要なら消すこともできる立場に立つ。検知の網そのものを無力化されるという意味で、通常の業務システムの脆弱性とは重みが異なる。
とりわけ今回のように、リモートコード実行やSPLインジェクション、権限昇格が並ぶ修正は、内部に足がかりを得た攻撃者にとって価値が高い。多くは認証済みユーザーを起点とするが、フィッシングなどで一般ユーザーの認証情報が奪われている前提に立てば、「認証が必要だから安全」とは言い切れない。
本稿執筆時点で、これらの脆弱性が実際に悪用されたという報告は確認できていない。ただし管理系の製品は、修正が公開されてから攻撃側が追随するまでの間隔が短い傾向にある。まずは自組織のバージョンを棚卸しし、本体・アプリ・アドオンを含めて修正版の適用計画を立てること。すぐに更新できない環境では、管理ポートやSplunk Web への到達経路を絞り、管理者権限を持つアカウントの棚卸しと多要素認証の適用状況を確認しておきたい。あわせて、Splunk自身へのログイン試行や設定変更を監視対象に含めているかを見直す価値がある。
同じ手口に、自社は備えられていますか？