CVE-2026-76274 in Splunk
Summary
by MITRE • 10/07/2026
In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user that holds a role with the read_o11y_content capability could redirect an outbound request from Splunk App for Splunk Observability Cloud through the Representational State Transfer (REST) API to an attacker-controlled host and disclose the configured Observability Cloud Application Programming Interface (API) token. The vulnerability is possible because Splunk App for Splunk Observability Cloud does not fully validate the destination of an outbound request. For more information see Authentication tokens (https://help.splunk.com/en/splunk-observability-cloud/administer/authentication-and-security/authentication-tokens) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
A critical security vulnerability has been identified within specific legacy releases of Splunk Enterprise, specifically those preceding version 10.4.3, 10.2.7, and 10.0.10. This flaw resides in the integration component known as the Splunk App for Splunk Observability Cloud and involves a failure to properly validate outbound network requests initiated through the Representational State Transfer API. The vulnerability allows an authenticated user possessing the read_o11y_content capability to manipulate the destination of these outbound calls, effectively redirecting them toward infrastructure controlled by an attacker rather than the intended legitimate endpoints. This misconfiguration in request handling creates a pathway for sensitive credential exfiltration without requiring elevated privileges or complex exploitation techniques beyond basic API interaction capabilities granted to standard monitoring roles.
The technical root cause is classified as an improper validation of outbound requests, which aligns with CWE-918, specifically addressing Server-Side Request Forgery (SSRF) mechanisms where the application acts as a proxy for user-supplied input without adequate sanitization or allow-listing of destination hosts. When a user invokes specific API endpoints associated with observability data retrieval, the underlying service constructs an outbound HTTP request to communicate with Splunk Observability Cloud servers. Due to insufficient validation logic within this process, the system accepts arbitrary hostnames and IP addresses provided in the request parameters. By supplying a maliciously crafted URL pointing to an attacker-controlled server, the application blindly forwards the entire payload of the original request, which includes authentication headers containing sensitive API tokens intended for internal service-to-service communication or user-specific access credentials.
The operational impact of this vulnerability is severe due to the high value of the disclosed data. The primary consequence is the unauthorized disclosure of configured Observability Cloud Application Programming Interface tokens. These tokens serve as long-lived secrets that grant extensive permissions within the Splunk Observability Cloud environment, including the ability to ingest metrics, view logs, and access other telemetry data associated with the organization's infrastructure. An attacker who successfully exploits this flaw can capture these tokens via their controlled server, thereby gaining persistent unauthorized access to critical observability platforms. This compromise undermines the confidentiality of operational intelligence and could serve as a stepping stone for further lateral movement or deeper infiltration into cloud-native environments that rely on Splunk for monitoring and security analytics.
From an adversarial perspective, this exploitation technique maps directly to MITRE ATT&CK techniques related to Collection via Remote Services and Credential Access through API keys. The attacker leverages the trusted relationship between the on-premises Splunk instance and the cloud service to bypass perimeter defenses that might otherwise block direct external access attempts. Since the request originates from a legitimate, whitelisted internal server, network security controls such as firewalls or intrusion detection systems may not flag the traffic as malicious until after the data has been exfiltrated. This highlights the risk of SSRF vulnerabilities in enterprise applications that act as intermediaries for sensitive cloud services, where trust boundaries are often assumed rather than strictly enforced through rigorous input validation and output encoding practices.
To mitigate this vulnerability, organizations running affected versions must prioritize immediate patching to one of the fixed releases: Splunk Enterprise 10.4.3, 10.2.7, or 10.0.10. These updates contain code changes that enforce strict validation on outbound request destinations, ensuring that only authorized and expected endpoints are accessible through the API interface. For environments where immediate patching is not feasible due to operational constraints, temporary mitigations should include restricting network egress policies for Splunk servers to allow traffic only to known legitimate observability cloud domains. Additionally, administrators should audit user roles to ensure that the read_o11y_content capability is granted only to users with a strict need-to-know basis, thereby reducing the attack surface available to potential insiders or compromised accounts. Regular rotation of API tokens remains a critical defense-in-depth measure, limiting the window of opportunity for attackers who may have previously exfiltrated credentials through this vector.