Splunkに重大脆弱性、公開2日でRCEの実証コードが公開

CVSS 9.8（10点満点中）——極めて高いスコアが、企業のセキュリティ監視基盤そのものであるSplunk Enterpriseに付けられた。 CVE-2026-20253と名付けられたこの脆弱性は、Splunk内部でログデータの一部処理を担う「PostgreSQLサイドカーサービス」のエンドポイントに認証制御が一切存在しないという、驚くほど単純な欠陥に起因する。未認証の攻撃者がネットワーク経由でこのエンドポイントにアクセスするだけで、任意のファイルを作成・切り詰めできてしまう。米国土安全保障省傘下のCISA（サイバーセキュリティ・インフラセキュリティ庁）はこれを既知悪用脆弱性（KEV）カタログに追加し、連邦政府機関に対して2026年6月21日までという異例の短期間でのパッチ適用を義務付けた。さらに衝撃的なのは、脆弱性が公式に公開されてからわずか2日後に、セキュリティ研究者がこの欠陥を悪用してリモートコード実行（RCE）に至る実証コード（PoC）を公開したことだ。本記事では、CVE-2026-20253の技術的な仕組み、悪用に至る攻撃チェーン、そして日本企業が今すぐ取るべき対応を、Splunk公式アドバイザリを含む複数の一次情報を基に詳しく解説する。

上の図は、CVE-2026-20253が単なる「ファイル書き込みバグ」から本格的なリモートコード実行に至るまでの攻撃チェーンを示している。認証なしでアクセス可能なPostgreSQLサイドカーのファイル操作機能を起点に、パストラバーサルによる任意ファイル作成、保存済みDB認証情報（.pgpass）の窃取、そして悪意あるバックアップの復元によって、最終的にSplunkサーバー上で任意コードが実行される。この一連の流れがわかると、なぜ本脆弱性が「認証バイパス」を超えて「事実上の事前認証RCE」として扱われているのかが理解できる。

CVE-2026-20253——脆弱性の概要

基本情報

Splunkが公式に公開したセキュリティアドバイザリ「SVD-2026-0603」によれば、CVE-2026-20253の詳細は以下の通りだ。

項目	内容
CVE番号	CVE-2026-20253
CVSSスコア	9.8（Critical、ベクトル: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）
脆弱性の種類	Missing Authentication for Critical Function（重要機能の認証欠如）
影響を受けるバージョン	Splunk Enterprise 10.0.0〜10.0.6、10.2.0〜10.2.3
修正バージョン	10.0.7、10.2.4、10.4.0以降
公式アドバイザリ公開日	2026年6月10日
アドバイザリ最終更新日	2026年6月18日（限定的な悪用を確認したと追記）
CISA KEV登録日	2026年6月18日
連邦機関パッチ期限	2026年6月21日

CVSSベクトルを見ると、攻撃元区分（AV）は「ネットワーク」、攻撃条件の複雑さ（AC）は「低」、必要な権限（PR）は「なし」、ユーザー関与（UI）は「不要」となっている。つまり攻撃者は特別な足場もユーザーの操作も必要とせず、ネットワーク経由で対象のSplunkサーバーにアクセスできればそれだけで攻撃が成立する。この組み合わせが9.8という極めて高いスコアの根拠になっている。

なお、Splunk Cloud Platform（Splunk社がホストするマネージドサービス）は本脆弱性の対象外であり、影響を受けるのは自社運用（オンプレミス）のSplunk Enterpriseに限られる。この点は複数のセキュリティベンダーのレポートで一致しており、自社でSplunkサーバーを構築・運用している組織のみが対応を求められる。

Splunkとは何か、なぜこの脆弱性が危険なのか

Splunkの役割

