米国CISA(Cybersecurity and Infrastructure Security Agency)は2026年6月18日、Splunk Enterpriseの重大な脆弱性が積極的に悪用されているとして、連邦民間行政機関(FCEB)に対し日曜日(6月21日)までにシステムを保護するよう求めました。
脆弱性はCVE-2026-20253として追跡され、CVSSv3.1スコアは9.8(Critical)。Splunk Enterprise(バージョン10.2.0〜10.2.3、10.0.0〜10.0.6)に影響し、権限を持たない遠隔の攻撃者が、PostgreSQLサイドカーサービスのエンドポイントを通じて任意のファイルを作成・切り詰め(truncate)できるという深刻な内容です。
Splunkセキュリティチームは公式アドバイザリで「この脆弱性はPostgreSQLサイドカーサービスのエンドポイントに認証制御が欠如していることに起因し、ネットワークから到達可能な任意のユーザーが認証情報なしにファイル操作を呼び出せる」と説明しています。
Splunkがパッチを公開した数日後の6月12日、脅威インテリジェンス企業watchTowr Labsが技術的な詳細解説とPoC(概念実証)エクスプロイトコードを公開し、この脆弱性がリモートコード実行(RCE)攻撃に悪用可能であると警告しました。そして6月18日(水)、Splunkはアドバイザリを更新し、サイバー攻撃への悪用の証拠があるとして顧客に至急のパッチ適用を呼びかけました。本記事ではSplunk公式アドバイザリ・watchTowr Labsの技術分析をもとに、脆弱性の仕組み・悪用の経緯・対応手順を解説します。
サマリー
- CVE番号:CVE-2026-20253
- CVSSv3.1スコア:9.8(Critical)——ベクトル:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CWE分類:CWE-306(重要機能における認証の欠如)
- 影響を受けるバージョン:
- Splunk Enterprise 10.2.0〜10.2.3
- Splunk Enterprise 10.0.0〜10.0.6
- 修正バージョン:10.4.0、10.2.4、10.0.7以降
- 影響を受けないバージョン:Splunk Enterprise 9.4以前・Splunk Cloud Platform(PostgreSQLサイドカーを使用しないため対象外)
- Splunkアドバイザリ公開日:2026年6月10日(SVD-2026-0603)
- PoC公開:2026年6月12日——watchTowr Labsが技術解説とエクスプロイトコードを公開
- 野生での悪用確認:2026年6月18日——SplunkがアドバイザリでPSIRT(Product Security Incident Response Team)による限定的な悪用の確認を追記
- CISA KEV追加:2026年6月18日(同日)——CVE-2026-20253はSplunk史上初めてKEVカタログに追加された脆弱性
- 連邦機関対応期限:2026年6月21日(日)
- 脆弱性の原因:PostgreSQLサイドカーサービス(バックアップ/リカバリ機能)のHTTPエンドポイントが、Basic認証ヘッダーを要求しているように見えながら、実際には空の認証情報でも受け入れてしまうという実装不備
- 攻撃の連鎖:①パストラバーサルによる任意ファイル作成/切り詰め→②PostgreSQL接続文字列インジェクション→③
pg_dump機能の悪用→**完全なリモートコード実行(RCE)**へ昇格可能 - 回避策:公式の回避策は**「PostgreSQLサイドカーサービスを無効化する」のみ**。ただしEdge Processor・OpAmp・SPL2データパイプラインを使用している環境では適用不可
- 特に危険な環境:Splunk Enterprise on AWS——PostgreSQLサイドカーサービスがデフォルトで有効化されており、初期状態から脆弱
- 同時に修正された関連脆弱性:CVE-2026-20251(CVSS 8.8・Secure Gatewayの安全でないデシリアライゼーション)・CVE-2026-20252(CVSS 7.6・PDF出力のSSRF)・CVE-2026-20258(CVSS 7.1・ダッシュボードの格納型XSS)
目次
脆弱性の技術的詳細—「認証ヘッダーがあるのに認証されない」という欠陥
PostgreSQLサイドカーサービスとは
Splunk Enterprise バージョン10で導入された「サイドカー(Sidecar)」という概念に基づき、PostgreSQLサイドカーサービスはデータベースのバックアップ・リカバリ操作を担当するコンポーネントとして実装されています。このサービスはローカルホスト(127.0.0.1)のポート5435でのみ待ち受けるよう設計されており、一見ネットワークから直接到達できないように見えます。
なぜ「ローカルのみ」のサービスが遠隔から悪用できるのか
watchTowr Labsの技術分析によれば、実際にはSplunkのメイン Webインターフェース(ポート8000で全インターフェースに公開)が、このローカル限定のサービスへリクエストを転送(プロキシ)する仕組みを持っていました。これにより、外部の攻撃者がSplunkの公開Webサーバーへリクエストを送信するだけで、本来到達できないはずの内部サービスのエンドポイント(/en-US/splunkd/__raw/v1/postgres/recovery/backup等)へ間接的に到達できてしまいます。
「Basic認証を要求しているのに、空でも通る」という設計不備
Picus Securityの分析によれば、このリカバリエンドポイントは一見HTTP Basic認証ヘッダーを要求しているように見えますが、実際にはいかなる認証情報も(空であっても)受け入れてしまう仕組みになっていました。
具体的には、空のユーザー名・パスワードをBase64エンコードしたAuthorization: Basic Og==というヘッダー値だけで、バックアップ操作を呼び出し成功レスポンスを得ることができます。提供されたユーザー名はそのままPostgreSQLツール(pg_dump等)へ渡されるだけで、サイドカーサービス自体は一切の認証検証を行いません。
ファイル作成からRCEへの連鎖
watchTowr Labsが解明した攻撃連鎖は以下の段階で進みます。
①任意ファイルの作成・切り詰め:/backupエンドポイントへの細工されたリクエストで、backupFileパラメータにパストラバーサルシーケンスを含めることで、pg_dumpが攻撃者の選択した任意のパスに空ファイルを書き込みます。backupFileパラメータは安全なディレクトリに制限されておらず、Splunkユーザーが書き込み可能などこにでもファイルを作成できます。
②接続文字列インジェクション:databaseパラメータがそのままPostgreSQL接続文字列に渡されるため、攻撃者は接続パラメータを操作できます。
③RCEへの昇格:これら2つの脆弱性プリミティブを組み合わせることで、攻撃者は最終的にsplunkユーザー権限での任意コード実行を達成できます。GBHackersは、PostgreSQLのlo_export機能を悪用してスクリプトを書き込み、実行する手法が確認されたと報じています。
特に危険な環境——AWS上のSplunk Enterprise
GBHackersの報告によれば、この脆弱性の影響は環境によって大きく異なります。
| 環境 | PostgreSQLサイドカーの状態 |
|---|---|
| Splunk Enterprise on AWS | デフォルトでインストール・有効化——初期状態から脆弱 |
| Windows手動インストール | デフォルトでは未インストールの場合が多い |
| Splunk Cloud Platform | 使用していないため対象外 |
AWS上でSplunk Enterpriseを運用している組織は、特別な設定変更をしていなくても初期状態で脆弱性の影響を受ける可能性が高く、最優先での確認・対応が必要です。
悪用までのタイムライン
| 日付 | 出来事 |
|---|---|
| 2026年6月10日 | Splunkがアドバイザリ「SVD-2026-0603」を公開。パッチ(10.4.0/10.2.4/10.0.7)をリリース |
| 2026年6月12日 | Splunkがアドバイザリを更新し、Splunk Cloud Platformが対象外であることを明確化 |
| 2026年6月12日 | watchTowr Labsが技術的詳細解説とPoCエクスプロイトコードを公開 |
| 2026年6月15日 | Splunkがアドバイザリを更新し、PostgreSQLサイドカーサービスを無効化する回避策を追加。Splunk Enterprise 9.3・9.4バージョンが対象外であることを明確化リストに追加 |
| 2026年6月18日(水) | Splunk PSIRTが「限定的な悪用」を確認したことをアドバイザリに追記。CISAが同日中にKEVカタログへ追加(Splunk史上初) |
| 2026年6月21日(日) | 連邦民間行政機関の対応期限(CISA要求) |
なぜ「Splunk史上初のKEV追加」が重大な意味を持つのか
SOCRadarの分析が強調する通り、CVE-2026-20253はSplunk製品としてCISA KEVカタログに追加された初めての脆弱性です。
これはSplunkというプラットフォームの性質上、極めて重い意味を持ちます。
Help Net Securityが引用したResecurityの研究者コメントによれば「Splunkがセキュリティ監視・運用インテリジェンスにおいて担う中心的な役割を踏まえると、このプラットフォームの侵害は組織の可視性を著しく低下させ、追加の悪意ある活動が検知されずに進行することを可能にしてしまう」とされています。
Splunkは組織全体のログ・メトリクス・イベントデータを収集・インデックス化し、SIEM(セキュリティ情報イベント管理)の中核プラットフォームとして機能しています。攻撃者がこの基盤を侵害できれば、以下のような深刻な二次被害につながります。
- セキュリティデータの改ざん・削除
- 保存された認証情報の窃取
- 他の内部システムへの横移動(ラテラルムーブメント)の足がかり
- 「監視するはずの仕組み自体」が機能不全に陥り、後続の攻撃が検知されないまま進行する
対応手順
① Splunkのバージョン確認と至急のアップグレード
唯一の完全な対策はアップグレードのみです。以下のいずれかのバージョンへ更新してください。
Splunk Enterprise: 10.4.0、10.2.4、10.0.7 以降
LatestHackingNewsによれば、Splunk Cloud Platformの修正済みビルドは10.4.2604.3・10.3.2512.12・10.2.2510.15・10.1.2507.23・9.3.2411.132等とされています(Cloud自体は本CVEの対象外ですが、同時に修正された他の脆弱性に対応するため)。
② 即時アップグレードが困難な場合の緩和策
Splunk公式アドバイザリが示す緩和策は、PostgreSQLサイドカーサービスを無効化することのみです。
# $SPLUNK_HOME/etc/system/local/server.conf に追加
[postgres]
disabled = true
設定変更後、Splunk Enterpriseを再起動してください。
重要な注意点:Edge Processor・OpAmp・SPL2データパイプラインを使用しているインスタンスでは、この回避策を適用しないでください。PostgreSQLの無効化によりこれらの機能が壊れ、依存するサイドカープロセスに連鎖的な影響が生じる可能性があります。コアのサーチ・インデックス作成・ダッシュボード機能には影響しません。
③ ネットワークレベルでの一時的な制限
アップグレードまでの間、リバースプロキシ・WAFレベルで以下のパスへのアクセスを制限することを検討してください。
/v1/postgres/recovery/backup
/v1/postgres/recovery/restore
ただしこれは補完的な緩和策であり、パッチ適用やサービス無効化の代替にはなりません。
④ 侵害の痕跡(IOC)の確認
Help Net Securityが引用するResecurityの推奨に従い、以下の痕跡を確認してください。
- パストラバーサルシーケンス(
../)を含むリクエスト hostaddr=・dbname=・port=・passfile=等のPostgreSQL接続パラメータを含むリクエスト- Splunkサービスから未知のPostgreSQLサーバーへの不審な外向き接続
- Splunkホスト上の予期しないファイル作成・切り詰め(特に機密ディレクトリ内)
- EDRテレメトリ上での、Splunkサービスから生成された異常な子プロセス
⑤ watchTowrの検知ツールの活用
watchTowr Labsは、自社環境がこの脆弱性に対して脆弱かどうかを確認できる「Detection Artifact Generator(DAG)」をGitHub上で無償公開しています。/v1/postgres/recovery/backupエンドポイントの応答を確認し、400ステータスが返れば脆弱、401であればパッチ適用済みまたは保護されていることを示します。なお、このツールは検知のみを行い、実際の悪用は行いません。
FAQ
Q. Splunk Cloud Platformを使用していますが、対応は必要ですか? A. CVE-2026-20253自体への対応は不要です。Splunk Cloud PlatformはPostgreSQLサイドカーアーキテクチャを使用していないため、本脆弱性の対象外です。ただし同時に修正されたCVE-2026-20204(CVSS高評価、Splunk Enterprise・Cloud両方に影響するRCE)など、他の関連脆弱性については別途確認が必要です。
Q. PoCが公開されてからすぐに悪用が始まったのですか? A. watchTowr LabsがPoCを公開したのは6月12日、Splunkが悪用を確認・公表したのは6月18日です。約6日間で実際の攻撃に悪用されたことになります。
Q. 自社のSplunk環境が既に侵害されたかどうかを確認する方法は? A. 本記事のIOCセクションで紹介した不審なファイル作成パターン・接続パラメータの確認に加え、Splunkサーバーのログ・ファイルシステムを精査してください。watchTowrのDetection Artifact Generatorで脆弱性の有無を先に確認することも有効です。
参考情報
- Splunk公式アドバイザリ「SVD-2026-0603」(CVE-2026-20253、2026年6月10日公開・6月18日更新)
- watchTowr Labs「Why Use App-Level Auth When Every Database Has Auth? (Splunk Enterprise CVE-2026-20253 Pre-Auth RCE)」(2026年6月12日)
- SOCRadar「CVE-2026-20253: CISA Warns of Actively Exploited Splunk Enterprise RCE」
- Picus Security「CVE-2026-20253: Splunk Enterprise Unauthenticated Remote Code Execution Vulnerability Explained」
- GitHub「watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253」(無償検知ツール)
- 当サイト関連:Fortinet FortiSandboxの3件のCritical脆弱性が積極的に悪用中——同時期の未認証RCE脆弱性事案
- 当サイト関連:Jenkins CVE-2026-53435——開示から数時間で積極的悪用が確認されたRCE脆弱性との比較
- 当サイト関連:サイバー攻撃・情報漏えい最新事例まとめ2026








