| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An information disclosure vulnerability exists in the backup configuration process where the SAS token is not masked in the configuration response. This oversight results in sensitive information leakage within the yb_backup log files, exposing the SAS token in plaintext. The leakage occurs during the backup procedure, leading to potential unauthorized access to resources associated with the SAS token. 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. |
| Insertion of sensitive information into log file for some Intel(R) Local Manageability Service software before version 2316.5.1.2 may allow an authenticated user to potentially enable information disclosure via local access. |
| zot is ancontainer image/artifact registry based on the Open Container Initiative Distribution Specification. Prior to version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f), when using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup. Version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f) fixes the issue. |
| AnyDesk through 8.1.0 on Windows, when Allow Direct Connections is enabled, inadvertently exposes a public IP address within network traffic. The attacker must know the victim's AnyDesk ID. |
| kube-audit-rest is a simple logger of mutation/creation requests to the k8s api. If the "full-elastic-stack" example vector configuration was used for a real cluster, the previous values of kubernetes secrets would have been disclosed in the audit messages. This vulnerability is fixed in 1.0.16. |
| Metabase is an open source Business Intelligence and Embedded Analytics tool. When admins change Snowflake connection details in Metabase (either updating a password or changing password to private key or vice versa), Metabase would not always purge older Snowflake connection details from the application database. In order to remove older and stale connection details, Metabase would try one connection method at a time and purge all the other connection methods from the application database. When Metabase found a connection that worked, it would log (log/infof "Successfully connected, migrating to: %s" (pr-str test-details)) which would then print the username and password to the logger. This is fixed in 52.17.1, 53.9.5 and 54.1.5 in both the OSS and enterprise editions. Versions 51 and lower are not impacted. |
| A problem with the Palo Alto Networks Cortex XDR Microsoft 365 Defender Pack can result in exposure of user credentials 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 credentials are exposed to recipients of the application logs. |
| The ops library is a Python framework for developing and testing Kubernetes and machine charms. The issue here is that ops passes the secret content as one of the args via CLI. This issue may affect any of the charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing `subprocess.CalledProcessError`. This vulnerability is fixed in 2.15.0. |
| apko is an apk-based OCI image builder. apko exposures HTTP basic auth credentials from repository and keyring URLs in log output. This vulnerability is fixed in v0.14.5. |
| 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.**
|
| spaces_plugin/app.py in SolidUI 0.4.0 has an unnecessary print statement for an OpenAI key. The printed string might be logged. |
| Insertion of Sensitive Information into Log File vulnerability in Octolize USPS Shipping for WooCommerce – Live Rates.This issue affects USPS Shipping for WooCommerce – Live Rates: from n/a through 1.9.4. |
|
A potential security vulnerability has been identified in HPE Compute Scale-up Server 3200 server. This vulnerability could cause disclosure of sensitive information in log files.
|
| Information exposure in the logging system in Yugabyte Platform allows local attackers with access to application logs to obtain database user credentials in log files, potentially leading to unauthorized database access. |
| Insertion of Sensitive Information into Log File vulnerability in Hitachi Ops Center Administrator allows local users to gain sensitive information.This issue affects Hitachi Ops Center Administrator: before 11.0.1.
|
| Insertion of Sensitive Information into Log File vulnerability in Hitachi Cosminexus Component Container allows local users to gain sensitive information.This issue affects Cosminexus Component Container: from 11-30 before 11-30-05, from 11-20 before 11-20-07, from 11-10 before 11-10-10, from 11-00 before 11-00-12, All versions of V8 and V9.
|
| A vulnerability exists in Docker Desktop prior to version 4.39.0 that could lead to the unintentional disclosure of sensitive information via application logs. In affected versions, proxy configuration data—potentially including sensitive details—was written to log files in clear text whenever an HTTP GET request was made through a proxy. An attacker with read access to these logs could obtain the proxy information and leverage it for further attacks or unauthorized access. Starting with version 4.39.0, Docker Desktop no longer logs the proxy string, thereby mitigating this risk. |
| 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. |
| The Quickcreator – AI Blog Writer plugin for WordPress is vulnerable to Sensitive Information Exposure in versions 0.0.9 to 0.1.17 through the /wp-content/plugins/quickcreator/dupasrala.txt file. This makes it possible for unauthenticated attackers to view the plugin's API key and subsequently use that to perform actions on the site like creating new posts and injecting XSS payloads. |
| Shared Access Signature token is not masked in the backup configuration response and is also exposed in the yb_backup logs |
