Splunk

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.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could read Spacebridge asymmetric private keys, which are secrets that compromise affected Spacebridge private-key material stored in the app collection, through the Splunk Secure Gateway App Key Value Store Representational State Transfer (REST) API. The vulnerability is possible on instances upgraded from older Splunk Secure Gateway deployments when the private-key migration remains incomplete, leaving key material in a collection with an insecure default access control list.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the rest_properties_get capability could read encrypted stored credentials through the Representational State Transfer (REST) API. Successful exploitation can expose relevant data protected by the stored credentials. The incorrect permission assignment is possible because the properties REST endpoint requires the rest_properties_get capability instead of the list_storage_passwords capability to read stored credentials. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.Show less

In Splunk Enterprise for Windows versions below 10.4.2, 10.2.6, 10.0.9, 9.4.13, and 9.3.14, a local user with access to the Windows host could bind to the management port before Splunk Enterprise starts, intercept authentication tokens from child processes, and use those tokens to compromise all relevant data and system integrity available to the user account running Splunk Enterprise. The vulnerability is possible because the Windows management-port listener does not apply exclusive address binding protections before the service starts.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.10, 3.9.24, and 3.8.71, a user who does not hold the "admin" or "power" Splunk roles could register an arbitrary companion app and cause Splunk Secure Gateway to forward mobile user requests, including tokens that compromise all relevant data available to the affected mobile user, to an attacker-controlled Uniform Resource Locator (URL). The vulnerability is possible because a hard-coded cryptographic key in the Splunk Secure Gateway companion app registration handler allows for arbitrary callback URL registration without restriction. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.10, 3.9.24, and 3.8.71, a user who holds a Splunk role with permissions to list storage passwords but does not hold Splunk Secure Gateway administration privileges could access Mobile Device Management signing secrets that compromise all affected mobile-device enrollment trust through Splunk Secure Gateway. The vulnerability is possible because Splunk Secure Gateway Representational State Transfer (REST) API endpoints for deployment bundle, Security Assertion Markup Language setup, and companion app workflows do not require Splunk Secure Gateway administration privileges before processing requests.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could read sensitive Security Assertion Markup Language setup and instance settings information through Splunk Secure Gateway Representational State Transfer (REST) API endpoints. The vulnerability is possible because the affected Security Assertion Markup Language setup and instance settings REST API endpoints do not enforce authorization requirements before returning configuration information.Show less

In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user who does not hold the "admin" or "power" Splunk roles could trick another user into running arbitrary Search Processing Language (SPL) commands through the Data Model Editor using the permissions of the affected user. The commands could access all relevant data available to the affected user and affect system integrity. The vulnerability is possible because Splunk Web does not apply SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, 9.4.14, and 9.3.14, an unauthenticated user could cause another user to dispatch arbitrary Search Processing Language (SPL) pipelines from Dataset Explorer with the same privileges as that user, which can allow for access to all relevant data and system integrity available to that user and affect system availability. The vulnerability is possible because Dataset Explorer does not validate or escape dataset names before building SPL searches and does not apply SPL safeguards for risky commands to those searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will. For more information see Explore a dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.4/manage-and-explore-datasets/explore-a-dataset) and SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) in the Splunk documentation.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could run arbitrary Search Processing Language (SPL) commands with the highest level of system privilege and read every credential stored in the credential store, which can allow for disclosure and modification of all relevant data and affect system integrity and availability. The vulnerability is possible because scheduled search alert action configuration does not properly restrict user-specific alert action settings before the search scheduler runs alert actions. For more information see Create scheduled alerts (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.3/create-alerts/create-scheduled-alerts), Set up alert actions (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.3/configure-alert-actions/set-up-alert-actions), Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities), and Configuration file precedence (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/administer-splunk-enterprise-with-configuration-files/configuration-file-precedence) in the Splunk documentation.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.13, an unauthenticated user who tricks another user into visiting a malicious web page could run unauthorized JavaScript in that user's browser. This could allow for unauthorized access to all relevant data available to that user and actions that affect system integrity. The Cross-Site Scripting (XSS) is possible because Splunk Web does not validate the origin and source of messages received by a page message handler. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, and 10.0.9, a user who does not hold the "admin" or "power" Splunk roles could cause the Splunk App for Splunk Observability Cloud to forward requests to Splunk Observability Cloud, including the Splunk Observability Cloud access token stored for the app. With this access, the user could view all relevant data available to that token and make limited changes to Splunk Observability Cloud content. The vulnerability does not affect Splunk Enterprise 9.4 and 9.3 versions. The vulnerability is possible because the app's Representational State Transfer (REST) API endpoint handlers do not enforce the read_o11y_content capability before forwarding requests with the stored access token. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.Show less

In Splunk AI Toolkit versions below 5.7.4, a user who holds the "admin" Splunk role could execute arbitrary OS commands on the host running the Splunk Enterprise instance. The vulnerability is possible because of an unsafe shell execution pattern in the btool configuration helper, which constructs OS command strings from dynamic parameters without disabling shell interpretation.Show less

In Splunk AI Toolkit versions below 5.7.4, a low-privileged user that does not hold the "admin" or "power" Splunk roles could cause the Splunk AI Toolkit to make outbound requests over HTTP to a server that an attacker controls, which could allow for data exfiltration. The vulnerability exists because of an insecure default domain allowlist in the Splunk AI Toolkit, which does not restrict outbound AI agent requests to approved external domains.Show less

In Splunk Enterprise versions below 10.2.4 and 10.0.7, and Splunk Cloud Platform versions below 10.4.2604.0, 10.3.2512.12, 10.2.2510.15, 10.1.2507.23, 10.0.2503.14, and 9.3.2411.131, a user who holds a Splunk role that contains the high-privilege capability `edit_saved_search_owner` could reassign saved search ownership to users outside their authorized scope. The ownership reassignment endpoint lacks access control.Show less

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could store a malicious script in a classic dashboard HTML panel, causing unauthorized JavaScript code to execute in the browser of another user. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.Show less

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a classic dashboard that exfiltrates sensitive data from the browser of a higher-privileged user who views it. The exfiltration is possible because classic dashboard panels do not fully validate style attribute values, which can allow for requests to reach external domains outside the configured Trusted Domains List. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.Show less

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could cause data exfiltration through classic dashboards by redirecting a victim to an external site using a protocol-relative URL in a drill-down link.<br><br>The vulnerability exists because the URL classifier in classic dashboards only recognizes `http://` and `https://` schemes when checking for external URLs. Protocol-relative URLs such as `//attacker.com` bypass this check entirely, and Splunk Web does not show the external-navigation warning dialog to the victim.Show less

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious classic dashboard that exfiltrates sensitive data to an external server. The vulnerability exists because URL validation on the external content dialog is incomplete, which can allow for requests to untrusted domains when a user interacts with a crafted dashboard.Show less

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious classic dashboard that exfiltrates sensitive data to an external server when a higher-privileged user views it, bypassing the external content restriction through a Cascading Style Sheets (CSS) injection.<br><br>The Trusted Domains security check does not fully validate inline style attribute values, which can allow for outbound requests to untrusted domains and credential exfiltration when a victim views a crafted dashboard.Show less