Splunk 脆弱性CVE-2026-76299：影響版の確認と10.2.8などへの更新手順

Splunkは2026年10月21日、Splunk Enterpriseに見つかった複数の脆弱性をまとめた勧告SVD-2026-1008を公表しました。そのうちCVE-2026-76299はアクセス制御の不備で、CVSS v3.1の値は9.9のCriticalです。この記事では、勧告に書かれている事実と書かれていないこと、SPLとREST APIで全サーバーの版を判定する方法、10月7日の修正版を入れた環境でも更新が要る理由、どのサーバーから先に上げるかの基準を順に整理しました。内容は2026年10月23日時点の公開情報にもとづきます。

まとめ：10.4.4・10.2.8・10.0.11・9.4.16未満は更新、回避策は無し

影響を受けるのは、10.4.0〜10.4.3、10.2.0〜10.2.7、10.0.0〜10.0.10、9.4.0〜9.4.15のSplunk Enterpriseです。同じ系列の10.4.4・10.2.8・10.0.11・9.4.16以上へ上げれば直ります。勧告に回避策の記載は無く、設定変更でしのぐ手段はありません。

攻撃にはSplunkへログインできるアカウントが要りますが、権限は低くてかまいません。利用者の多い検索ヘッドから更新し、10月7日に10.2.7などへ上げたばかりの環境も、もう一度上げてください。社内のログ基盤を含めて公開範囲と版をまとめて点検したい場合は、脆弱性診断・セキュリティ診断で棚卸しすると見落としが減ります。

SVD-2026-1008：CVE-2026-76299のCVSS 9.9と同時公表の4件

まず勧告に書かれている事実と、書かれていないことを分けて押さえます。

CVE-2026-76299はアクセス制御の不備で評価はPR:LかつS:Cの9.9

SVD-2026-1008は、社内で見つけた複数の脆弱性を弱点の種類（CWE）ごとにまとめ、1つの種類に1つのCVE番号を振った「Security Hardening」型の勧告です。CVE-2026-76299はCWE-284（不適切なアクセス制御）の束です。

勧告本文にCVSSのベクトルはありません。NVDとCVE.orgのレコードに載っている値は「AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H」です。ネットワーク越しに、低い権限で、利用者の操作なしに突けて、影響がSplunkの外へ及ぶ（S:C）という評価になります。読み方の基礎はCVSSv3の計算式とスコアの目安で確認できます。どの画面やAPIが該当するかは公表されていません。

同じ勧告で公表された4件のCVEの内容と、個別の手口が公表されない理由

SVD-2026-1008に含まれるCVEは4件です。

CVEの説明文はどれも「Ciscoの社内セキュリティレビューで見つかった」という定型文で、手口には触れていません。複数の不具合を1番号に束ねているため、1件ずつの条件を外部から確かめる手段もありません。つまり「うちの使い方なら当たらない」と判断する材料が出てこない勧告です。この性質が、後で述べる「回避策を探すより更新」という結論につながります。

SSVCは悪用なし・自動化不可・影響total、KEVは未掲載

CVE.orgのレコードには、CISAが10月22日に付けたSSVC（対応の優先度を決める判定）が入っています。値は「Exploitation: none」「Automatable: no」「Technical Impact: total」でした。悪用の報告は無く、ログインが要るため大量の自動攻撃には向かない一方、成功すれば被害は全面的という判定です。

2026年10月23日に取得したCISAのKEVカタログにも本件はありません。ただしKEVには、6月18日にSplunk EnterpriseのCVE-2026-20253（SVD-2026-0603、PostgreSQLサイドカーへの認証なしのファイル作成）が追加され、対応期限は3日後の6月21日でした。Splunkは攻撃対象として現に狙われる製品で、「悪用なし」は公表時点の状態にすぎません。

影響版の確認：SPLのrestコマンドとREST APIで全サーバーの版を棚卸し

判定に必要なのは、各サーバーの版と、その版が属する系列の2つです。

4系列の影響範囲と修正版、勧告の表に載らない10.6系とUF

SVD-2026-1008の対象は次の4系列です。SVD-2026-1007とSVD-2026-1009も同じ表で、修正版は共通です。

サポート終了日はSplunk Support Policyの表によります。9月30日に出た10.6系は、10月23日時点で勧告の表に載っていません。また事前告知のSVD-2026-1006は、10月21日の更新でUniversal Forwarderを開示対象から外しました。フォワーダーだけのサーバーは今回の更新対象から外してよく、判定は検索ヘッド・インデクサー・デプロイメントサーバーなどの本体に絞れます。

CLI・splunk.version・SPLのrestコマンドで版を確かめる方法

1台ずつ見るなら、版の確認方法を示した公式docsにある次の方法が使えます。

# サーバー上で確認する（どちらか）
$SPLUNK_HOME/bin/splunk -version
cat $SPLUNK_HOME/etc/splunk.version

