| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could cause a denial of service against a Representational State Transfer (REST) API endpoint in the Discover Splunk Observability Cloud app. The vulnerability is possible because the app uses an inefficient regular expression to validate input submitted through the endpoint. For more information see 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), Splunk Observability Cloud previews (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.4/observability/splunk-observability-cloud-previews), and restmap.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/restmap.conf) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is possible because Splunk Secure Gateway does not verify that the user is authorized to request a signature. Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72 are also affected. 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. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user that holds a role with the run_collect capability could use the collect Search Processing Language (SPL) command to add attacker-controlled content to system-level messages on the Splunk platform instance. The vulnerability is possible because the collect command does not validate the index name before processing the value. For more information see collect (https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/10.4/search-commands/collect), 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 System endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.4/system-endpoints/system-endpoint-descriptions) in the Splunk documentation. |
| Deserialization of Untrusted Data vulnerability in Brainstorm Force SureCart surecart allows Object Injection.This issue affects SureCart: from n/a through 4.9.3. |
| Missing Authorization vulnerability in miniOrange WP OAuth Server miniorange-oauth-20-server allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP OAuth Server: from n/a through 6.4.0. |
| 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. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could access search query text and job metadata for jobs that belong to other users, including job identifiers, dispatch parameters, result counts, and execution metadata, through an Application Programming Interface (API) implemented as a Representational State Transfer (REST) API. The vulnerability is possible because the REST API does not fully enforce per-user authorization before it includes job information in search job listings. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could retrieve original source code for the Discover Splunk Observability Cloud app through Splunk Web. The vulnerability is possible because production JavaScript bundles for the app contain embedded source maps that include original source code. For more information see 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), Splunk Observability Cloud previews (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.4/observability/splunk-observability-cloud-previews), and Navigating Splunk Web (https://help.splunk.com/en/splunk-enterprise/search/search-tutorial/10.4/part-1-getting-started/navigating-splunk-web) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected. |
| In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user that holds a role with the edit_user capability could create a native Splunk username that ends with a period. The vulnerability is possible because username validation does not reject a trailing period before the username is used for a user directory. This can cause distinct native Splunk usernames to share per-user configuration data, and user-management operations can affect the wrong account or fail. For more information see Set up native Splunk authentication (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/use-the-native-splunk-platform-authentication-scheme/set-up-native-splunk-authentication) and 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. |
| A flaw was found in curl. A remote malicious server can cause a Denial of Service (DoS) or memory corruption in applications that enable File Transfer Protocol (FTP) wildcard matching. When a wildcard listing operation fails, curl does not properly reset its internal callback handlers before the connection handle is reused or duplicated. An application that subsequently reuses or clones this corrupted handle may experience an immediate application crash or unsafe memory access. |
| A flaw was found in curl. A malicious or compromised HTTP proxy server can trick curl into sending authentication credentials intended for the target destination server directly to the proxy itself. When establishing a connection tunnel, if the proxy replies with an HTTP 401 Unauthorized status code instead of a proxy authentication challenge, curl mishandles the response and transmits the origin server's credentials. This issue leads to information disclosure, allowing an untrusted proxy to intercept sensitive passwords and authentication tokens. |
| A flaw was found in curl. When connection pooling is used with forced local interface binding options, curl fails to include the source interface configuration in its connection reuse cache. An attacker able to initiate network requests in an application using pooled connections can cause subsequent transfers to inadvertently reuse an existing connection. This behavior causes outbound network traffic to be transmitted through the wrong source address, potentially routing requests through an unintended network interface. |
| A flaw was found in curl. When processing an HTTP redirect to an address containing user credentials, curl improperly retains and retransmits authentication state. A malicious server can exploit this behavior by redirecting curl to an untrusted destination, forcing the client to transmit sensitive authentication tokens, such as Kerberos tickets, to the third party. This flaw can lead to unauthorized information disclosure of user credentials across domain boundaries. |
| A flaw was found in curl. An attacker could supply deeply nested Multipurpose Internet Mail Extensions (MIME) structures to an application utilizing the libcurl library. During memory cleanup in the curl_mime_free function, excessive recursive calls exhaust available stack memory, leading to an application crash and a Denial of Service (DoS). |
| A flaw was found in curl. When handling Trivial File Transfer Protocol (TFTP) transfers, a malicious server can trigger information disclosure by responding to a download request in a way that forces the client into transmit mode. Consequently, the client may unintentionally send leftover sensitive data from prior operations on a reused connection handle to the attacker's server. |
| A flaw was found in curl. When importing HTTP Strict Transport Security (HSTS) cache records, loading a parent domain entry configured to include subdomains before a longer-lived subdomain entry silently drops the subdomain policy. Consequently, once the parent policy expires, curl fails to upgrade subsequent connections for the subdomain to HTTPS and transmits unencrypted requests, allowing a network attacker to intercept sensitive data. |
| A flaw was found in curl. When libcurl is built with the libssh2 backend and uses a hashed known-hosts file, host key verification can mistakenly report a key mismatch as a missing key to custom verification callbacks. A remote attacker who intercepts or controls the Secure Shell (SSH) connection can exploit this flaw to make a previously pinned server appear as a new host. As a result, the application may inadvertently authenticate to an untrusted server, leading to credential exposure and the receipt of malicious data. |
| A flaw was found in curl. When ambient user credentials—where authentication is handled implicitly without providing a username—are used, curl may improperly reuse an existing connection authenticated via Negotiate for a different server origin. This improper connection reuse can cause requests intended for one server to be transmitted over an established connection to another, potentially resulting in information disclosure. |
| A flaw was found in curl. In builds configured with the Microsoft Schannel Transport Layer Security (TLS) backend, libcurl's connection cache fails to evaluate client certificate authentication settings when handling HTTP redirects. A malicious server can redirect a transfer to a different destination, causing curl to inappropriately reuse an already authenticated connection. This issue can result in information disclosure by exposing client certificates and credentials to unintended origins. |
| A flaw was found in curl. When curl is configured to follow HTTP redirects while performing Negotiate authentication using system-provided Kerberos credentials, it may forward authentication details to an unrelated destination. A malicious server can exploit this flaw by redirecting the client to a target URL containing embedded user credentials, resulting in information disclosure of sensitive authentication data. |
