Splunk Enterprise CVE-2026-76269

Exploitation requires an authenticated Splunk Enterprise account that does NOT hold the 'admin' or 'power' roles, plus network access to the REST API endpoint that returns search job information. The attacker supplies a user-controlled job identifier for a job owned by another user; the vulnerable condition is that the REST API does not fully validate job ownership before returning data. This affects default deployments of the listed versions (no special feature toggle is named), but is inherently limited to deployments with more than one user, since the value lies in reading OTHER users' jobs - single-user or non-shared instances have little exposure. Limiting factors: valid low-privilege credentials are mandatory (PR:L), impact is read-only confidentiality disclosure, and affected versions must be below 10.4.3 / 10.2.7 / 10.0.10 / 9.4.15.

This is a moderate-severity authorization flaw (CVSS 6.5) rather than a critical one, and the signals are internally consistent. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N correctly reflects an authenticated (PR:L) low-privilege Splunk user abusing a REST API over the network with low complexity to read other users' search jobs - a textbook CWE-639 Insecure Direct Object Reference (IDOR). Impact is confidentiality-only (C:H, I:N, A:N): no code execution, no data modification, no availability loss. No EPSS score, CISA KEV listing, or public POC was provided, so exploitation is 'no public exploit identified at time of analysis'; there is no SSVC decision data in the input. The key limiting factor is PR:L - an attacker must already possess valid Splunk credentials for a non-admin, non-power account, which constrains this to insiders or attackers who have already obtained a foothold/low-tier account, making it a privilege-escalation-of-data-access issue rather than a remote-unauthenticated breach. Real priority is elevated in multi-tenant or shared Splunk deployments where search queries and results contain sensitive data, but it is not an emergency internet-facing threat. The 'Authentication Bypass' tag overstates the issue: this is an authorization (ownership-validation) bypass, not an authentication bypass - the attacker is authenticated.

An authenticated Splunk user without admin or power roles - for example, a low-tier analyst or a compromised limited account - enumerates or guesses search job identifiers and requests them through the REST API. Because the API does not fully validate job ownership, the attacker retrieves other users' search query text, job metadata, and (preview) results, potentially exposing sensitive data such as credentials or security-investigation details embedded in colleagues' searches. No public exploit code is identified at time of analysis, and exploitation requires valid low-privilege credentials.