CVE-2026-76404: Splunk MCP Serverの安全でないデシリアライズ — CVE-2026-76404

TL;DR

Splunk SVD-2026-0808では、 Splunk MCP Server app 1.2.1未満に存在する、安全でないデシリアライズの脆弱性が公開されています。Splunkのadminロールを持つ利用者が、基盤OS上で任意のコマンドを実行できる問題です。CVE-2026-76404、CWE-502、CVSS v3.1 9.1 （Critical）が割り当てられています。

認証情報管理コンポーネントは、保存データが期待する型か確認せずにデシリアライズしていました。1.2.1以降へ更新してください。直ちに更新できない場合にSplunkが公開している緩和策は、アプリを無効化または削除することです。

本記事には、シリアライズ済みPayload、Gadget chain、Endpoint、コマンド実行PoCを掲載しません。これらは公開アドバイザリに記載されておらず、守りの検証にOSコマンド実行の再現は必要ないためです。

調査理由 / なぜ重要か

MCP ServerはAI Clientと重要なシステムの中間に位置します。認証情報を保持し、検索を実行し、Tool callを特権操作へ変換することがあります。そのため、管理者だけが変更できる場合でも、設定・認証情報ストア自体がセキュリティ境界になります。

アプリケーション管理者は、必ずしもOS管理者として想定された主体ではありません。 CVE-2026-76404は、安全でないデータ変換により、アプリレベルのロールがHost上のコード実行へ変わり得ることを示します。上流のロール確認だけで十分と考えず、保存設定から特権sinkまでの経路全体を確認する必要があります。

Trust Boundary

公開情報から確認できるデータフローは、クラスレベルでは次のとおりです。

Splunkのadminロールを持つ認証済み主体が、MCP Server appの認証情報管理へ到達する。
認証情報に関係する内容が保存され、後にアプリによって読み込まれる。
アプリが期待する型を事前確認せず、その内容をデシリアライズする。
デシリアライズ処理は、基盤OSへ影響を与えられるプロセス内で実行される。

決定的な境界は3です。永続化されたデータが、特権プロセス内のオブジェクトデシリアライザーへ渡ります。一度保存されたことは、信頼できることを意味しません。ストレージから読み出した後、汎用的なオブジェクト再構築を行う前に、利用時点での検証が必要です。

Splunkのアドバイザリは、保存Schema、Route、Serialization library、呼出可能な Gadget、正確なPayloadを公開していません。本記事でも、それらの実装詳細を推測して断定しません。

根本原因

Splunkの説明は、認証情報管理コンポーネントにおける入力検証不足です。保存データが期待する型か確認しないままデシリアライズしており、CWE-502（信頼できないデータのデシリアライズ）に分類されています。

設計上、安全な認証情報Recordは、限定されたPrimitive型のSchemaとして表現できることが望まれます。特権Serviceは、危険なDecoderが実行可能なObjectや振る舞いを持つObjectを構築する前に、想定外の型を拒否すべきです。次の制御は別々に必要です。

Authorization：誰が認証情報Recordを作成・更新できるか。
Schema validation：Recordに何を含められるか。
Safe decoder：RecordがMemory上で何になれるか。
Process isolation：それ以前の制御がすべて失敗した場合の影響をどこまで限定するか。

公開情報が立証するのは型確認の不足までであり、特定の関数やLibraryを根本原因として断定できるSource detailは公開されていません。

Safe reproducer

隔離された許可済みStaging環境では、次をExploitを伴わない検証計画として利用できます。

Splunk MCP Server appの導入Versionを棚卸しする。ベンダー情報上、1.2.1未満は影響を受けるため、Version確認が最も安全で決定的な判定方法です。
StagingのSnapshotを取得し、Splunk Service AccountのProcess・File・Network Telemetryを有効にする。
1.2.1以降へ更新し、使い捨てのTest Credentialで通常の作成・参照・更新・削除が動作することを確認する。
ベンダーから正式なRegression fixtureが提供される場合だけ、復号後の値が想定外の Primitive型またはContainer型になる無害なRecordを投入する。期待結果はValidation Errorであり、子Process、File write、外部通信が発生しないことです。
Test Credentialを削除し、保存する検証LogにSecretが含まれないことを確認する。

Exploit payloadを使わず、必要なSecurity propertyを次のように表現できます。

decode(stored_record) -> primitive credential schema または明示的な拒否
unexpected type      -> 特権Object構築前に拒否
rejection            -> 子Process、File write、Network side effectなし

ProductionのKV Storeへ武器化したSerialized objectを挿入してはいけません。公開アドバイザリには公式の無害なPoCがなく、独自PayloadはSplunk Service Accountの権限で実行されるおそれがあります。

