CVE-2026-76262 in Splunk
Summary
by MITRE • 08/20/2026
In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could read Prometheus service metrics from the Edge Processor SPL2 Preview sidecar, including service details that expose relevant runtime and build metadata for the sidecar. The vulnerability does not affect Splunk Enterprise versions below 10.4. The information disclosure is possible because the Prometheus metrics endpoint in the Edge Processor SPL2 Preview sidecar lacks authentication, which lets any client that can reach the sidecar retrieve the metrics without credentials. For more information see About Splunk sidecars (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/splunk-sidecars/about-splunk-sidecars) in the Splunk documentation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk Enterprise versions prior to 10.4.2 represents a critical information disclosure flaw within the Edge Processor SPL2 Preview sidecar component. This security issue specifically impacts deployments running version 10.4 but does not affect earlier major releases of the software. The core technical deficiency lies in the configuration and implementation of the Prometheus metrics endpoint associated with the Sidecar service. By design, this endpoint is intended to expose operational telemetry data for monitoring purposes via standard Prometheus scraping mechanisms. However, the implementation fails to enforce any form of authentication or access control checks on requests directed at this specific interface. Consequently, the security boundary that should restrict access to sensitive internal metrics is effectively non-existent for network-reachable clients.
An unauthenticated attacker who has network connectivity to the affected Splunk instance can interact directly with the Prometheus metrics endpoint without providing valid credentials. This lack of authentication allows any external entity capable of reaching the sidecar's listening port to retrieve a comprehensive dump of service metrics. The data exposed includes detailed runtime information and build metadata specific to the SPL2 Preview sidecar. While this may appear as benign operational telemetry, it provides adversaries with valuable intelligence regarding the internal architecture, versioning details, and potentially other configuration specifics that can be leveraged for further reconnaissance or targeted exploitation against the broader Splunk infrastructure.
The operational impact of this vulnerability is primarily centered on information disclosure rather than immediate remote code execution or data exfiltration from the main database. However, in security operations, such metadata exposure significantly lowers the barrier for subsequent attacks. Knowledge of specific build versions and runtime configurations allows threat actors to identify known vulnerabilities associated with that exact software state. It also aids in mapping the internal network topology and understanding how Splunk components are deployed within an organization's environment. This aligns with common attack patterns where initial access is followed by detailed system enumeration to plan lateral movement or privilege escalation strategies.
From a classification perspective, this vulnerability corresponds directly to CWE-200: Information Exposure, as it involves the unintended leakage of sensitive information through exposed endpoints. Furthermore, in terms of offensive security frameworks such as MITRE ATT&CK, this behavior is indicative of T1592: Gather Victim Host Information and potentially T1608: Stage Capabilities if the gathered data facilitates further payload deployment or configuration manipulation. The failure to implement authentication on a service endpoint that exposes internal system details represents a fundamental deviation from secure coding practices regarding API security and service isolation.
To mitigate this risk, organizations running Splunk Enterprise 10.4 must upgrade immediately to version 10.4.2 or later, where the authentication requirements for the Prometheus metrics endpoint have been enforced by default. For environments that cannot yet patch due to operational constraints, temporary mitigations should be implemented at the network perimeter level. This includes configuring firewalls or access control lists to restrict inbound traffic to the sidecar's metrics port exclusively from trusted monitoring systems such as internal Prometheus servers or Splunk Observability Cloud instances. Additionally, ensuring that these ports are not exposed to untrusted networks or the public internet is essential to prevent unauthorized scraping of sensitive runtime metadata until a permanent software fix can be applied.