Splunkは、サーバー・ネットワーク機器・アプリケーションなどから出力される大量のログデータを収集・検索・可視化・分析するためのプラットフォームで、SIEM（Security Information and Event Management、セキュリティ情報イベント管理）製品の代表格として世界中の大企業・官公庁で使われている。セキュリティ運用センター（SOC）のアナリストは、Splunkのダッシュボード上で不審なログイン試行、マルウェアの通信パターン、内部不正の兆候などを日々監視している。つまりSplunkは「侵入者を見つけるための監視カメラ」の役割を担っており、企業のセキュリティ体制の中核に位置する製品だ。

PostgreSQLサイドカーサービスとは

Splunk Enterpriseは近年、一部のデータパイプライン機能や設定管理のバックエンドとして、軽量なPostgreSQLデータベースを「サイドカー」（メインプロセスに付随する補助プロセス）として内部で動作させる構成を導入している。このサイドカーはローカルホスト上のポート（前述のPicus Securityの分析ではlocalhost:5435と報告されている）で待ち受け、Splunk本体のWebインターフェースやバックエンド処理からリクエストを中継して利用する設計になっている。

問題は、このサイドカーサービスのエンドポイントが「アプリケーションレベルの認証」を実装していなかった点にある。本来であればSplunk本体を通じて認証済みのリクエストのみが到達するはずの箇所だが、実際にはネットワーク到達可能な誰もが、資格情報なしにファイル操作系のAPIを呼び出せる状態になっていた。ローカルホスト限定のサービスだから安全、という設計上の前提が、Splunk本体のWebインターフェース経由でのリレー可能性によって崩れてしまったことが、本脆弱性の核心だ。

なぜ「ファイル作成・切り詰め」がRCEに直結するのか

Splunk公式の説明は当初「認証なしでの任意ファイル作成・切り詰めが可能」という比較的地味な表現にとどまっていた。しかし、この一見地味な脆弱性が危険な理由は、Splunkというソフトウェアの構造そのものにある。ファイル作成・書き換えの自由度が高ければ、設定ファイルの改ざん、スケジュール実行スクリプトの差し替え、認証情報ファイルの窃取といった二次攻撃の足がかりに転用できるからだ。

Picus Securityの技術分析によれば、実際の攻撃チェーンは次のような段階を踏む。

1. Splunk Webインターフェースを経由して、ローカルの PostgreSQL サイドカーサービスへリクエストをリレーする
2. 空の認証情報（Basic認証ヘッダーの中身が空）でもサービス側がリクエストを受理してしまう
3. バックアップファイルパスのパラメータを操作するパストラバーサル手法で、任意の場所にファイルを作成する
4. PostgreSQL接続文字列を悪用し、リモートからデータベースの内容をダンプする
5. データベース内に保存されている認証情報ファイル（.pgpass）を利用し、特権を持ったデータベースアカウントとして認証する
6. マルウェアを仕込んだバックアップファイルを復元させることで、任意の内容のファイルをサーバー上に書き込む
7. Splunkが定期実行するスケジュールタスクのスクリプト（ssg_enable_modular_input.pyなど）を悪意あるコードに置き換え、次回実行時にリモートコード実行を達成する

この7段階の連鎖を見れば、「認証バイパスによる任意ファイル作成」という一見地味な脆弱性区分と、実態としての「事前認証リモートコード実行」との間にあるギャップの大きさがわかる。攻撃者にとって、Splunkサーバーの制御を奪うことは、SOCの監視の目そのものを潰す、あるいは監視ログを改ざんして侵入の痕跡を消すことにも直結する。これは単なる情報漏えいではなく、「侵入検知システム自体を無力化される」という、セキュリティ運用の根幹を揺るがすシナリオだ。

上のタイムライン図が示す通り、公式発表からPoC公開までわずか2日、KEV登録から連邦機関のパッチ期限までも3日というスピード感で事態が進行した。この異様な速さこそが、本脆弱性を単なる「よくあるCVE」ではなく、業界全体で警戒すべき事案に押し上げている理由だ。

悪用の経緯とCISAの対応

Splunkは2026年6月10日に公式アドバイザリ「SVD-2026-0603」を公開し、CVE-2026-20253の詳細と修正バージョン（10.0.7、10.2.4、10.4.0以降）を発表した。この時点では、脆弱性は「発見・修正済み」という通常のプロセスの範疇にあった。

