Splunk Enterpriseに深刻な脆弱性、認証なしでOSコマンドを実行される恐れ

Splunkは、Splunk Enterpriseに存在する深刻な脆弱性に対処しました。この脆弱性を悪用されると、認証を受けていない攻撃者が、サーチヘッドクラスターのメンバー上でPatroni REST APIを通じてオペレーティングシステムのコマンドを実行できてしまいます。

CVEdatabase access

この問題はセキュリティアドバイザリSVD-2026-1001で2026年10月7日に公表され、CVE-2026-76268として追跡されています。CVSS v3.1スコアは9.8です。悪用には、影響を受けるインターフェースへのネットワークアクセスが必要ですが、認証情報やユーザーの操作は不要です。

Splunk Enterpriseの脆弱性

この脆弱性はSplunk Enterpriseに影響し、10.4系と10.2系のうち、それぞれ10.4.3および10.2.7より前のリリースが対象です。Splunkは、10.0.xと9.4.xについては今回の問題の影響を受けないと明記しています。ただし、これらの系統でも同じリリースサイクルで別の脆弱性に対する更新が提供されています。

この脆弱性の原因は、Patroni Representational State Transfer(REST)APIで公開されている重要な設定操作に認証が欠けていることです。

脆弱なサーチヘッドクラスターのメンバー上でこのインターフェースにアクセスできる攻撃者は、これらの操作を悪用して、攻撃者が指定したコマンドを実行できる可能性があります。Splunkはこの問題をCWE-306「重要な機能に対する認証の欠如」に分類し、社内ではバグ識別子VULN-79185で管理しています。

この脆弱性のCVSSベクターはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hです。ネットワーク経由で、低い複雑さで攻撃でき、必要な権限もユーザーの操作もないことを示しています。

評価では、機密性、完全性、可用性のいずれにも高い影響が想定されています。一方、アドバイザリには、実行されたコマンドがどのようなOS権限を持つのかは記載されていません。エクスプロイトのペイロードも公開されておらず、実際に悪用されたという報告もありません。

この脆弱性を発見したのは、Splunkのガブリエル・ニツ(Gabriel Nitu)氏だとSplunkは伝えています。今回の開示が焦点を当てているのは、認証済みユーザーの操作手順ではなく、公開された設定用インターフェースです。そのため、環境のリスクを評価する際には、ネットワーク上で到達可能かどうかが重要な要素になります。

Splunkのドキュメントによると、PostgreSQLはストレージ用のサイドカーとして位置づけられ、server.confファイルの[postgres]スタンザで制御されます。Splunk Enterpriseではこのサイドカーがデフォルトで有効(`disabled = false`)です。ただし、この初期設定だけで直ちに悪用可能になるわけではありません。アドバイザリが条件として挙げているのは、サーチヘッドクラスターのメンバー上のPatroni APIにアクセスできることです。

管理者は、Patroniが常にTCPポート8008で待ち受けていると思い込まないようにする必要があります。Splunkはこのポートを設定例に記載していますが、IPC Brokerは、特定のサービスアドレスが設定されていない場合、利用可能なポートをランダムに割り当てます。そのため、露出状況の確認では、固定ポートのチェックだけに頼らず、実際のサービスのバインド状況や設定を調べる必要があります。

影響を受けるリリースを運用している組織は、Splunk Enterprise 10.4.3または10.2.7、もしくは各系統のそれ以降のリリースにアップグレードしてください。

これらのバージョンでは、Splunkが9月から10月にかけて実施した広範なセキュリティ更新の一環として、CVE-2026-76268が修正されています。アドバイザリ全体では、10.0.10と9.4.15でも別の問題が修正されたと記載されています。これらの系統は、今回のPatroniの脆弱性の影響を受けません。

Edge Processor、OpAmp、SPL2データパイプラインを使用していない環境向けに、Splunkは回避策を示しています。$SPLUNK_HOME/etc/system/local/server.confの[postgres]スタンザで、`disabled = true`を設定する方法です。

変更を反映するには、Splunk Enterpriseの再起動が必要です。この回避策は機能の利用状況に左右されるため、すべての環境に一律で適用するのではなく、PostgreSQLサイドカーを無効にする前に、依存関係を確認することをお勧めします。

影響が出る前にサイバー脅威を阻止し、MTTRを21分短縮。ANYRUNのSandboxをSOCに統合

翻訳元: https://gbhackers.com/critical-splunk-enterprise-vulnerability/

本記事は gbhackers.com の記事を翻訳・要約したものです。