# 検索ヘッドのサーチバーで実行（自分自身の版）
| rest splunk_server=local count=1 /services/server/info | table version

# 同じ検索ヘッドから、つながっている検索ピアの版をまとめて出す
| rest splunk_server=* count=1 /services/server/info
| table splunk_server version server_roles

3つ目の検索は、restコマンドの引数splunk_serverにワイルドカードを渡し、分散検索でつながるインデクサーの版を一度に返させるものです。ただし検索ピアに登録されていないデプロイメントサーバーやライセンスマスターは出てきません。そうしたサーバーは次のスクリプトで拾います。

管理ポート8089へトークンで問い合わせるPythonの判定スクリプト

Splunkの管理ポートは、認証トークンを「Authorization: Bearer」ヘッダで受け付けます。標準ライブラリだけで、複数ホストの版を勧告の表と突き合わせる例です。

import json
import ssl
import sys
import urllib.request

# SVD-2026-1008 の修正版（系列 : 修正版）
FIXED = {"10.4": "10.4.4", "10.2": "10.2.8", "10.0": "10.0.11", "9.4": "9.4.16"}

def ver(s):
    return tuple(int(x) for x in s.split(".")[:3])

def judge(version):
    branch = ".".join(version.split(".")[:2])
    if branch not in FIXED:
        return "表に無い系列（10.6系、または9.3以前）"
    if ver(version) >= ver(FIXED[branch]):
        return "修正済み"
    return "要更新 → " + FIXED[branch]

# 使い方: python check_splunk.py token.txt ca.pem sh01.example.local idx01.example.local
token = open(sys.argv[1]).read().strip()
ctx = ssl.create_default_context(cafile=sys.argv[2])  # 管理ポートの証明書を出したCA

for host in sys.argv[3:]:
    url = "https://" + host + ":8089/services/server/info?output_mode=json"
    req = urllib.request.Request(url, headers={"Authorization": "Bearer " + token})
    with urllib.request.urlopen(req, context=ctx, timeout=15) as r:
        content = json.load(r)["entry"][0]["content"]
    print(host, content["version"], judge(content["version"]),
          ",".join(content.get("server_roles", [])))

判定部分は10.2.7で「要更新 → 10.2.8」、10.4.4で「修正済み」、10.6.0.5と9.3.9で「表に無い系列」を返すことを、2026年10月23日に手元で確かめました。証明書の検証を外す（curlの-kに当たる設定）のは、docsも一時的な確認に限るとしています。9.3以前は7月24日にサポートが終わっており、修正版は出ません。

更新手順：10月7日の10.2.7を入れた環境も再更新が要る理由と順序

Splunkの勧告は月に2回まとまって出ることがあり、今回がその例です。

10月7日のSVD-2026-1002と10月21日の修正版が別物である点

10月7日にはSVD-2026-1002が出ており、修正版は10.4.3・10.2.7・10.0.10・9.4.15でした。こちらもCVE-2026-76281（CVSS 9.8）を含むCriticalの勧告です。その2週間後のSVD-2026-1008は、まさにその版を影響範囲に含めています。10月7日の勧告に合わせて上げた環境は、もう1段上げないと今回の穴が残ります。

一方、修正版は勧告より前から配布されていました。10.4.4のFixed issuesは9月29日に更新されていますが、セキュリティ関連の修正は勧告でだけ開示すると注記しています。リリースノートの修正一覧だけを見て「急ぎの修正は無い」と見送った環境が、今回の対象に残りやすい構造です。tar形式の更新手順と、更新後のKV Storeの確認はSplunk Enterprise 10.2の更新履歴とアップグレード要件にまとめています。

Secure Gatewayの更新とEdge Processorで必要な追加作業

同じ日のSVD-2026-1007には、本体の更新だけでは終わらない項目が2つあります。

• CVE-2026-76292とCVE-2026-76295：アプリのSplunk Secure Gatewayを3.10.12・3.9.26・3.8.73以上へ別に上げる
• CVE-2026-76290：本体の更新後、既存のEdge Processorを用意し直し、パッケージのダウンロードに認証を掛けて再起動する
• CVE-2026-76288：認証なしの1回のリクエストでSplunk Webが止まるDoS（7.5）。外部に面したSplunk Webがあれば優先度を上げる

Secure GatewayはSplunk Mobileなどで使うアプリで、標準で入っている環境が多いはずです。本体と同じ保守時間で更新しておくと、停止が1回で済みます。

PostgreSQLサイドカーを止める回避策が使える構成と使えない構成

SVD-2026-1007のCVE-2026-76298（8.8）は、PostgreSQLサイドカーに埋め込まれた暗号鍵の問題で、こちらには回避策があります。server.confで次のように止めて再起動します。

# $SPLUNK_HOME/etc/system/local/server.conf
[postgres]
disabled = true