ところが状況は急速に悪化する。SecurityWeekおよびCrowdSecの報告によれば、公開からわずか2日後の6月12日、セキュリティ研究チームがこの脆弱性を悪用してリモートコード実行に至るPoCを公開した。攻撃チェーンの詳細が公になったことで、悪用のハードルは一気に下がった。

その後、6月17日から18日にかけて、Splunk PSIRT（プロダクトセキュリティインシデント対応チーム）が実際の限定的な悪用を確認したと発表し、アドバイザリを更新した。これを受けてCISAは6月18日、CVE-2026-20253をKEVカタログに追加。連邦政府の拘束力ある指令「Binding Operational Directive（BOD）26-04」に基づき、連邦政府機関に対して2026年6月21日までのパッチ適用または緩和策の実施を義務付けた。BleepingComputerの報道では、この期限は公開からわずか3日というタイトなスケジュールだったと伝えられている。

CISAのKEVカタログは「実際に悪用が確認された脆弱性」のみを掲載するリストであり、理論上のリスクだけでは登録されない。Splunk製品がKEVに登録されるのは今回が初めてであり、SIEM製品という「防御側の要」がリストに載ったこと自体が、業界に強いメッセージを送っている。

類似のログ管理・SIEM製品脆弱性との比較

SIEM・ログ管理製品の脆弱性は近年たびたび報告されているが、その多くは認証後の権限昇格や特定条件下でのインジェクション攻撃にとどまり、CVE-2026-20253ほど「未認証・低複雑度・重大な影響」の三拍子が揃うケースは稀だ。以下は主要なログ管理・SIEM関連製品で報告された重大脆弱性との比較である。

脆弱性	製品	CVSS	認証要否	影響	KEV登録
CVE-2026-20253	Splunk Enterprise	9.8	不要	任意ファイル作成→RCE	あり（初）
CVE-2026-48558	SimpleHelp RMM	10.0	不要（OIDC設定時）	MFAバイパス・セッション乗っ取り	あり
CVE-2024-3400	Palo Alto PAN-OS（GlobalProtect）	10.0	不要	コマンドインジェクション・RCE	あり
CVE-2023-46747	F5 BIG-IP（Configuration Utility）	9.8	不要	認証バイパス・RCE	あり
CVE-2022-47966	ManageEngine各種製品	9.8	不要	SAML関連のRCE	あり

この比較から見えてくるのは、「未認証」「ネットワーク経由」「重大な影響」という三条件が揃った脆弱性は、製品カテゴリを問わずCVSS 9.8〜10.0という最高ランクに位置づけられ、ほぼ例外なくCISAのKEV登録・悪用対象になっているという傾向だ。企業のセキュリティ運用や監視の中核を担う製品（SIEM、RMM、ネットワーク機器の管理コンソール）は、攻撃者にとって「一度奪えば広範囲に影響を及ぼせる」高価値の標的であり、今後もこの種の脆弱性が繰り返し発見されることが予想される。

筆者の所感——「公開後わずか2日」が意味する脅威の変化

筆者が本件で最も注目すべきだと考えるのは、CVSSスコアの高さそのものよりも、「脆弱性の公式発表からRCE実証コードの公開までがわずか2日だった」という事実だ。かつては脆弱性が公開されてから実際に武器化されるまで、数週間から数ヶ月の猶予があるのが一般的だった。防御側はその間にパッチ適用計画を立て、リスク評価を行い、段階的に展開する時間的余裕があった。

しかし近年、セキュリティ研究者コミュニティの「攻撃的研究（オフェンシブ・リサーチ）」の実力は著しく向上している。公式アドバイザリに書かれた「認証なしで任意ファイルの作成・切り詰めが可能」という一文だけから、経験豊富な研究者は「バックアップ機構」「スケジュール実行タスク」「保存済み認証情報」といった典型的な設計パターンを踏まえ、わずか数日で実用的なRCEチェーンを組み立てられる。今回のケースでも、Picus Securityが公開した7段階の攻撃チェーンは、いずれもソフトウェアアーキテクチャの一般的な知識から導出可能な内容であり、特別な内部情報を必要としない。

