| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions. |
| Passwords are stored in clear-text logs. An attacker can retrieve passwords. As for the affected products/models/versions, see the reference URL. |
| 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 |
| 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.
|
| An information disclosure vulnerability in Phloc Webscopes 7.0.0 allows local attackers with access to the log files to view logged HTTP requests that contain user passwords or other sensitive information. |
| 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. |
| 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. |
| 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. |
| A vulnerability has been identified in SINUMERIK 828D V4 (All versions < V4.95 SP3), SINUMERIK 840D sl V4 (All versions < V4.95 SP3 in connection with using Create MyConfig (CMC) <= V4.8 SP1 HF6), SINUMERIK ONE (All versions < V6.23 in connection with using Create MyConfig (CMC) <= V6.6), SINUMERIK ONE (All versions < V6.15 SP4 in connection with using Create MyConfig (CMC) <= V6.6). Affected systems, that have been provisioned with Create MyConfig (CMC), contain a Insertion of Sensitive Information into Log File vulnerability. This could allow a local authenticated user with low privileges to read sensitive information and thus circumvent access restrictions. |
| Insertion of Sensitive Information into Log File (CWE-532) in the Gallagher Command Centre Alarm Transmitter feature could allow an authenticated Operator to view some security sensitive information to which they have not been granted access.
This issue affects: Command Centre Server 9.10 prior to 9.10.2149 (MR4), 9.00 prior to 9.00.2374 (MR5), 8.90 prior to 8.90.2356 (MR6), all versions of 8.80 and prior. |
| 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.**
|
| IBM Tivoli Netcool Impact 7.1.0.0 through 7.1.0.37 stores sensitive information in log files that could be read by a local user. |
| Dell Elastic Cloud Storage, version 3.8.1.7 and prior, and Dell ObjectScale, versions prior to 4.1.0.3 and version 4.2.0.0, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to secret exposure. The attacker may be able to use the exposed secret to access the vulnerable system with privileges of the compromised account. |
| Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.
Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue. |
| FileZilla 3.40.0 contains a denial of service vulnerability in the local search functionality that allows local attackers to crash the application by supplying a malformed path string. Attackers can trigger the crash by entering a crafted path containing 384 'A' characters followed by 'BBBB' and 'CCCC' sequences in the search directory field and initiating a local search operation. |
| The Registration Forms – User Registration Forms, Invitation-Based Registrations, Front-end User Profile, Login Form & Content Restriction plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.8.4 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. |
| The Easy Digital Downloads – Sell Digital Files & Subscriptions (eCommerce Store + Payments Made Easy) plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.2.9. This makes it possible for unauthenticated attackers to download the debug log via Directory Listing. This file may include PII. |
| The CTT Expresso para WooCommerce plugin for WordPress is vulnerable to sensitive information exposure in all versions up to and including 3.2.12 via the /wp-content/uploads/cepw directory. The generated .pdf and log files are publicly accessible and contain sensitive information such as sender and receiver names, phone numbers, physical addresses, and email addresses |
| Brocade ASCG before 3.3.0 logs JSON
Web Tokens (JWT) in log files. An attacker with access to the log files
can withdraw the unencrypted tokens with security implications, such as
unauthorized access, session hijacking, and information disclosure. |
| 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. |
