Splunk Web in Splunk Enterprise 7.0.x before 7.0.0.1, 6.6.x before 6.6.3.2, 6.5.x before 6.5.6, 6.4.x before 6.4.9, and 6.3.x before 6.3.12, when the SAML authType is enabled, mishandles SAML, which allows remote attackers to bypass intended access restrictions or conduct impersonation attacks.

Splunk Web in Splunk Enterprise 5.0.x before 5.0.17, 6.0.x before 6.0.13, 6.1.x before 6.1.12, 6.2.x before 6.2.12, 6.3.x before 6.3.8, and 6.4.x before 6.4.4 allows remote attackers to conduct HTTP request injection attacks and obtain sensitive REST API authentication-token information via unspecified vectors, aka SPL-128840.

Splunk Enterprise deployment servers in versions before 8.1.10.1, 8.2.6.1, and 9.0 let clients deploy forwarder bundles to other deployment clients through the deployment server. An attacker that compromised a Universal Forwarder endpoint could use the vulnerability to execute arbitrary code on all other Universal Forwarder endpoints subscribed to the deployment server.

In Splunk App for Stream versions below 8.1.1, a low-privileged user could use a vulnerability in the streamfwd process within the Splunk App for Stream to escalate their privileges on the machine that runs the Splunk Enterprise instance, up to and including the root user.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code.

In Splunk Enterprise 10.2 versions below 10.2.4 and 10 versions below 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials. Splunk Enterprise versions 9.4 and earlier are not affected. If you cannot immediately upgrade to a fixed version, you can mitigate this vulnerability by disabling the PostgreSQL sidecar service.

In libarchive 3.6.1, the software does not check for an error after calling calloc function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference or, in some cases, even arbitrary code execution.

Upstream patch: https://github.com/libarchive/libarchive/commit/fd180c36036df7181a64931264732a10ad8cd024

A vulnerability was found in lz4, where a potential memory corruption due to an integer overflow bug which caused one of the memmove arguments to become negative. Depending on how the library was compiled this will hit an assert() inside the library and dump core, leaving a 4GB core file, or it wil go into libc and crash inside the memmove() function.

Reference: https://github.com/lz4/lz4/pull/972

A vulnerability was found in curl. The issue occurs when doing HTTP(S) transfers, where curl might erroneously use the read callback (CURLOPTREADFUNCTION) to ask for data to send, even when the CURLOPTPOSTFIELDS option has been set if it previously used the same handle to issue a PUT request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent POST request.

A vulnerability was found in curl. This issue occurs because when curl saves cookies, alt-svc, and HSTS data to local files, it makes the operation atomic by finalizing the process with a rename from a temporary name to the final target file name. This flaw leads to unpreserved file permissions, either by mistake or by a malicious actor.

A vulnerability in input validation exists in curl <8.0 during communication using the TELNET protocol may allow an attacker to pass on maliciously crafted user name and "telnet options" during server negotiation. The lack of proper input scrubbing allows an attacker to send content or perform option negotiation without the application's intent. This vulnerability could be exploited if an application allows user input thereby enabling attackers to execute arbitrary code on the system.

When using Ingest Actions to configure a destination that resides on Amazon Simple Storage Service (S3) in Splunk Web, TLS certificate validation is not correctly performed and tested for the destination. The vulnerability only affects connections between Splunk Enterprise and an Ingest Actions Destination through Splunk Web and only applies to environments that have configured TLS certificate validation. It does not apply to Destinations configured directly in the outputs.conf configuration file. The vulnerability affects Splunk Enterprise version 9.0.0 and does not affect versions below 9.0.0, including the 8.1.x and 8.2.x versions.

