「ログを集めて監視しているSplunkが、まさか侵入の入り口になるなんて」。そう感じた方こそ、今回の話は急いで読んでほしい内容です。守りの中心であるはずのログ監視基盤そのものに、認証なしで遠隔からコードを実行できる深刻な欠陥が見つかり、しかもすでに悪用が確認されているからです。
2026年6月18日、米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）が、Splunk Enterpriseの脆弱性「CVE-2026-20253」をKEV（Known Exploited Vulnerabilities＝悪用が確認された脆弱性のカタログ）に追加しました。Splunk製品としては初のKEV入りです。CVSS（脆弱性の深刻度スコア）は最大級の9.8。Splunk Enterprise 10で導入された「PostgreSQLサイドカー」という補助コンポーネントが、認証を素通りさせてしまい、未認証のままリモートでコード実行（RCE）に至る、というのが事案の核心です。
この記事では、CVE-2026-20253で何が起きているのかを一次情報から整理し、攻撃者がどうやって「空の認証情報」を突いてRCEまで到達するのかを攻撃者視点で分解します。そのうえで、SOC（セキュリティ監視を担うチームや組織）・情シスが今すぐ実施すべき該当バージョンの確認、IoC（Indicator of Compromise＝侵害の痕跡）の検知、そして緩和策を、現場で使えるレベルで整理します。攻撃の流れを取り上げるのは、あくまで防御のためです。敵がどの順で攻めてくるかを知らなければ、検知すべきポイントも見えてきません。落ち着いて、優先順位をつけて対応していきましょう。
CVE-2026-20253とは何が起きている脆弱性なのか
まず事実関係を一次情報ベースで整理します。CVE-2026-20253は、Splunk Enterpriseに同梱される「PostgreSQLサイドカーサービス」に存在する、認証の欠落（CWE-306: Missing Authentication for Critical Function）に起因する脆弱性です。PostgreSQLサイドカーは、Splunk Enterprise 10で導入されたバックアップ・リカバリ用の補助コンポーネントで、本来は内部的に使われるものです。
問題は、このコンポーネントが公開するHTTPエンドポイントの作りにあります。報告によれば、エンドポイントはBasic認証（IDとパスワードをヘッダで送る基本的な認証方式）のヘッダを要求する見た目になっていながら、実際には「空の認証情報」を受け入れてしまうとされています。つまり、正規の鍵を持っていなくても、空っぽの鍵を差し出せば扉が開いてしまう状態です。攻撃者はこの隙を突いて、未認証のまま機微なファイル操作を呼び出せます。
深刻度を示すCVSS v3.1スコアは9.8（Critical）。これは「ネットワーク越しに、特別な権限も利用者の操作も必要とせず、機密性・完全性・可用性のすべてに重大な影響を与えうる」ことを意味する、最高レベルに近い評価です。影響を受けるのはSplunk Enterprise 10.2.0～10.2.3、および10.0.0～10.0.6。修正は10.2.4、10.0.7、そして10.4.0以降で提供されています。
この事案を理解するうえで、時系列も押さえておく価値があります。報告によれば、アドバイザリ（注意喚起）が公開されたのが2026年6月10日、技術的な詳細や実証コード（PoC）が出回り始めたのが6月12日、そして実際の悪用が確認され、CISAがKEVへ追加したのが6月18日です。パッチ公開からおよそ8日で悪用が現実化した計算になります。「アドバイザリが出てから対応を検討しよう」と構えていると、攻撃者の動きに追い越されてしまう速さだと分かります。
なぜログ監視基盤の脆弱性が、ここまで重く扱われるのか。Splunkのようなログ基盤には、組織中のサーバーや機器のログが集まっています。ここを攻撃者に握られると、機微な情報が一望できてしまうだけでなく、自分の侵入の痕跡を消したり、監視のアラートを無効化したりすることまで可能になります。守りの司令塔が乗っ取られると、他のすべての守りが効きにくくなる――この連鎖こそが、ログ基盤の脆弱性を「最優先で塞ぐべきもの」にしている理由です。
攻撃者は「空の認証情報」からどうRCEに到達するのか
では、攻撃者がどの順で攻めてくるのか。防御側が検知ポイントを設計するための材料として、攻撃者の視点で流れを分解します。具体的な攻撃コードには踏み込まず、概念レベルで「どこを通って」コード実行に至るのかを押さえます。
1. 空の認証情報で未認証アクセスを成立させる
入り口は、PostgreSQLサイドカーのバックアップ・リカバリ系エンドポイントです。報告では、`/v1/postgres/recovery/backup` や `/v1/postgres/recovery/restore` といったエンドポイントが、認証を要求するように見えながら空の認証情報を通してしまうとされています。攻撃者から見れば、ここが「鍵のかかっていない裏口」です。インターネットや社内ネットワークから到達できる状態であれば、認証情報を一切持たずに、本来は内部専用であるはずの機能を呼び出せてしまいます。
2. ファイル操作とパストラバーサルで足場を作る
未認証で機能を呼び出せるようになると、攻撃者は次にファイルの作成や切り詰め（中身を空にする操作）を試みます。ここで使われるのがパストラバーサル（path traversal＝ファイルパスを遡って想定外の場所を指す手口）です。本来アクセスできないはずの場所にファイルを書き込んだり、既存ファイルを書き換えたりすることで、後続の攻撃に必要な足場を作っていきます。守りの観点では、「想定外のパスへのファイル書き込み」がここで発生する点を覚えておいてください。
3. 接続文字列の悪用とpg_dumpで任意コード実行へ
最終段階では、データベースの接続文字列（接続先や認証情報を指定する設定値）への注入と、PostgreSQL付属のバックアップツール`pg_dump`の悪用を連鎖させます。これらを組み合わせることで、攻撃者はsplunkユーザーの権限で任意のコマンドを実行できる――つまり完全なリモートコード実行（RCE）に到達します。ここまで来ると、ログ監視基盤そのものが攻撃者の拠点に変わってしまいます。皮肉なことに、組織のあらゆるログが集まる場所が乗っ取られると、攻撃者は自分の痕跡を消すことすら容易になります。
重要なのは、この一連の流れが「正規利用者を装ったログイン」ではなく、「そもそも認証を要求されない裏口」を通る点です。だからこそ、失敗ログインの急増といった分かりやすい兆候が出にくく、検知の設計にひと工夫が要ります。
PR
初心者のための実践セキュリティ 自宅ラボでの攻撃検知と防御（技術の泉シリーズ）
IDSやSIEMを使った監視の組み立て方を、手元の検証環境で学べる一冊です。「未認証アクセスをログからどう拾うか」という、まさに今回必要になる検知の感覚を養いたい方に向いています。
SOC・情シスがいま実施すべき緊急対応
KEVに登録されたということは、「すでに悪用が確認されている」という意味です。後回しにできる段階ではありません。専任担当がいなくても着手できる順に整理します。
1. 該当バージョンの確認とアップグレード
最優先は、自社のSplunk Enterpriseが影響範囲に入っているかの確認です。10.2.0～10.2.3、または10.0.0～10.0.6を使っているなら該当します。修正版は10.2.4、10.0.7、10.4.0以降です。アップグレードが根本対応であり、可能な限り早く適用してください。バージョンの確認は管理画面やコマンドから行えます。「いつか入れた古いバージョンのまま動き続けていないか」を、この機会に棚卸ししておくと安全です。
2. すぐにアップグレードできない場合の緩和策
検証や業務都合でアップグレードを即座にできない場合は、暫定の緩和策としてPostgreSQLサイドカーサービスの無効化が挙げられています。具体的には、`$SPLUNK_HOME/etc/system/local/server.conf` に設定を追加してサービスを止める方法です。バックアップ・リカバリ用の補助機能のため、無効化による業務影響を確認したうえで適用してください。加えて、当該エンドポイントへのアクセスをネットワーク側で絞ることも、攻撃面を狭める助けになります。あくまで時間稼ぎであり、最終的にはアップグレードが必要だという点は押さえておいてください。
緩和策を適用したら、それで安心せず「本当に効いているか」を必ず確認してください。サービスを止めたつもりでも設定が反映されていなかった、というのはよくある落とし穴です。後述する検知ツールや、当該エンドポイントへの確認リクエストの応答を使って、無効化が実際に機能しているかを点検しましょう。設定変更は、適用したことより「適用が効いていることを確かめる」ところまでをワンセットにするのが、確実な進め方です。
3. すでに悪用されていないかの確認（IoCの探索）
緩和と並行して、「もう入られていないか」を確認します。KEV入りの脆弱性は、対応する前にすでに突かれている可能性を前提に動くのが安全です。確認の出発点は、後述する検知ポイントに沿ったログの精査です。不審なエンドポイントへのアクセス、想定外のファイル作成、`pg_dump`の異常な実行などが見つかった場合は、侵害を疑い、影響範囲の特定と封じ込めへ進みます。判断に迷う場合は、保守委託先やインシデント対応の専門事業者へ相談するのが現実的です。
攻撃者視点で設計するIoC・検知ポイント
この脆弱性は「未認証の裏口」を通るため、ログイン失敗の監視だけでは拾えません。攻撃の流れに沿って、見るべきポイントを整理します。次の項目は、SIEM（各種ログを集約し相関分析する仕組み）での検知ルールや、ログの手動精査のチェックリストとして使えます。
・サイドカーエンドポイントへのアクセス: `/v1/postgres/recovery/` 配下など、PostgreSQLサイドカーのエンドポイントへの外部・内部からのアクセスログを確認する
・空の認証情報による要求: Basic認証ヘッダが空、または異常な形で送られているリクエストを拾う
・想定外のファイル作成・書き換え: Splunkの稼働ユーザー権限で、通常使わないパスにファイルが作られていないかを見る
・pg_dumpの異常な実行: バックアップ用途以外の文脈で`pg_dump`が走っていないか、実行元やタイミングを確認する
・splunkユーザーからの不審なプロセス起動: ログ収集に無関係なコマンドやシェルの起動を監視する
検知の精度を上げる実用的なヒントとして、watchTowr Labsが無償の検知ツール「Detection Artifact Generator」を公開しています。報告によれば、対象エンドポイントへの確認リクエストに対し、HTTP 400応答が返れば脆弱、401応答ならパッチ済みまたは保護されている状態を示すとされています。自社環境の該当判定の補助として活用できます。
| 攻撃の段階 | 検知すべき痕跡（IoC） | 対応の優先度 |
|---|---|---|
| 未認証アクセス | サイドカーエンドポイントへの空認証リクエスト | 高（即時確認） |
| 足場作り | 想定外パスへのファイル作成・切り詰め | 高 |
| コード実行 | pg_dumpの異常実行・splunkユーザーの不審プロセス | 高（侵害を疑う） |
| 該当判定 | 確認リクエストにHTTP 400応答（脆弱の兆候） | 中（緩和の判断材料） |
中小企業でも今日からできること
専任のセキュリティ担当がいなくても、優先度の高い順に着手できます。次のチェックリストから始めてください。
・バージョン確認: 使っているSplunk Enterpriseが10.2.0～10.2.3 / 10.0.0～10.0.6に該当しないか確認する
・アップグレード計画: 該当するなら10.2.4 / 10.0.7 / 10.4.0以降への更新を最優先で計画する
・暫定の緩和: すぐ更新できない場合はPostgreSQLサイドカーの無効化と、エンドポイントへのアクセス制限を検討する
・痕跡の確認: 上記のIoCに沿って、すでに悪用されていないかログを精査する
・相談先の確保: 自前で判断が難しい場合に相談できる保守委託先・専門事業者の連絡先を、対応の前に確認しておく
KEV入りの脆弱性は「いつか対応すればよい」ものではありません。とはいえ、慌てて手順を飛ばすと痕跡を見落とします。確認・緩和・検知の順で、淡々と進めるのが結果的にいちばん速い対応になります。
PR
攻撃者の動機や思考、攻撃と防御の基礎を実際の事案ベースで学べる定番書です。「なぜ未認証の裏口が致命傷になるのか」を、背景から腹落ちさせたい情シス・SOC担当の土台になります。
よくある疑問（FAQ）
Q1. パッチを当てればもう安心ですか？
アップグレードは根本対応として最優先ですが、それだけで終わりとは限りません。KEV入りの脆弱性は、パッチを当てる前にすでに悪用されている可能性があります。アップグレードと並行して、IoCに沿った痕跡の確認を行い、不審な兆候がないかを点検してください。侵害が疑われる場合は、影響範囲の特定まで進めることが大切です。
Q2. うちのSplunkはインターネットに公開していないので無関係ですか？
外部公開していないことは攻撃面を狭める有効な対策ですが、「無関係」と言い切るのは早計です。社内ネットワークに侵入した攻撃者が、内部から当該エンドポイントへ到達して悪用する経路も考えられます。公開・非公開にかかわらず、該当バージョンであればアップグレードと痕跡確認を実施するのが安全側の判断です。
Q3. CVSS 9.8というのはどれくらい深刻なのですか？
CVSSは脆弱性の深刻度を0～10で表す指標で、9.8は最高レベルに近い評価です。今回の場合「ネットワーク越しに、特別な権限も利用者の操作も不要で、システムへ重大な影響を与えうる」性質を反映しています。さらにKEV入り＝実際の悪用が確認されているため、スコアの高さに加えて「いま現に狙われている」点を重く受け止める必要があります。
Q4. すぐにアップグレードできません。最低限、何をすればよいですか？
まずPostgreSQLサイドカーサービスの無効化（server.confへの設定追加）と、当該エンドポイントへのアクセス制限を検討してください。これは時間を稼ぐための暫定策です。同時に、IoCに沿ってすでに悪用されていないかを確認し、最終的には必ずアップグレードへ進めてください。緩和策だけで放置するのは避けたほうが安全です。
Q5. 検知のために、まずどのログから見ればよいですか？
PostgreSQLサイドカーのエンドポイント（`/v1/postgres/recovery/`配下など）へのアクセスログが出発点です。空の認証情報による要求、想定外パスへのファイル作成、`pg_dump`の異常実行、splunkユーザーからの不審なプロセス起動の順に確認すると、攻撃の流れに沿って痕跡を拾いやすくなります。SIEMを使っているなら、これらを相関ルール化しておくと再発時にも素早く気づけます。
本記事のまとめ
CVE-2026-20253は、ログ監視基盤であるSplunk Enterpriseの補助コンポーネント（PostgreSQLサイドカー）が、空の認証情報を受け入れてしまうことで、未認証のままRCEに至る深刻な脆弱性です。CVSS 9.8でKEV入り――つまり「最高レベルの深刻度」と「現に悪用されている」が重なった、いま動くべき事案です。
やるべきことの軸はシンプルです。該当バージョンかを確認してアップグレードを最優先で進め、すぐ更新できないならサイドカーの無効化とアクセス制限で時間を稼ぎ、IoCに沿ってすでに悪用されていないかを点検する。攻撃者から見れば、認証を要求されない裏口は「壊す必要すらない、開いたままの扉」です。その扉を閉じ、開いていた間に誰も入っていないかを確かめることが、本質的な対応になります。正しく知れば、過度に恐れる必要はありません。落ち着いて、確認・緩和・検知の順で守りを固めていきましょう。
攻撃者の狙う「認証の隙」を、先回りして塞ぐ
KEV入りの脆弱性は、攻撃者がどこを通るかを知ることで、検知も対応も速くなります。
攻撃手法を防御に落とし込む実践的な解説を、これからもお届けしていきます。
