Splunk Enterprise CVE-2026-76289

Exploitation requires an authenticated Splunk account (PR:L) that does NOT need admin or power roles, plus network access to the Splunk Enterprise REST API, specifically the endpoint for lookup table files; the attacker triggers the flaw by supplying response field selections the endpoint fails to bound. Limiting factors: the attacker must already hold valid (even minimal) Splunk credentials, so this is not exploitable by fully unauthenticated outsiders; it affects Splunk Enterprise below 10.4.4, 10.2.8, 10.0.11, and 9.4.16; and impact is confined to availability (no data read or modification). Realistic risk is highest in deployments where many users or integrations have API access, and lower where REST API access is restricted to a small set of trusted administrators.

This is a genuine but moderate-priority availability issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) is internally consistent with the description: a network-reachable REST endpoint, low attack complexity, and a requirement for some authenticated privilege (PR:L) matching the stated 'user who does not hold admin or power roles.' Impact is availability-only (C:N/I:N) via uncontrolled resource consumption (CWE-770), and the service does not self-recover - a restart is required - which raises operational severity above a transient slowdown. No EPSS score, KEV listing, or public POC was provided in the input, so exploitation probability cannot be quantified from the data: per the precision rules, there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is driven by the low barrier (any authenticated low-privilege account suffices) weighed against the limited impact ceiling (denial of service only, no data exposure or code execution). Treat as a meaningful insider/compromised-credential availability risk in multi-tenant or shared Splunk deployments, and lower priority where API access is already tightly restricted to trusted administrators.

A low-privileged authenticated Splunk user - for example a compromised analyst account or a malicious internal user without admin/power roles - sends a crafted request to the REST API endpoint for lookup table files, specifying response field selections that the endpoint fails to bound. The resulting uncontrolled resource consumption exhausts the instance's resources and renders it unavailable to all other users until an administrator performs a full restart. No public exploit code was identified in the provided data, and no user interaction by a victim is required.