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 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 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 AI Toolkit versions below 5.7.3, a low-privileged user that does not hold the 'admin' or 'power' roles could access confidential data that was restricted through `srchFilter` configurations on custom roles.<br><br>The app contains an `authorize.conf` configuration file with a `srchFilter` entry that modifies the built-in ‘user’ role. Because the Splunk platform combines inherited search filters with the `OR` SPL operator, the injected filter overrides more restrictive filters on child roles.

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 below 10.0.2, 10.0.3, 9.4.8, and 9.3.9, a low-privileged user who does not hold the "admin" Splunk role could access the Splunk Monitoring Console App endpoints due to an improper access control. This could lead to a sensitive information disclosure.<br><br>The Monitoring Console app is a bundled app that comes with Splunk Enterprise. It is not available for download on SplunkBase, and is not installed on Splunk Cloud Platform instances. This vulnerability does not affect [Cloud Monitoring Console](https://help.splunk.com/en/splunk-cloud-platform/administer/admin-manual/10.2.2510/monitor-your-splunk-cloud-platform-deployment/introduction-to-the-cloud-monitoring-console).

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 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.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 Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, and Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the the Splunk _internal index could view the Security Assertion Markup Language (SAML) configurations for Attribute query requests (AQRs) or Authentication extensions in plain text within the conf.log file, depending on which feature is configured.

In Splunk MCP Server app versions below 1.0.3 , a user who holds a role with access to the Splunk `_internal` index or possesses the high-privilege capability `mcp_tool_admin` could view users session and authorization tokens in clear text.<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. <br><br>Review roles and capabilities on your instance and restrict internal index access to administrator-level roles. See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities) and [Connecting to MCP Server and Admin settings](https://help.splunk.com/en/splunk-enterprise/mcp-server-for-splunk-platform/connecting-to-mcp-server-and-admin-settings) in the Splunk documentation for more information.

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.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 run a search using the permissions of a higher-privileged user that could lead to disclosure of sensitive information.<br><br>The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated low-privileged user should not be able to exploit the vulnerability at will.

In Splunk Add-on for Palo Alto Networks versions below 2.0.2, the add-on exposes client secrets in plain text in the _internal index during the addition of new “Data Security Accounts“. 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. See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities) in the Splunk documentation for more information.

In Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, the software potentially exposes authentication tokens during the token validation process. This exposure happens when either Splunk Enterprise runs in debug mode or the JsonWebToken component has been configured to log its activity at the DEBUG logging level.

In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the RSA `accessKey` value from the [<u>Authentication.conf</u> ](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/authentication.conf)file, in plain text.

In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the `integrationKey`, `secretKey`, and `appSecretKey` secrets, generated by [Duo Two-Factor Authentication for Splunk Enterprise](https://duo.com/docs/splunk), in plain text.

In Splunk Enterprise versions below 9.0.8, the Splunk RapidDiag utility discloses server responses from external applications in a log file.

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 Add-on Builder versions below 4.1.4, the app writes sensitive information to internal log files.

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.

Dell PowerScale OneFS 9.5.0.x, contains an insertion of sensitive information into log file vulnerability in SNMPv3. A low privileges user could potentially exploit this vulnerability, leading to information disclosure.

The Brocade Fabric OS Commands “configupload” and “configdownload” before Brocade Fabric OS v9.1.1c, v8.2.3d, v9.2.0 print scp, sftp, ftp servers passwords in supportsave. This could allow a remote authenticated attacker to access sensitive information.

The auth_parse_options function in auth-options.c in sshd in OpenSSH before 5.7 provides debug messages containing authorized_keys command options, which allows remote authenticated users to obtain potentially sensitive information by reading these messages, as demonstrated by the shared user account required by Gitolite. NOTE: this can cross privilege boundaries because a user account may intentionally have no shell or filesystem access, and therefore may have no supported way to read an authorized_keys file in its own home directory.

Nomad Community and Nomad Enterprise (“Nomad”) are vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs. This vulnerability, identified as CVE-2025-1296, is fixed in Nomad Community Edition 1.9.7 and Nomad Enterprise 1.9.7, 1.8.11, and 1.7.19.

An insertion of sensitive information into log file vulnerability in Fortinet FortiOS 7.2.0 through 7.2.4 and FortiProxy 7.0.0 through 7.0.10. 7.2.0 through 7.2.1 allows an attacker to read certain passwords in plain text.

An information exposure vulnerability in Fortinet FortiWeb 6.2.0 CLI and earlier may allow an authenticated user to view sensitive information being logged via diagnose debug commands.

Veracode Scan Jenkins Plugin before 23.3.19.0, when the "Connect using proxy" option is enabled and configured with proxy credentials and when the Jenkins global system setting debug is enabled and when a scan is configured for remote agent jobs, allows users (with access to view the job log) to discover proxy credentials.

A vulnerability has been identified in Climatix POL909 (AWB module) (All versions < V11.44), Climatix POL909 (AWM module) (All versions < V11.36). The handling of log files in the web application of affected devices contains an information disclosure vulnerability which could allow logged in users to access sensitive files.

Planning Analytics Cartridge for Cloud Pak for Data 4.0 exposes sensitive information in logs which could lead an attacker to exploit this vulnerability to conduct further attacks. IBM X-Force ID: 247896.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All versions of Argo CD starting with v2.6.0-rc1 have an output sanitization bug which leaks repository access credentials in error messages. These error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI). The user must have `applications, create` or `applications, update` RBAC access to reach the code which may produce the error. The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository. If the user has `repositories, update` access, they may edit an existing repository to introduce a URL typo or otherwise force an error message. But if they have that level of access, they are probably intended to have access to the credentials anyway. A patch for this vulnerability has been released in version 2.6.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Ansible, versions 2.9.x before 2.9.1, 2.8.x before 2.8.7 and Ansible versions 2.7.x before 2.7.15, is not respecting the flag no_log set it to True when Sumologic and Splunk callback plugins are used send tasks results events to collectors. This would discloses and collects any sensitive data.

