In JetBrains TeamCity version before 2022.10, Password parameters could be exposed in the build log if they contained special characters

In JetBrains TeamCity before 2023.05.1 build chain parameters of the "password" type could be written to the agent log

In JetBrains TeamCity before 2023.05.1 build parameters of the "password" type could be written to the agent log

In JetBrains TeamCity before 2022.04.2 the private SSH key could be written to the build log in some cases

In JetBrains TeamCity before 2025.07.1 aWS credentials were exposed in Docker script files

In JetBrains TeamCity before 2023.05.1 parameters of the "password" type could be shown in the UI in certain composite build configurations

In JetBrains TeamCity before 2024.12.1 decryption of connection secrets without proper permissions was possible via Test Connection endpoint

In JetBrains TeamCity version before 2022.10, Project Viewer could see scrambled secure values in the MetaRunner settings

In JetBrains TeamCity before 2024.12 backup file exposed user credentials and session cookies

In JetBrains TeamCity before 2024.07.3 password could be exposed via Sonar runner REST API

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 improper access control in Pull Requests and Commit status publisher build features was possible

In JetBrains TeamCity before 2021.2, blind SSRF via an XML-RPC call was possible.

In JetBrains TeamCity before 2021.2, health items of pull requests were shown to users who lacked appropriate permissions.

In JetBrains YouTrack versions before 2020.3.4313, 2020.2.11008, 2020.1.11011, 2019.1.65514, 2019.2.65515, and 2019.3.65516, an attacker can retrieve an issue description without appropriate access.

In JetBrains TeamCity before 2024.07 comparison of authorization tokens took non-constant time

In JetBrains TeamCity before 2024.03.2 users could perform actions that should not be available to them based on their permissions

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5, 2024.03.2 path traversal allowing to read files from server was possible

In JetBrains TeamCity before 2024.03.2 certain TeamCity API endpoints did not check user permissions

In JetBrains TeamCity before 2020.1.1, project parameter values can be retrieved by a user without appropriate permissions.

In JetBrains Rider before 2023.3.3 logging of environment variables containing secret values was possible

In JetBrains PhpStorm before 2023.1 source code could be logged in the local idea.log file

In JetBrains TeamCity before 2025.03.1 base64-encoded credentials could be exposed in build logs

In JetBrains IntelliJ IDEA before 2024.3, 2024.2.4 source code could be logged in the idea.log file

In JetBrains TeamCity before 2025.03 base64 encoded password could be exposed in build log

In JetBrains YouTrack before 2024.3.55417 permanent tokens could be exposed in logs

In JetBrains TeamCity before 2022.04 leak of secrets in TeamCity agent logs was possible

In JetBrains TeamCity before 2023.05 parameters of the "password" type from build dependencies could be logged in some cases

In JetBrains TeamCity before 2019.2.3, password parameters could be disclosed via build logs.

In JetBrains TeamCity before 2022.04.4 environmental variables of "password" type could be logged when using custom Perforce executable

In JetBrains TeamCity before 2022.04.3 the private SSH key could be written to the server log in some cases

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.

Multiple Exposure of sensitive information to an unauthorized actor vulnerabilities [CWE-200] in FortiAIOps version 2.0.0 may allow an authenticated, remote attacker to retrieve sensitive information from the API endpoint or log files.

Couchbase Server 6.6.x through 7.x before 7.0.4 exposes Sensitive Information to an Unauthorized Actor.

A vulnerability in the logging component of Cisco Duo Authentication Proxy could allow an authenticated, remote attacker to view sensitive information in clear text on an affected system. This vulnerability exists because certain unencrypted credentials are stored. An attacker could exploit this vulnerability by accessing the logs on an affected system and obtaining credentials that they may not normally have access to. A successful exploit could allow the attacker to view sensitive information in clear text.

Potential Insertion of Sensitive Information into Jetty Log Files in multiple versions of OpenNMS Meridian and Horizon could allow disclosure of usernames and passwords if the logging level is set to debug. Users should upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet.

IBM InfoSphere Information Server 11.7 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 280361.

In affected versions of the Octopus Kubernetes worker or agent, sensitive variables could be written to the Kubernetes script pod log in clear-text. This was identified in Version 2 however it was determined that this could also be achieved in Version 1 and the fix was applied to both versions accordingly.

An information disclosure vulnerability exists in Yugabyte Anywhere, where the LDAP bind password is logged in plaintext within application logs. This flaw results in the unintentional exposure of sensitive information in Yugabyte Anywhere logs, potentially allowing unauthorized users with access to these logs to view the LDAP bind password. An attacker with log access could exploit this vulnerability to gain unauthorized access to the LDAP server, leading to potential exposure or compromise of LDAP-managed resources This issue affects YugabyteDB Anywhere: from 2.20.0.0 before 2.20.7.0, from 2.23.0.0 before 2.23.1.0, from 2024.1.0.0 before 2024.1.3.0.

