Splunk Secure Gateway EUVD-2026-94617

Requires a valid but low-privilege Splunk account that does NOT hold the 'admin' or 'power' roles, plus network reachability to the Splunk Secure Gateway REST API on an affected Splunk Enterprise (below 10.4.3/10.2.7/10.0.10/9.4.15) or standalone Secure Gateway (below 3.10.11/3.9.25/3.8.72) instance. The specific trigger is that multiple Splunk Secure Gateway REST API endpoints do not perform role/authorization checks before processing requests, so any authenticated session can reach privileged signing functionality. Limiting factors: exploitation is gated by authentication (an attacker must already possess or obtain Splunk credentials), requires Splunk Secure Gateway to be deployed/enabled, and no user interaction or special non-default configuration is otherwise needed.

This is a moderate, real-but-not-urgent priority. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5 Medium) indicates a network-reachable, low-complexity authorization flaw requiring an already-authenticated low-privilege Splunk account (PR:L) with no user interaction - so it is an authenticated post-access issue, not a pre-auth internet-facing break. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input; exploitation status is therefore 'no public exploit identified at time of analysis.' A notable internal inconsistency exists: the vendor scored impact as C:H/I:N/A:N (confidentiality only), yet the description's concrete harm - causing Splunk Secure Gateway to sign attacker-controlled payloads via unauthorized REST endpoints - reads primarily as an INTEGRITY impact, not confidentiality. This C:H with I:N mapping should be verified with Splunk, as the demonstrated capability (forging signed/trusted content) suggests integrity exposure. Because exploitation needs a valid non-admin account and no active exploitation is reported, this is a genuine but lower-tier priority best treated as part of routine Splunk patching rather than emergency response.

A low-privilege authenticated Splunk user (lacking the 'admin' or 'power' role) sends crafted requests to Splunk Secure Gateway REST API endpoints that fail to enforce authorization, gaining access to privileged functionality. Using this, the attacker coerces Secure Gateway into cryptographically signing payloads they control, producing trusted artifacts they should never be able to generate. No public exploit code was identified in the provided data.