In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.9, and 9.3.10, and Splunk Cloud Platform versions below 10.2.2510.5, 10.1.2507.16, 10.0.2503.11, and 9.3.2411.123, a low-privileged user that does not hold the "admin" or "power" Splunk roles could access the `/splunkd/__raw/servicesNS/-/-/configs/conf-passwords` REST API endpoint, which exposes the hashed or plaintext password values that are stored in the passwords.conf configuration file due to improper access control. This vulnerability could allow for the unauthorized disclosure of sensitive credentials.

In Splunk Enterprise versions below 9.3.1, and 9.2.0 versions below 9.2.3, and Splunk Cloud Platform versions below 9.2.2403.103, 9.1.2312.200, 9.1.2312.110 and 9.1.2308.208, a low-privileged user that does not hold the "admin" or "power" Splunk roles could run a search as the "nobody" Splunk user in the SplunkDeploymentServerConfig app. This could let the low-privileged user access potentially restricted data.

In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the `admin` or `power` Splunk roles, has write permission on the app, and does not hold the high-privilege capability `accelerate_datamodel`, could turn on or off Data Model Acceleration due to improper access control.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200, an authenticated, low-privileged user who does not hold the admin or power Splunk roles could upload a file with an arbitrary extension using the indexing/preview REST endpoint.

On Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, an unauthorized user can access the {{/services/indexing/preview}} REST endpoint to overwrite search results if they know the search ID (SID) of an existing search job.

In Splunk Enterprise versions below 10.2.1, 10.0.4, 9.4.9, and 9.3.10, and Splunk Cloud Platform versions below 10.2.2510.7, 10.1.2507.17, 10.0.2503.12, and 9.3.2411.124, a low-privileged user that does not hold the "admin" or "power" Splunk roles could retrieve sensitive information by inspecting the job's search log due to improper access control in the MongoClient logging channel.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table upload feature let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now be one of the following only: .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gzl.

In Splunk Enterprise versions below 8.1.13 and 8.2.10, the ‘createrss’ external search command overwrites existing Resource Description Format Site Summary (RSS) feeds without verifying permissions. This feature has been deprecated and disabled by default.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘sendemail’ REST API endpoint lets any authenticated user send an email as the Splunk instance. The endpoint is now restricted to the ‘splunk-system-user’ account on the local instance.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200, a low-privileged user that does not hold the admin or power Splunk roles could create notifications in Splunk Web Bulletin Messages that all users on the instance receive.

In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See [Define alert suppression groups to throttle sets of similar alerts](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/manage-alert-trigger-conditions-and-throttling/define-alert-suppression-groups-to-throttle-sets-of-similar-alerts).

In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could turn off the scheduled search `Bucket Copy Trigger` within the Splunk Archiver application. This is because of missing access controls in the saved searches for this app.

In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.111, 9.3.2408.119, and 9.2.2406.122, a low-privileged user that does not hold the admin or power Splunk roles could access sensitive search results if Splunk Enterprise runs an administrative search job in the background. If the low privileged user guesses the search job’s unique Search ID (SID), the user could retrieve the results of that job, potentially exposing sensitive search results. For more information see https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/about-jobs-and-job-management and https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/manage-search-jobs.

In Splunk Universal Forwarder for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.

In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could edit and delete other user data in App Key Value Store (KVStore) collections that the Splunk Secure Gateway app created. This is due to missing access control and incorrect ownership of the data in those KVStore collections.<br><br>In the affected versions, the `nobody` user owned the data in the KVStore collections. This meant that there was no specific owner assigned to the data in those collections.

In Splunk Enterprise for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Splunk Enterprise for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, an authenticated user can perform an extensible markup language (XML) external entity (XXE) injection via a custom View. The XXE injection causes Splunk Web to embed incorrect documents into an error.

In Splunk Enterprise versions in the following table, an authenticated user can craft a dashboard that could potentially leak information (for example, username, email, and real name) about Splunk users, when visited by another user through the drilldown component. The vulnerability requires user access to create and share dashboards using Splunk Web.

An information disclosure vulnerability exists in curl 7.65.0 to 7.82.0 are vulnerable that by using an IPv6 address that was in the connection pool but with a different zone id it could reuse a connection instead.

In Splunk Enterprise versions below 9.3.0, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.1.2312.206, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles, that has a username with the same name as a role with read access to dashboards, could see the dashboard name and the dashboard XML by cloning the dashboard.

