背景
自分で運用している脆弱性ウォッチのサイトに、Splunk Enterprise の CVE-2026-76268 を載せました。
CVSS 9.8 で未認証の OS コマンド実行なので、見出しだけ見るとかなり怖いです。
ただ、アドバイザリを読んでいくと「10.0.x と 9.4.x は対象外」とはっきり書かれていて、そこが少し面白かったので整理しておきます。
古い版のほうが安全、というのはあまり見ないパターンな気がします…。
用語をざっくり
CVE は、公開された脆弱性1件ごとに振られる通し番号だ。
CVSS は脆弱性の深刻度を0〜10で表す指標で、9.0以上が Critical になる。
今回の 9.8 は、Cisco PSIRT（Splunk の親会社 Cisco の脆弱性対応チームで、この CVE を採番した CNA＝採番機関）が付けた値です。
NVD（米国の脆弱性データベース）には 2026年10月7日に登録されていて、NVD 独自の採点はまだ付いていませんでした。
CISA の KEV（実際に悪用が確認された脆弱性の一覧）には、10月8日時点で載っていません。
何が問題なのか
一次情報は Splunk のアドバイザリ SVD-2026-1001 です。
原因は CWE-306（重要な機能に認証が無い）に分類されていて、場所は Patroni の REST API だ。
Patroni は PostgreSQL の死活監視やフェイルオーバーを受け持つ管理ツールで、Splunk はこれを「PostgreSQL サイドカー」として本体の横で動かしている。
アドバイザリによると、サーチヘッドクラスタ（検索を受け持つサーバを複数台束ねた構成）のメンバー上で、この API にネットワークで届けば、認証なしで OS コマンドを実行できる。
対象と修正版は下記のとおりです。
- 10.4.0〜10.4.2 → 10.4.3 で修正
- 10.2.0〜10.2.6 → 10.2.7 で修正
- 10.0.x と 9.4.x → 対象外
なぜ 10.0 と 9.4 は対象外なのか
ここはアドバイザリに理由が書かれているわけではないので、私の読みです。
穴があるのは PostgreSQL サイドカーの管理 API なので、そもそもサイドカーを持たない版には攻撃面が無い、ということだと思います。
緩和策が「サイドカーを止めろ」になっているのも、この読みと合っています。
同じアドバイザリは17件の CVE をまとめて扱っていて、他の CVE 向けには 10.0.10 や 9.4.15 も出ています。
なので「アドバイザリに 9.4.15 が載っているから 9.4 系も上げなきゃ」と読むと、この CVE については空振りになる。
逆に、10.2 系を「修正版の一覧に 10.0.10 があるから 10.0 系の話だろう」と読み飛ばすと、本当に危ないほうを見落とします。
版ごとに、どの CVE の修正なのかを分けて読むのが大事でした。
対象かどうかを判定する
手元に Splunk のホストが何台もあると、splunk version で集めた版の一覧を機械的に振り分けたくなります。
下記は、版の文字列（10.2.6 のような形）を受け取って、この CVE の対象なら true を返す関数です。
範囲は上のアドバイザリの「下限以上・修正版未満」をそのまま配列にしています。
// 版文字列を "." で区切り、数値として左から比べる（-1 / 0 / 1）
function cmp(a, b) {
const x = a.split('.').map(Number);
const y = b.split('.').map(Number);
for (let i = 0; i < Math.max(x.length, y.length); i++) {
const d = (x[i] || 0) - (y[i] || 0);
if (d) return Math.sign(d);
}
return 0;
}
// CVE-2026-76268 の対象範囲: [下限, 修正版)
const ranges = [['10.4.0', '10.4.3'], ['10.2.0', '10.2.7']];
const affected = (v) => ranges.some(([lo, fix]) => cmp(v, lo) >= 0 && cmp(v, fix) < 0);
for (const v of ['10.4.2', '10.4.3', '10.2.6', '10.2.10', '10.0.9', '9.4.14']) {
console.log(v, affected(v));
}
Node.js v24 で実行した結果です。
10.4.2 true
10.4.3 false
10.2.6 true
10.2.10 false
10.0.9 false
9.4.14 false
10.2.10 のような2桁の版も、数値で比べているので「修正済み」に正しく倒れています。
10.0.9 と 9.4.14 は、どちらも修正版より小さいのに false です。
「修正版より古ければ全部危ない」という単純な比較にせず、下限を持たせているのはこのためです。
なお、アドバイザリはサーチヘッドクラスタのメンバーでの露出として書いているので、版が対象に入ったホストについては、クラスタ構成かどうかも合わせて確認します（単独構成が安全だとは明記されていません）。
更新までの緩和策
公式の緩和策は、Edge Processor・OpAmp・SPL2 のデータパイプラインを使っていない場合に限って、PostgreSQL サイドカーを止めることです。
$SPLUNK_HOME/etc/system/local/server.conf に下記を足して、Splunk を再起動します。
[postgres]
disabled = true
サイドカーが動かなければ Patroni の API も立ち上がらないので、穴のある入口そのものが無くなる、という考え方だ。
ただし上の3機能はサイドカーに依存しているので、使っている環境ではこの手が取れません。
その場合は更新を優先し、それまではサーチヘッドクラスタのメンバー同士以外から Patroni の API に届かないよう、ファイアウォールで絞るのが現実的だと思います（こちらは公式の緩和策ではなく、到達経路を減らす一般的な措置です）。
結論
CVE-2026-76268 は、PostgreSQL サイドカーの管理 API に認証が無いことが原因なので、サイドカーを持たない 10.0.x と 9.4.x は対象外で、対象は 10.4.0〜10.4.2 と 10.2.0〜10.2.6 だけです。
判定は版を数値で比べて「下限以上・修正版未満」で振り分け、該当したホストは 10.4.3 / 10.2.7 へ上げます。
すぐ上げられないホストでは、Edge Processor・OpAmp・SPL2 パイプラインを使っていなければ [postgres] disabled = true でサイドカーごと止めるのが、いちばん確実なつなぎです。
本記事はAI補助で執筆した、個人開発の紹介記事です。