Splunk Enterprise の脆弱性 CVE-2026-20253 が FIX:認証前 RCE チェーンを確認

Critical Splunk Enterprise Pre-Auth RCE Chain Exposes Databases

2026/06/13 gbhackers — Splunk Enterprise において、認証前リモート・コード実行 (RCE) 脆弱性 CVE-2026-20253 (CVSS 9.8) が公表された。この脆弱性は 2026年6月10日に Splunk により公開されたものであり、Splunk バージョン 10 で導入された、PostgreSQL Sidecar Service に影響を及ぼす。CVE-2026-20253 の根本原因は、PostgreSQL Sidecar Service の HTTP API エンドポイントである “/v1/postgres/recovery/backup” および “/v1/postgres/recovery/restore” に認証制御が存在しない点にある。

これらの内部エンドポイントはプロキシ機構を介して、Splunk のメイン Web アプリケーションからアクセス可能であり、ネットワーク到達可能な攻撃者であれば、有効な認証情報なしで呼び出せる。

影響が最も深刻なのは、Splunk Enterprise の AWS ホスト型環境である。この環境のコンフィグでは、PostgreSQL Sidecar Service がデフォルトでインストール/有効化されるため、初期状態から脆弱となる。その一方で、オンプレミスの Windows 環境では、当該サービスがデフォルトで未導入または無効であるため、即時影響の可能性は低い。

Splunk Enterprise の認証前 RCE

WatchTowr Labs の調査により判明したのは、backupFile パス/database 名といった攻撃者制御パラメータが、”/backup” エンドポイントから pg_dump に直接渡されることだ。backupFile パラメータのパストラバーサルにより、ファイル・システム上の任意パスへのファイル作成などが可能となる。

さらに PostgreSQL の設計上の問題として database パラメータは完全な libpq 接続文字列を受け入れ、その内部パラメータがコマンドライン引数を上書きできることが確認された。これにより攻撃者は hostaddr を注入し、pg_dump の接続先を localhost から攻撃者制御下の PostgreSQL サーバへと変更できる。続いて確認されたのは、”/restore” エンドポイントから pg_restore が利用される構成である。

また “/opt/splunk/var/packages/data/postgres/.pgpass” に平文の “.pgpass” ファイルが存在し、ローカルの postgres_admin 認証情報が露出していることが確認された。この passfile 接続文字列パラメータを注入する攻撃者は、ローカル PostgreSQL インスタンスへの完全な認証を達成し、攻撃者制御のデータベース・ダンプをリストアし、その過程で任意 SQL 実行を可能にする。

悪意のダンプにより PostgreSQL の lo_export 関数が悪用され、攻撃者が制御するコンテンツがファイル・システム上の任意パスへ書き込まれるため、splunk ユーザー権限での任意ファイル書き込みが成立する。任意ファイル書き込みが成立した時点で、RCE に到達するために必要な要素は残り 1 つとなる。

研究者が特定したのは、Splunk が “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py” を定期的に実行していることだ。

この定期実行される挙動を悪用する攻撃者は、lo_export による書き込みプリミティブを用いて、当該 Python スクリプトを悪意のペイロードで上書きできる。それにより、次回実行時に splunk ユーザー権限でコードが実行され、認証前 RCE チェーンが成立する。

影響を受けるバージョンと緩和策
Affected and patched version (Source: WatchTowr)

この脆弱性の影響を受けるバージョンは、Splunk Enterprise 10.x 以降である。その原因は、PostgreSQL Sidecar コンポーネントが、バージョン 10 で導入されたことにある。

Splunk を運用する組織に対する緩和策として、AWS ホスト型環境においては、直ちにパッチ適用を行い、PostgreSQL Sidecar Service ディレクトリへのファイル・システム・アクセス監査を実施する必要がある。また、”.pgpass” ファイルの露出確認および、内部サービスポートと外部インターフェイスの分離確認も求められる。

WatchTowr Labs が、Detection Artifact Generator (DAG) を公開しているため、”/v1/postgres/recovery/backup” エンドポイントが認証なしで応答するかどうかを検査できる。400 ステータスコードは脆弱性の存在を示し、401 は修正済みまたは保護済みを示す。

この脆弱性が示すのは、セキュリティ監視プラットフォームが高価値な標的であること、また、内部サービス API における認証不備が企業全体のセキュリティ態勢を損なう可能性があることだ。