これはつまり、「脆弱性の詳細（技術的なCVE説明文）が公開された時点で、実質的にゼロデイと同等の緊急度で対応しなければならない」という時代に入ったことを意味する。防御側にとっての教訓は明確だ。パッチ管理のプロセスにおいて「CVSSスコアが高い脆弱性は、詳細公開から48時間以内に緩和策を講じられる体制」を平時から整備しておく必要がある。月次のパッチ適用サイクルを待っていては、今回のような事案では手遅れになりかねない。また、攻撃者側のPoC公開スピードが上がっている以上、防御側もCISAのKEVカタログや主要ベンダーのアドバイザリを常時モニタリングし、自動アラートを設定するといった仕組み化が不可欠だ。

日本ではどうなるか

日本企業のSplunk導入状況

Splunkは日本国内でも、金融機関、通信キャリア、製造業の大企業、官公庁関連組織などで広く導入されているSIEM製品の一つだ。特にセキュリティ監視のアウトソーシング先であるMSSP（マネージドセキュリティサービスプロバイダー）や、社内SOCを構築している大企業において、ログの集約・相関分析基盤として利用されるケースが多い。オンプレミス版のSplunk Enterpriseを自社データセンターやプライベートクラウド上で運用している企業は、今回のCVE-2026-20253の直接的な対象となる。

一方で、Splunk Cloud Platform（Splunk社がマネージドで提供するクラウド版）を利用している企業は本脆弱性の対象外であり、Splunk社側の責任でパッチが適用される。まずは自社がどちらの形態でSplunkを利用しているかを確認することが第一歩となる。

日本企業が取るべき確認・対応手順

1. バージョン確認: 自社のSplunk Enterpriseのバージョンが10.0.0〜10.0.6、または10.2.0〜10.2.3の範囲に該当するか、管理コンソールまたはsplunk versionコマンドで確認する
2. 緊急パッチ適用: 該当する場合は10.0.7、10.2.4、10.4.0以降のいずれかへ速やかにアップグレードする。ダウンタイムの調整が必要な場合は、変更管理プロセスを短縮してでも優先度を最上位に設定すべきだ
3. 侵害有無の調査: パッチ適用前にすでにアクセス可能な状態だった期間について、アクセスログ、PostgreSQLサイドカーへの不審な接続、.pgpassファイルへのアクセス履歴、想定外のバックアップファイルの有無を確認する
4. 暫定緩和策の検討: 即座のパッチ適用が難しい場合は、PostgreSQLサイドカーサービスの無効化や、該当ポートへのネットワークアクセス制限（ファイアウォールルールの追加）を暫定措置として検討する。ただしサイドカー無効化はデータパイプライン機能に影響が出る可能性があるため、事前に業務影響を確認する
5. JPCERT/CCへの報告: 侵害の兆候が確認された場合は、JPCERTコーディネーションセンター（JPCERT/CC）のインシデント報告窓口（Webフォームまたはメール）から速やかに報告する。特に自社のSplunk環境が他社・グループ会社のログも収集している場合、被害が広範囲に及ぶ可能性があるため早期の情報共有が重要となる
6. 委託先・MSSPへの確認: セキュリティ監視を外部委託している場合は、委託先のSplunk運用状況とパッチ適用状況を照会し、契約上のSLA（サービスレベル合意）に基づく緊急対応を要請する

日本ではセキュリティ人材不足や、本番環境への変更に対する社内稟議の慣習から、パッチ適用までのリードタイムが海外企業より長くなりがちだ。しかし今回のように「公開後2日でPoCが出回る」事案では、通常の稟議プロセスを待っていては手遅れになる可能性が高い。あらかじめ「CVSS 9.0以上かつKEV登録」という条件を満たす脆弱性については、緊急変更として即日〜数日以内に適用できる例外プロセスを整備しておくことが望ましい。

