CVE-2026-76352

This CVE exposes a fundamental gap between Splunk's documented RBAC model and its actual enforcement at the configuration endpoint layer. The transforms API endpoints — specifically those handling scripted lookups — do not perform capability checks, allowing any authenticated user to create or modify lookup definitions that point to arbitrary scripts, regardless of whether their assigned role should permit such configuration. This is not a missing ACL or a misconfiguration; it is a capability enforcement failure in the configuration layer itself, where the system apparently assumed that any authenticated caller was authorized to configure transforms. The privilege escalation path is direct: a low-privilege user creates a scripted lookup referencing a malicious script, and that script executes with Splunk service account privileges. On most deployments, that service account runs as SYSTEM or root, and on domain-joined hosts it often has domain admin-equivalent access to read logs, credentials, and authentication tokens across the infrastructure Splunk monitors. Compromising Splunk does not simply compromise one host — it compromises the visibility platform your SOC uses to detect intrusions. This makes the blast radius far larger than a typical privilege escalation. The pattern is not new. Splunk has patched at least two similar capability bypasses in the past five years (CVE-2022-43571 among them), suggesting the root assumption — that authenticated users at the API layer are authorized callers — persists across product generations. The transforms endpoints likely predate Splunk's current security model; they were built when Splunk was an internal search engine, not a security-critical monitoring platform. As the threat model expanded, these legacy endpoints were never audited against the capability framework bolted onto the UI layer. For defenders, the priority is immediate: verify whether your Splunk deployment permits non-admin users to create or modify scripted lookups through the transforms endpoints. If it does, treat any user with Splunk authentication as equivalent to admin-level access until patched. Review your Splunk service account privileges — if it runs as a domain admin or equivalent, this vulnerability provides a direct path to domain compromise. Splunk's hardening documentation includes run-as configuration guidance and least-privilege service account recommendations, but these are frequently unimplemented in production deployments due to operational friction. The compensating controls exist; the gap is deployment reality, not documentation. The broader question is whether other transforms configuration endpoints share this capability bypass. Splunk's configuration API surface is vast and includes legacy code layers that may never have been reviewed against the current security model. This CVE may represent the exposed edge of a larger forgotten attack surface.

Reviewed through automated stages and approved by a human before publication.