Insertion of Sensitive Information into Log File vulnerability in upKeeper Solutions upKeeper Manager allows Use of Known Domain Credentials.This issue affects upKeeper Manager: from 5.2.0 before 5.2.12.

When using the cd4pe::root_configuration task to configure a Continuous Delivery for PE installation, the root user’s username and password were exposed in the job’s Job Details pane in the PE console. These issues have been resolved in version 1.2.1 of the puppetlabs/cd4pe module.

An issue was discovered in GitLab Community and Enterprise Edition 9.x, 10.x, and 11.x before 11.8.9, 11.9.x before 11.9.10, and 11.10.x before 11.10.2. Gitaly has allows an information disclosure issue where HTTP/GIT credentials are included in logs on connection errors.

Cloud Foundry UAA Release, versions prior to v74.10.0, when set to logging level DEBUG, logs client_secret credentials when sent as a query parameter. A remote authenticated malicious user could gain access to user credentials via the uaa.log file if authentication is provided via query parameters.

Pivotal Ops Manager, versions 2.4.x prior to 2.4.27, 2.5.x prior to 2.5.24, 2.6.x prior to 2.6.16, and 2.7.x prior to 2.7.5, logs all query parameters to tomcat’s access file. If the query parameters are used to provide authentication, ie. credentials, then they will be logged as well.

The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected.

Shopware is an open source eCommerce platform. Versions prior to 6.4.3.1 contain a vulnerability involving an insecure direct object reference of log files of the Import/Export feature. Version 6.4.3.1 contains a patch. As workarounds for older versions of 6.1, 6.2, and 6.3, corresponding security measures are also available via a plugin.

In Search Guard FLX versions from 1.0.0 up to 4.0.1, the audit logging feature might log user credentials from users logging into Kibana.

Shopware is an open source commerce platform based on Symfony Framework and Vue js. In affected versions the log module would write out all kind of sent mails. An attacker with access to either the local system logs or a centralized logging store may have access to other users accounts. This issue has been addressed in version 6.4.18.1. For older versions of 6.1, 6.2, and 6.3, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. Users unable to upgrade may remove from all users the log module ACL rights or disable logging.

OpenShift Container Platform, versions 4.1 and 4.2, does not sanitize secret data written to pod logs when the log level in a given operator is set to Debug or higher. A low privileged user could read pod logs to discover secret material if the log level has already been modified in an operator by a privileged user.

Hydrosystem Control System saves sensitive information into a log file. Critically, user credentials are logged allowing the attacker to obtain further authorized access into the system. Combined with vulnerability CVE-2026-34184, these sensitive information could be accessed by an unauthorized user.This issue was fixed in Hydrosystem Control System version 9.8.5

A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way that FreeIPA's batch processing API logged operations. This included passing user passwords in clear text on FreeIPA masters. Batch processing of commands with passwords as arguments or options is not performed by default in FreeIPA but is possible by third-party components. An attacker having access to system logs on FreeIPA masters could use this flaw to produce log file content with passwords exposed.

The OpenSearch logging provider, when configured with a `host` URL that embeds credentials (for example `https://user:password@server.example.com:9200`), wrote the full host URL — including the embedded credentials — into task logs. Any user with task-log read permission could harvest the backend credentials. Users are advised to upgrade to `apache-airflow-providers-opensearch` 1.9.1 or later and, as a defense-in-depth measure, configure the backend credentials via a secret backend rather than embedding them in the `[opensearch] host` URL.

The Elasticsearch logging provider, when configured with a `host` URL that embeds credentials (for example `https://user:password@server.example.com:9200`), wrote the full host URL — including the embedded credentials — into task logs. Any user with task-log read permission could harvest the backend credentials. Users are advised to upgrade to `apache-airflow-providers-elasticsearch` 6.5.3 or later and, as a defense-in-depth measure, configure the backend credentials via a secret backend rather than embedding them in the `[elasticsearch] host` URL.

An improper sanitization vulnerability exists in the BIG-IP QKView utility that allows a low-privileged attacker to read sensitive information from a QKView file.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

TYPO3 is an open source PHP based web content management system. In versions 9.0.0 through 9.5.27, 10.0.0 through 10.4.17, and 11.0.0 through 11.3.0, user credentials may been logged as plain-text. This occurs when explicitly using log level debug, which is not the default configuration. TYPO3 versions 9.5.28, 10.4.18, 11.3.1 contain a patch for this vulnerability.

Vulnerability in Cloud Foundry Notifications, Cloud Foundry SMB-volume release, Cloud FOundry cf-nfs-volume release.This issue affects Notifications: All versions prior to 63; SMB-volume release: All versions prior to 3.1.19; cf-nfs-volume release: 5.0.X versions prior to 5.0.27, 7.1.X versions prior to 7.1.19.

The VMware Tanzu Application Service for VMs and Isolation Segment contain an information disclosure vulnerability due to the logging of credentials in hex encoding in platform system audit logs. A malicious non-admin user who has access to the platform system audit logs can access hex encoded CF API admin credentials and can push new malicious versions of an application. In a default deployment non-admin users do not have access to the platform system audit logs.