An insertion of sensitive information into the log file in the audit log in GitHub Enterprise Server was identified that could allow an attacker to gain access to the management console. To exploit this, an attacker would need access to the log files for the GitHub Enterprise Server appliance, a backup archive created with GitHub Enterprise Server Backup Utilities, or a service which received streamed logs. This vulnerability affected all versions of GitHub Enterprise Server since 3.8 and was fixed in version 3.8.12, 3.9.7, 3.10.4, and 3.11.1. 

GitLab CE/EE, versions 8.0 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, would log access tokens in the Workhorse logs, permitting administrators with access to the logs to see another user's token.

An issue was discovered by Elastic whereby Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.

Since version 5.2.0, when using deferrable mode with the path of a Kubernetes configuration file for authentication, the Airflow worker serializes this configuration file as a dictionary and sends it to the triggerer by storing it in metadata without any encryption. Additionally, if used with an Airflow version between 2.3.0 and 2.6.0, the configuration dictionary will be logged as plain text in the triggerer service without masking. This allows anyone with access to the metadata or triggerer log to obtain the configuration file and use it to access the Kubernetes cluster. This behavior was changed in version 7.0.0, which stopped serializing the file contents and started providing the file path instead to read the contents into the trigger. Users are recommended to upgrade to version 7.0.0, which fixes this issue.

Laf is a cloud development platform. In the Laf version design, the log uses communication with k8s to quickly retrieve logs from the container without the need for additional storage. However, in version 1.0.0-beta.13 and prior, this interface does not verify the permissions of the pod, which allows authenticated users to obtain any pod logs under the same namespace through this method, thereby obtaining sensitive information printed in the logs. As of time of publication, no known patched versions exist.

CodeIgniter Shield is an authentication and authorization provider for CodeIgniter 4. In affected versions successful login attempts are recorded with the raw tokens stored in the log table. If a malicious person somehow views the data in the log table they can obtain a raw token which can then be used to send a request with that user's authority. This issue has been addressed in version 1.0.0-beta.8. Users are advised to upgrade. Users unable to upgrade should disable logging for successful login attempts by the configuration files.

An issue was discovered by Elastic whereby Watcher search input logged the search query results on DEBUG log level. This could lead to raw contents of documents stored in Elasticsearch to be printed in logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by removing this excessive logging. This issue only affects users that use Watcher and have a Watch defined that uses the search input and additionally have set the search input’s logger to DEBUG or finer, for example using: org.elasticsearch.xpack.watcher.input.search, org.elasticsearch.xpack.watcher.input, org.elasticsearch.xpack.watcher, or wider, since the loggers are hierarchical.

An issue was discovered by Elastic whereby the Documents API of App Search logged the raw contents of indexed documents at INFO log level. Depending on the contents of such documents, this could lead to the insertion of sensitive or private information in the App Search logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by changing the log level at which these are logged to DEBUG, which is disabled by default.

Dell OpenManage Enterprise, versions 3.10, 4.0, 4.1, and 4.2, contains an Insertion of Sensitive Information into Log File vulnerability in the Backup and Restore. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.

CubeFS is an open-source cloud-native file storage system. CubeFS prior to version 3.3.1 was found to leak users secret keys and access keys in the logs in multiple components. When CubeCS creates new users, it leaks the users secret key. This could allow a lower-privileged user with access to the logs to retrieve sensitive information and impersonate other users with higher privileges than themselves. The issue has been patched in v3.3.1. There is no other mitigation than upgrading CubeFS.

An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error or in the event where debug level logging is enabled in Kibana. Elastic has released Kibana 8.11.2 which resolves this issue. The messages recorded in the log may contain Account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users, Elastic Security package policy objects which can contain private keys, bearer token, and sessions of 3rd-party integrations and finally Authorization headers, client secrets, local file paths, and stack traces. The issue may occur in any Kibana instance running an affected version that could potentially receive an unexpected error when communicating to Elasticsearch causing it to include sensitive data into Kibana error logs. It could also occur under specific circumstances when debug level logging is enabled in Kibana. Note: It was found that the fix for ESA-2023-25 in Kibana 8.11.1 for a similar issue was incomplete.

An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error. Elastic has released Kibana 8.11.1 which resolves this issue. The error message recorded in the log may contain account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users. The issue occurs infrequently, only if an error is returned from an Elasticsearch cluster, in cases where there is user interaction and an unhealthy cluster (for example, when returning circuit breaker or no shard exceptions).