CVE Vulnerability Catalog

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user with edit_spl2_module_permissions capability could use the REST API to access permission grants for SPL2 modules they are not allowed to view. The vulnerability is due to missing verification of user's read access to the app before returning module permissions.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user with edit_user capability could create a native Splunk username ending with a period. Username validation does not reject a trailing period, causing distinct usernames to share per-user configuration data and user-management operations to affect the wrong account or fail.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user without admin or power roles could retrieve original source code for the Discover Splunk Observability Cloud app through Splunk Web. The vulnerability is due to embedded source maps in production JavaScript bundles.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user without admin or power roles could access search query text and job metadata for jobs belonging to other users via a REST API. The vulnerability is due to incomplete per-user authorization enforcement in search job listings.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user with read_o11y_content capability could redirect an outbound request from Splunk App for Splunk Observability Cloud through the REST API to an attacker-controlled host and disclose the configured Observability Cloud API token. The vulnerability is due to incomplete validation of the outbound request destination.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user with run_collect capability could use the collect SPL command to add attacker-controlled content to system-level messages. The vulnerability is due to lack of index name validation before processing the value.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, a user without admin or power roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is due to lack of authorization verification for signature requests.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user without admin or power roles could cause a denial of service against a REST API endpoint in the Discover Splunk Observability Cloud app. The vulnerability is due to an inefficient regular expression used for input validation.

In Splunk Enterprise versions below 10.4.3, a user with a role having the list_spl2_modules capability could use SQL injection in SPL2 module filtering to access all relevant data available through the REST API, including private SPL2 module definitions belonging to other users. The vulnerability exists because Splunk does not parameterize user-supplied values before using them in database queries for SPL2 module filtering.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user without the admin or power roles could use a user-controlled job identifier to access substantially all search job information from jobs belonging to other users, including search query text, job metadata, results, and preview results, through a REST API. The vulnerability is due to incomplete validation of job ownership before returning search job information.

Vulnerability in Splunk Enterprise before versions 10.4.3 and 10.2.7 allows an unauthenticated user with network access to the Patroni REST API on a search head cluster member to execute attacker-controlled OS commands. The interface does not require authentication for critical configuration operations.

In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user with the read_o11y_content capability could inject forged entries into the app log through the REST API. The vulnerability exists because the Splunk App for Splunk O11y Cloud does not neutralize user-supplied SignalFlow content before writing it to the app log.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 on Linux, a local user who can run commands as the user account running Splunk Enterprise could cause an affected Linux package upgrade to run attacker-controlled operating-system commands with root privileges. The vulnerability is possible because the Linux package maintainer script trusts existing Splunk Enterprise installation content when it performs upgrade operations with root privileges. The vulnerability requires an affected Linux package upgrade to occur after the local user modifies the installation.

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, a user without the admin or power roles could access privileged Splunk Secure Gateway functionality. With this access, the user could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is due to multiple REST API endpoints not enforcing authorization requirements before processing requests.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.10, and 9.4.15, a user without the admin or power roles could create or edit scripted lookup definitions through raw configuration endpoints. The vulnerability is due to raw transforms configuration write paths not applying external lookup capability checks before saving scripted lookup settings.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 11.7 before 18.8.9, 18.9 before 18.9.5, and 18.10 before 18.10.3 that when importing CSV files could have allowed an authenticated user to cause denial of service to Sidekiq workers due to improper validation of CSV file structure.

In OpenStack Zaqar before 23.0.1, the WebSocket transport fails to bind the project identifier in subsequent requests to the project authenticated by the Keystone token. An authenticated user with a valid token for one project may substitute another project's UUID to enumerate, inspect, create, or delete queues belonging to that project, resulting in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected.

Missing authorization checks in Amazon Athena engine version 3 request handling could have allowed an authenticated user to read limited query metadata (AWS account identifiers and SQL statement text) from other AWS accounts. Query results, credentials, and Amazon S3 data were not affected. AWS remediated the issue on September 1, 2026, and has confirmed no customer metadata was accessed. No customer action is required.

The AsyncHttpClient (AHC) library from 2.16.0 until 3.0.14 has incomplete validation of cookie Domain attributes in ThreadSafeCookieStore. Missing private-section and default public-suffix rules, absent A-label normalization, locale-sensitive lowercasing, public-suffix host-only handling, and numeric or IP host checks allow one origin to store a cookie later sent to another origin. Applications sharing one client across trust domains can therefore receive attacker-injected cookies and may be exposed to session fixation. This issue is fixed in version 3.0.14.

The AsyncHttpClient (AHC) library from 2.1.0 until 3.0.14 has an enabled-by-default cookie store that replaces a Cookie header explicitly supplied through setHeader or addHeader whenever the store contributes any cookie for the origin. In a shared client, stored cookies originating from one user can replace a different user's request cookie, causing the request to execute under the wrong session. This bypasses the earlier CVE-2024-53990 remediation, which covered cookies supplied through addCookie but not a directly supplied header. This issue is fixed in version 3.0.14.