In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.2.2406.107, 9.2.2403.109, and 9.1.2312.206, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could run a saved search with a risky command using the permissions of a higher-privileged user to bypass the SPL safeguards for risky commands on “/en-US/app/search/report“ endpoint through “s“ parameter.<br>The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.

In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and below 3.9.10, 3.8.58, and 3.7.28 of Splunk Secure Gateway app in Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles and subscribes to mobile push notifications could receive notifications that disclose the title and description of the report or alert even if they do not have access to view the report or alert.

In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.5, 9.3.7, and 9.2.9, and Splunk Cloud Platform versions below 10.1.2507.0, 10.0.2503.9, 9.3.2411.112, and 9.3.2408.122, a low-privileged user who does not hold the "admin" or "power" Splunk roles could bypass the SPL safeguards for risky commands when they create a Data Model that contains an injected SPL query within an object. They can bypass the safeguards by exploiting a path traversal vulnerability.

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6, the software potentially exposes sensitive HTTP parameters to the `_internal` index. This exposure could happen if you configure the Splunk Enterprise `REST_Calls` log channel at the DEBUG logging level.

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6, the software potentially exposes plaintext passwords for local native authentication Splunk users. This exposure could happen when you configure the Splunk Enterprise AdminManager log channel at the DEBUG logging level.

In Splunk Enterprise versions below 10.2.1 and 10.0.4, and Splunk Cloud Platform versions below 10.2.2510.5, 10.1.2507.16, and 10.0.2503.12, a low-privileged user that does not hold the "admin" or "power" Splunk roles could retrieve the Observability Cloud API access token through the Discover Splunk Observability Cloud app due to improper access control. This vulnerability does not affect Splunk Enterprise versions below 9.4.9 and 9.3.10 because the Discover Splunk Observability Cloud app does not come with Splunk Enterprise.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, an authenticated user could run risky commands using the permissions of a higher-privileged user to bypass SPL safeguards for risky commands in the Analytics Workspace. The vulnerability requires the authenticated user to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.

In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can perform an unauthorized transfer of data from a search using the ‘copyresults’ command if they know the search ID (SID) of a search job that has recently run.

In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and versions below 3.2.462, 3.7.18, and 3.8.5 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could see alert search query responses using Splunk Secure Gateway App Key Value Store (KVstore) collections endpoints due to improper access control.

CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. A local authenticated malicious user with access to the CF CLI config file can act as that client, who is the owner of the leaked credentials.

In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, and 9.2.9 and Splunk Cloud Platform versions below 9.3.2411.116, 9.3.2408.124, 10.0.2503.5 and 10.1.2507.1, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could run a saved search with a risky command using the permissions of a higher-privileged user to bypass the SPL safeguards for risky commands. They could bypass these safeguards on the “/services/streams/search“ endpoint through its “q“ parameter by circumventing endpoint restrictions using character encoding in the REST path. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.

