Insertion of Sensitive Information into Log File

Insertion of Sensitive Information into Log File in Checkmk GmbH's Checkmk versions <2.3.0p7, <2.2.0p28, <2.1.0p45 and <=2.0.0p39 (EOL) causes automation user secrets to be written to audit log files accessible to administrators.Show less

Dell PowerProtect DD, versions prior to 8.0, LTS 7.13.1.0, LTS 7.10.1.30, LTS 7.7.5.40 contain a disclosure of temporary sensitive information vulnerability. A remote high privileged attacker could potentially exploit this vulnerability, leading to the reuse of disclosed information to gain unauthorized access to the application report.Show less

A vulnerability in a password management API in Brocade Fabric OS versions before v9.2.1, v9.2.0b, v9.1.1d, and v8.2.3e prints sensitive information in log files. This could allow an authenticated user to view the server passwords for protocols such as scp and sftp. Detail. When the firmwaredownload command is incorrectly entered or points to an erroneous file, the firmware download log captures the failed command, including any password entered in the command line.Show less

go-retryablehttp prior to 0.7.7 did not sanitize urls when writing them to its log file. This could lead to go-retryablehttp writing sensitive HTTP basic auth credentials to its log file. This vulnerability, CVE-2024-6104, was fixed in go-retryablehttp 0.7.7.Show less

In SonarQube before 10.4 and 9.9.4 LTA, encrypted values generated using the Settings Encryption feature are potentially exposed in cleartext as part of the URL parameters in the logs (such as SonarQube Access Logs, Proxy Logs, etc).Show less

The sessions are stored in clear-text logs. An attacker can retrieve authentication sessions. A remote attacker can retrieve the credentials and bypass the authentication mechanism. As for the affected products/models/versions, see the reference URL.Show less

The session cookies, used for authentication, are stored in clear-text logs. An attacker can retrieve authentication sessions. A remote attacker can retrieve the credentials and bypass the authentication mechanism. As for the affected products/models/versions, see the reference URL.Show less

A problem with the Palo Alto Networks GlobalProtect app can result in exposure of encrypted user credentials, used for connecting to GlobalProtect, in application logs. Normally, these application logs are only viewable by local users and are included when generating logs for troubleshooting purposes. This means that these encrypted credentials are exposed to recipients of the application logs.Show less

Under certain circumstances the Microsoft® Internet Information Server (IIS) used to host the C•CURE 9000 Web Server will log Microsoft Windows credential details within logs. There is no impact to non-web service interfaces C•CURE 9000 or prior versionsShow less

Sentry is a developer-first error tracking and performance monitoring platform. Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. **SaaS users** do not need to take any action. **Self-hosted users** should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token. For users only using the `slack.signing-secret` in their self-hosted configuration, the legacy verification token is not used to verify the webhook payload. It is ignored. Users unable to upgrade should either set the `slack.signing-secret` instead of `slack.verification-token`. The signing secret is Slack's recommended way of authenticating webhooks. By having `slack.singing-secret` set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether `slack.verification-token` is set or not. Alternatively if the self-hosted instance is unable to be upgraded or re-configured to use the `slack.signing-secret`, the logging configuration can be adjusted to not generate logs from the integration. The default logging configuration can be found in `src/sentry/conf/server.py`. **Services should be restarted once the configuration change is saved.** Show less

Fides is an open-source privacy engineering platform. The Fides webserver requires a connection to a hosted PostgreSQL database for persistent storage of application data. If the password used by the webserver for this database connection includes special characters such as `@` and `$`, webserver startup fails and the part of the password following the special character is exposed in webserver error logs. This is caused by improper escaping of the SQLAlchemy password string. As a result users are subject to a partial exposure of hosted database password in webserver logs. The vulnerability has been patched in Fides version `2.37.0`. Users are advised to upgrade to this version or later to secure their systems against this threat. There are no known workarounds for this vulnerability.Show less

The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, OCI, Helm repositories and S3-compatible buckets. The source-controller implements the source.toolkit.fluxcd.io API and is a core component of the GitOps toolkit. Prior to version 1.2.5, when source-controller was configured to use an Azure SAS token when connecting to Azure Blob Storage, the token was logged along with the Azure URL when the controller encountered a connection error. An attacker with access to the source-controller logs could use the token to gain access to the Azure Blob Storage until the token expires. This vulnerability was fixed in source-controller v1.2.5. There is no workaround for this vulnerability except for using a different auth mechanism such as Azure Workload Identity.Show less