修正差分の評価

公開情報から外部検証できる修正境界はReleaseです。1.2.1未満が影響を受け、1.2.1が修正版です。アドバイザリにはこのアプリの行単位のPatchが公開されていないため、本記事はベンダー説明を超える具体的なCode changeを断定しません。

1.2.1の結果ベースのReviewでは、次を確認します。

Recordが利用直前に厳密な期待Schemaで検証される。
想定外のScalar、Collection、Object型がfail closedになる。
旧形式Recordが安全にMigrationされるか、復旧可能な明示Errorで拒否される。
SecretがValidation errorやDebug logへ複製されない。
認証情報操作がShellや無関係な子Processを生成しない。
アプリが必要最小限のHost権限とSplunk権限で動作する。

Release確認と実環境でのValidationは両方必要です。実装レベルの保証が必要な場合は、非公開Diffを推測せずSplunkへ確認します。

回帰テスト

継続的なTest suiteでは、AuthorizationとData shapeの両方を扱います。

テスト	期待結果
非adminが認証情報管理を試行	保護Recordを読み書きする前に拒否
adminが正しいCredential schemaを送信	正常終了し、LogへSecretを出さない
保存Scalarが想定外の型	明示拒否し、別方式のDeserializationへFallbackしない
保存Collection内に想定外の型	Record全体をAtomicに拒否
更新前の正しいRecordをUpgrade後に参照	安全なMigrationまたは文書化された復旧可能Error
Validation failureを繰り返す	RateとError処理が上限内でSecretを漏らさない
Endpoint telemetryで認証情報操作を観測	Shellや無関係な子Processを生成しない

Backup restoreとRollbackもテストします。現在のWrite pathが安全でも、古いBackupが危険な永続Objectを戻し、その後のRead pathが信頼すれば問題が再発します。

Detection

露出と設定の確認

Version棚卸しから始め、1.2.1未満のMCP Server appが導入されていたSplunk Instanceをすべて特定します。Exposure window、アプリの有効状態、管理者、認証情報管理Dataの変更を記録します。公開されていないSerialized payloadをSignature化するより、Version 確認の方が確度の高い検知です。

Host上の振る舞い

認証情報管理の変更と、Splunk Service AccountによるProcess・File・Network activityを時系列で関連付けます。次のSPLはEndpoint dataを調べる出発点です。Index、Account、 Field mappingを自組織のSchemaへ置き換えてください。

index=YOUR_ENDPOINT_INDEX user="YOUR_SPLUNK_SERVICE_ACCOUNT"
(process_name=sh OR process_name=bash OR process_name=zsh
 OR process_name=cmd.exe OR process_name=powershell.exe OR process_name=pwsh.exe)
| stats count min(_time) as first_seen max(_time) as last_seen
        values(parent_process_name) as parents
        values(command_line) as command_lines
  by host user process_name
| convert ctime(first_seen) ctime(last_seen)

これは製品固有SignatureではなくHunting queryです。Service AccountによるShell実行が正当な場合も、攻撃がShellを使わない場合もあります。想定外の子Process、新規実行 File、初見Destinationへの外部通信、通常のMaintenance window外の活動にも範囲を広げます。相関に使える管理者Identity、Source address、Request IDまたはChange IDを保持してください。

Incident Response

露出または不審なHost activityを確認した場合は、次の順で対応します。

InstanceへのAccessを制限し、Splunk audit data、App log、Credential storeの Metadata、Endpoint telemetry、関連Network logを保全する。
System変更前に導入済みApp versionとHashを記録する。
Exposure window中の全管理者による認証情報管理操作を確認し、Host process・ Network eventと相関する。
Splunk Service Accountの権限と到達可能Systemを特定する。
アプリが参照できたCredentialを、Lateral movementにつながるTokenから優先して Rotationし、必要に応じてActive sessionを失効する。
1.2.1以降へ更新またはアプリを削除する。OS侵害を排除できない場合は、信頼できる BaselineからHostを再構築する。
上記Regression testと新しいTelemetryを確認してからServiceを再開する。

Containmentの緊急性がForensics上の価値を上回る場合を除き、証拠収集前に疑わしい Recordを削除したりHostを再起動したりしないでください。

Disclosure Timeline

報告日： 参照した公開アドバイザリには記載されていません。
2026-08-19： SplunkがSVD-2026-0808を公開・更新し、MCP Server app 1.2.1を修正版として掲載。Kuniyoshi Noguchi（KuniNogu）をAcknowledgmentsへ掲載。
非公開のTriage、Patch開発、Validationの日付： 参照したアドバイザリには記載されていません。

CVE番号やRelease metadataから、非公開の調整日を推測して補っていません。