In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.113, and 9.2.2406.119, the software potentially exposes the search head cluster [splunk.secret](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) key. This exposure could happen if you have a Search Head cluster and you configure the Splunk Enterprise `SHCConfig` log channel at the DEBUG logging level in the clustered deployment. <br><br>The vulnerability would require either local access to the log files or administrative access to internal indexes, which by default only the admin role receives. Review roles and capabilities on your instance and restrict internal index access to administrator-level roles. <br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities), [Deploy a search head cluster](https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/deploy-search-head-clustering/deploy-a-search-head-cluster), [Deploy secure passwords across multiple servers](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) and [Set a security key for the search head cluster](https://help.splunk.com/splunk-enterprise/administer/distributed-search/9.4/configure-search-head-clustering/set-a-security-key-for-the-search-head-cluster#id_2c54937a_736c_47b5_9485_67e9e390acfa__Set_a_security_key_for_the_search_head_cluster) for more information.

In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.103, 9.2.2406.108, 9.2.2403.113, 9.1.2312.208 and 9.1.2308.212, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could run a saved search with a risky command using the permissions of a higher-privileged user to bypass the SPL safeguards for risky commands on the “/app/search/search“ endpoint through its “s“ parameter. <br>The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.

curl supports the `-t` command line option, known as `CURLOPT_TELNETOPTIONS`in libcurl. This rarely used option is used to send variable=content pairs toTELNET servers.Due to flaw in the option parser for sending `NEW_ENV` variables, libcurlcould be made to pass on uninitialized data from a stack based buffer to theserver. Therefore potentially revealing sensitive internal information to theserver using a clear-text network protocol.This could happen because curl did not call and use sscanf() correctly whenparsing the string provided by the application.

curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.

curl 7.7 through 7.76.1 suffers from an information disclosure when the `-t` command line option, known as `CURLOPT_TELNETOPTIONS` in libcurl, is used to send variable=content pairs to TELNET servers. Due to a flaw in the option parser for sending NEW_ENV variables, libcurl could be made to pass on uninitialized data from a stack based buffer to the server, resulting in potentially revealing sensitive internal information to the server using a clear-text network protocol.

In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.107, 9.2.2406.111, and 9.1.2308.214, a low-privileged user that does not hold the "admin" or "power" Splunk roles could run a saved search with a risky command using the permissions of a higher-privileged user to bypass the SPL safeguards for risky commands on the "/services/streams/search" endpoint through its "q" parameter. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.

curl 7.62.0 through 7.70.0 is vulnerable to an information disclosure vulnerability that can lead to a partial password being leaked over the network and to the DNS server(s).

When handling a mismatched pre-authentication cookie, the application leaks the internal error message in the response, which contains the Splunk Enterprise local system path. The vulnerability impacts Splunk Enterprise versions before 8.1.0.

Splunk through 7.0.1 allows information disclosure by appending __raw/services/server/info/server-info?output_mode=json to a query, as demonstrated by discovering a license key.

Splunk Enterprise 5.0.x before 5.0.18, 6.0.x before 6.0.14, 6.1.x before 6.1.13, 6.2.x before 6.2.13.1, 6.3.x before 6.3.10, 6.4.x before 6.4.6, and 6.5.x before 6.5.3 and Splunk Light before 6.5.2 assigns the $C JS property to the global Window namespace, which might allow remote attackers to obtain sensitive logged-in username and version-related information via a crafted webpage.

When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used 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. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST.

A malicious server can use the FTP PASV response to trick curl 7.73.0 and earlier into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions.

Apache Airflow, versions before 2.6.3, is affected by a vulnerability that allows an unauthorized actor to gain access to sensitive information in Connection edit view. This vulnerability is considered low since it requires someone with access to Connection resources specifically updating the connection to exploit it. Users should upgrade to version 2.6.3 or later which has removed the vulnerability.

The Under Construction / Maintenance Mode from Acurax plugin for WordPress is vulnerable to Sensitive Information Exposure in versions up to, and including, 2.6 via the 'acx_csma_subscribe_ajax' function. This can allow authenticated attackers to extract sensitive data such as names and email addresses of subscribed visitors.

Nextcould Talk android is a video and audio conferencing app for Nextcloud. Prior to versions 12.2.8, 13.0.10, 14.0.6, and 15.0.0, guests can continue to receive video streams from a call after being removed from a conversation. An attacker would be able to see videos on a call in a public conversation after being removed from that conversation, provided that they were removed while being in the call. Versions 12.2.8, 13.0.10, 14.0.6, and 15.0.0 contain patches for the issue. No known workarounds are available.

Exposure of Sensitive Information to an Unauthorized Actor, Exposure of private personal information to an unauthorized actor vulnerability in MeWare Software Development Inc. PDKS allows Excavation. This issue affects PDKS: from V16.20200313 before VMYR_3.5.2025117.

fhir-works-on-aws-authz-smart is an implementation of the authorization interface from the FHIR Works interface. Versions 3.1.1 and 3.1.2 are subject to Exposure of Sensitive Information to an Unauthorized Actor. This issue allows a client of the API to retrieve more information than the client’s OAuth scope permits when making “search-type” requests. This issue would not allow a client to retrieve information about individuals other than those the client was already authorized to access. Users of fhir-works-on-aws-authz-smart 3.1.1 or 3.1.2 should upgrade to version 3.1.3 or higher immediately. Versions 3.1.0 and below are unaffected. There is no workaround for this issue.

titra is an open source time tracking project. In version 0.99.52, the globalsettings Meteor publication returns all global settings without any admin or role check. Any authenticated user can subscribe via DDP and receive sensitive configuration fields such as google_secret, openai_apikey, and google_clientid. At time of publication no public patch is available.

In GolfBuddy Course Manager 1.1, passwords are sent (with base64 encoding) via a GET request.