In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who can read the Hypertext Markup Language (HTML) source of a page that embeds a Splunk report could use exposed session material to access all relevant data and affect system integrity. The vulnerability is possible because the dispatch archive download path does not correctly enforce the embedded-report authorization boundary and includes sensitive session material in archived search-job data. For more information see Additional configuration for embedded reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/10.4/report-management/additional-configuration-for-embedded-reports) and Embed scheduled reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/10.4/report-management/embed-scheduled-reports) in the Splunk documentation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the associated search job dispatch archive, recover session material, and use it to access all relevant data available to the report owner and affect system integrity, including by performing administrative actions when the owner holds the "admin" Splunk role. The vulnerability is possible because embedded report access does not block Representational State Transfer (REST) API dispatch archive download requests. For more information see Additional configuration for embedded reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.1/report-management/additional-configuration-for-embedded-reports) and About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the dispatch archive for an embedded report search job and use exposed session material to access all relevant data and affect system integrity on the Splunk platform instance. The vulnerability is possible because the embedded report authorization flow does not block dispatch archive download requests before Splunk Enterprise begins sending the archive to the requester. For more information see Additional configuration for embedded reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/10.4/report-management/additional-configuration-for-embedded-reports) and Embed scheduled reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/10.4/report-management/embed-scheduled-reports) in the Splunk documentation.

Directory traversal vulnerability in the collect script in Splunk before 5.0.5 allows remote attackers to execute arbitrary commands via a .. (dot dot) in the file parameter. NOTE: this issue was SPLIT per ADT2 due to different vulnerability types. CVE-2013-7394 is for the issue in the "runshellscript echo.sh" script.

Splunk 4.2.5 and earlier, when a Free license is selected, enables potentially undesirable functionality within an environment that intentionally does not support authentication, which allows remote attackers to (1) read arbitrary files via a management-console session that leverages the ability to create crafted data sources, or (2) execute management commands via an HTTP request.

curl. Multiple issues were addressed by updating to curl version 7.79.1.

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.

In Splunk MCP Server app versions below 1.2.1, a user who holds the "admin" Splunk role could execute arbitrary commands on the underlying operating system. The vulnerability is possible because of missing input validation in the app's credential management component, which deserializes stored data without checking whether the content is of the expected type.

A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of usingan insecure clear-text HTTP step even when HTTP is provided in the URL. ThisHSTS mechanism would however surprisingly be ignored by subsequent transferswhen done on the same command line because the state would not be properlycarried on.

The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.

The "runshellscript echo.sh" script in Splunk before 5.0.5 allows remote authenticated users to execute arbitrary commands via a crafted string. NOTE: this issue was SPLIT from CVE-2013-6771 per ADT2 due to different vulnerability types.

In Splunk Enterprise versions earlier than 8.2.12, 9.0.6, and 9.1.1, a dynamic link library (DLL) that ships with Splunk Enterprise references an insecure path for the OPENSSLDIR build definition. An attacker can abuse this reference and subsequently install malicious code to achieve privilege escalation on the Windows machine.

In Splunk Enterprise versions below 8.2.12, 9.0.6, and 9.1.1, an attacker can create an external lookup that calls a legacy internal function. The attacker can use this internal function to insert code into the Splunk platform installation directory. From there, a user can execute arbitrary code on the Splunk platform Instance.

In Splunk Enterprise for Windows versions below 9.0.8 and 9.1.3, Splunk Enterprise does not correctly sanitize path input data. This results in the unsafe deserialization of untrusted data from a separate disk partition on the machine. This vulnerability only affects Splunk Enterprise for Windows.

In Splunk Add-on Builder versions below 4.1.4, the application writes user session tokens to its internal log files when you visit the Splunk Add-on Builder or when you build or edit a custom app or add-on.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109 and 9.1.2308.207, an authenticated user could create an external lookup that calls a legacy internal function. The authenticated user could use this internal function to insert code into the Splunk platform installation directory. From there, the user could execute arbitrary code on the Splunk platform Instance.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 on Windows, an authenticated user could execute a specially crafted query that they could then use to serialize untrusted data. The attacker could use the query to execute arbitrary code.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10, a low-privileged user that does not hold the admin or power Splunk roles could cause a Remote Code Execution through an external lookup that references the “splunkarchiver“ application.