| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The matrix-sdk-crypto crate, part of the Matrix Rust SDK project, is an implementation of a Matrix end-to-end encryption state machine in Rust. In Matrix, the server-side `key backup` stores encrypted copies of Matrix message keys. This facilitates key sharing between a user's devices and provides a redundant copy in case all devices are lost. The key backup uses asymmetric
cryptography, with each server-side key backup assigned a unique public-private key pair. Due to a logic bug introduced in commit 71136e44c03c79f80d6d1a2446673bc4d53a2067, matrix-sdk-crypto version 0.7.0 will sometimes log the private part of the backup key pair to Rust debug logs (using the `tracing` crate). This issue has been resolved in matrix-sdk-crypto version 0.7.1. No known workarounds are available. |
| 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. |
| Under certain circumstances unnecessary user details are provided within system logs |
| 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. |
| Disclosure
of sensitive information in a Milestone XProtect Device Pack driver’s log file for third-party cameras, allows an attacker to read camera
credentials stored in the Recording Server under specific conditions. |
| User credentials (login & password) are inserted into log files when a user tries to authenticate using a version of a Web client that is not compatible with that of the PcVue Web back end.
By exploiting this vulnerability, an attacker could retrieve the credentials of a user by accessing the Log File. Successful exploitation of this vulnerability could lead to unauthorized access to the application. |
| The Woo Manage Fraud Orders plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.6.1 through publicly exposed log files. This makes it possible for unauthenticated attackers to view potentially sensitive information about users contained in the exposed log files. |
| System environment variables are recorded in Docker Desktop diagnostic logs, when using shell auto-completion. This leads to unintentional disclosure of sensitive information such as api keys, passwords, etc.
A malicious actor with read access to these logs could obtain secrets and further use them to gain unauthorized access to other systems. Starting with version 4.43.0 Docker Desktop no longer logs system environment variables as part of diagnostics log collection. |
| 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. |
| 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.
|
| 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.
|
|
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.
|
| Under certain log settings the IAM or CORE service will log credentials in the iam logfile in Fortra Application Hub (Formerly named Helpsystems One) prior to version 1.3 |
| Using API in the 2N OS device, authorized user can enable logging, which discloses valid authentication tokens in system log.
2N has released an updated version 2.46 of 2N OS, where this vulnerability is mitigated. It is recommended that all customers update their devices to the latest 2N OS. |
| Insertion of sensitive information into log file issue exists in RoamWiFi R10 prior to 4.8.45. If this vulnerability is exploited, a network-adjacent unauthenticated attacker with access to the device may obtain sensitive information. |
| 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.**
|
| Steeltoe is an open source project that provides a collection of libraries that helps users build production-grade cloud-native applications using externalized configuration, service discovery, distributed tracing, application management, and more. When utilizing multiple Eureka server service URLs with basic auth and encountering an issue with fetching the service registry, an error is logged with the Eureka server service URLs but only the first URL is masked. The code in question is `_logger.LogError(e, "FetchRegistry Failed for Eureka service urls: {EurekaServerServiceUrls}", new Uri(ClientConfig.EurekaServerServiceUrls).ToMaskedString());` in the `DiscoveryClient.cs` file which may leak credentials into logs. This issue has been addressed in version 3.2.8 of the Steeltoe.Discovery.Eureka nuget package. |
| 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. |
| Passwords of agents and customers are displayed in plain text in the OTRS admin log module if certain configurations regarding the authentication sources match and debugging for the authentication backend has been enabled.
This issue affects:
* OTRS from 7.0.X through 7.0.50
* OTRS 8.0.X
* OTRS 2023.X
* OTRS from 2024.X through 2024.5.X
* ((OTRS)) Community Edition: 6.0.x
Products based on the ((OTRS)) Community Edition also very likely to be affected |
| Insertion of Sensitive Information into Log File vulnerability observed in FLEXON. Some information may be improperly disclosed through https access.
This issue affects FLXEON through <= 9.3.4. |