ただし勧告は、Edge Processor・OpAmp・SPL2のパイプラインを使う環境では機能が止まるので適用しないよう書いています。しかもこれは76298だけの回避策で、CVE-2026-76299には効きません。サイドカーはKEVに載ったCVE-2026-20253と同じ部品です。使っていないなら止めておく価値はありますが、更新の代わりにはなりません。

対応の優先順位：ログインできる利用者数と9.4系の期限で決める基準

複数のSplunkサーバーを抱えている場合の順番を、条件ごとに言い切ります。

低権限のアカウントが多い検索ヘッドで、当日中の更新を優先する判断基準

最優先は、多くの部署の利用者がログインする検索ヘッドです。CVE-2026-76299は低い権限で突けるため、SOCの分析担当や開発者に配ったアカウント、外部の運用委託先のアカウントがそのまま入口になります。SAMLなどで社内の全員がログインできる構成なら、当日中に更新か、少なくとも利用者を絞ります。

次がインデクサーとデプロイメントサーバーで、週内に上げます。利用者のログインを受けないぶん入口は狭いものの、S:Cの評価どおり影響が外へ広がる以上、後回しにする理由はありません。逆に「詳細が出ていないので様子を見る」は誤りです。詳細が出ないことはこの種の勧告の仕様で、待っても判断材料は増えません。監視の体制ごと見直す場合は、SOCの内製とアウトソースの判断も参考になります。

9.4系は12月16日のサポート終了を見据えて10.x系へ移す

9.4系には修正版9.4.16が出ていますが、系列のサポートは2026年12月16日に終わります。今回9.4.16へ上げても、2か月後には同じ判断がまた来ます。

9.4系のサーバーは、今回は9.4.16で穴をふさぎ、12月16日までに10.2系か10.4系への移行を終える二段構えにします。10.4はLinuxでのroot実行をサポート外にするなど要件が変わるので、移行先の選び方はSplunkの構成要素と10.4系の要件変更で確かめてください。同じ日にはSplunk SOARにもSVD-2026-1011などCriticalの勧告が出ており、SOARを併用している環境は8.7.0への更新も同じ計画に入れます。改修範囲や外部委託の費用から整理したい場合は、脆弱性診断の進め方と外注時の判断基準が出発点になります。

Splunk CVE-2026-76299の対応でよくある質問と回答

CVE-2026-76299の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

Splunk Cloud Platformの利用者も自分で更新する必要がありますか？

SVD-2026-1008の影響範囲の表に載っているのはSplunk Enterpriseだけで、Splunk Cloud Platformの記載はありません。Cloud Platformは版の付け方も別で、基盤の更新はSplunk側が行う前提のサービスです。自社で入れたヘビーフォワーダーや、オンプレミスに残した検索ヘッドなどEnterpriseのサーバーがあれば、それらは本記事の手順で判定してください。

Universal Forwarderも更新しないといけませんか？

今回の勧告の表はSplunk Enterpriseだけです。事前告知のSVD-2026-1006も、10月21日の更新でUniversal Forwarderを開示対象から外しました。このためフォワーダーは今回の更新対象に入れなくてかまいません。ただし台数が多く版がばらつきやすい部品なので、デプロイメントサーバーでの定期の版管理からは外さないでください。

10.6系を使っていれば影響を受けませんか？

2026年10月23日時点で、SVD-2026-1007・1008・1009の表に10.6系の記載はありません。10.6系は9月30日に出た系列で、表に載らない理由は勧告に書かれていません。影響なしと断定できる材料は無いため、10.6系の最新パッチに上げたうえで、勧告ページの更新を追ってください。

実際の攻撃や悪用は確認されていますか？

勧告に悪用の記載は無く、CISAのSSVCも「Exploitation: none」です。2026年10月23日時点でKEVにも載っていません。ただし6月のCVE-2026-20253は、6月10日の勧告公表から8日後の6月18日にKEVへ追加されました。修正の差分から手口を割り出される前に更新を終えるのが筋です。

CVSS 9.9なのに、なぜ回避策が示されていないのですか？

SVD-2026-1008は、社内レビューで見つけた多数の不具合をCWEごとに束ねた勧告で、個々の不具合の場所を公表していません。場所が分からない以上、特定の設定やWAFのルールで止める方法も示せません。このため対策は修正版への更新だけです。同じ日のSVD-2026-1007には個別の回避策が付いた項目もありますが、それらはCVE-2026-76299には効きません。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：公表から修正までの流れの基礎です。
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVEとNVDの登録の関係を整理しています。
• O11y Cloud Free Edition徹底ガイド｜15ホスト無期限無料で始めるSplunk可観測性：Splunkのクラウド側の製品構成です。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：勧告が続く製品の管理の回し方です。
• nginx 1.30.3の脆弱性修正：CVE-2026-42055のCVSS v4.0スコア9.2の読み方と更新先：同じ月の別製品の版確認と更新の例です。