筆者の見解・予測——SIEM製品への攻撃は今後どう展開するか

今回のSplunk事案は、単発の出来事として片付けるべきではない。SIEM・ログ管理製品そのものが攻撃者にとって「監視の目を潰す」「侵入の証拠を消す」という二重の価値を持つ標的である以上、今後も同種の攻撃は増加していくと筆者は予測する。特に以下の3点が今後の焦点になるだろう。

1. サイドカー構成・補助プロセスの認証境界が狙われる: 近年のエンタープライズソフトウェアは、メインアプリケーションに加えてデータベースやキャッシュ層を「サイドカー」として同居させる構成が一般化している。今回のケースのように「ローカルホスト限定だから安全」という前提が、メインアプリケーション経由のリレーによって崩れる設計上の死角は、他の製品でも同様に存在する可能性が高い。ベンダー各社は自社製品のサイドカー・補助プロセスの認証境界を今一度棚卸しすべきだ。

2. PoC公開の高速化がパッチ管理の常識を変える: 前述の通り、詳細公開から実証コード公開までのリードタイムは年々短縮している。セキュリティ担当者は「パッチが出たら1〜2週間以内に適用する」という従来の感覚を改め、「重大脆弱性は公開から48時間が勝負」という前提でプロセスを再設計する必要がある。

3. SIEM自体の完全性を守る多層防御が重要になる: SIEMがもし侵害された場合、そのSIEMが出力するログやアラートそのものが信頼できなくなる。今後は「SIEMを監視する仕組み」、すなわちSIEMサーバー自体の整合性監視（ファイル改ざん検知、異常なプロセス起動の検知）や、SIEMとは独立した経路でのバックアップ・監査ログの保全が、成熟したセキュリティ体制の必須要件になっていくだろう。

セキュリティ担当者へのアドバイスとしては、今回のような「防御ツール自体の脆弱性」に対しては、通常のアプリケーション脆弱性以上に迅速な対応が求められる。自社の脅威インテリジェンス収集の対象に、利用している主要セキュリティ製品ベンダー（Splunk、CrowdStrike、Palo Alto Networks等）のアドバイザリを含め、KEVカタログの更新を日次で確認する運用を組み込むことを強く推奨する。

上のフローチャートは、日本企業がとるべき対応の全体像を整理したものだ。まず自社のバージョンを確認し、対象範囲に該当する場合は緊急パッチ適用と侵害調査を並行して進め、侵害の兆候があればJPCERT/CCへの報告につなげる、という流れを踏まえておけば、いざという時に迷わず動ける。

まとめ

CVE-2026-20253は、CVSS 9.8という極めて高い深刻度に加え、公開後わずか2日でRCEに至る実証コードが公開されたという異例のスピード感を伴う脆弱性だ。Splunk EnterpriseのPostgreSQLサイドカーサービスにおける認証制御の欠如という一見地味な欠陥が、パストラバーサル、DB資格情報の窃取、悪意あるバックアップの復元を経て、最終的にはリモートコード実行という深刻な結果に至る。CISAはこれをKEVカタログに追加し、連邦機関に6月21日までのパッチ適用を義務付けた。

自社でSplunk Enterpriseを運用している組織は、以下のアクションを直ちに実行してほしい。

1. バージョン確認: 自社のSplunk Enterpriseが10.0.0〜10.0.6または10.2.0〜10.2.3に該当するか確認する
2. パッチ適用: 該当する場合は10.0.7、10.2.4、10.4.0以降へ最優先でアップグレードする
3. 侵害調査とJPCERT/CC報告: パッチ適用前のアクセスログ・不審なファイル作成の痕跡を調査し、侵害が確認された場合はJPCERT/CCへ速やかに報告する

「監視する側」であるSIEM製品が攻撃対象になるという事実は、セキュリティ運用の前提そのものを問い直す契機になる。今回の事案を機に、自社のパッチ管理プロセスと、セキュリティ製品自体の完全性監視体制を見直すことを強く推奨する。