| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The acer_cgi.log file in the device firmware is accessible without authentication via the web interface. This file contains cleartext login credentials (for web and Telnet), leading to unauthorized system access. |
| IBM MQ Operator SC2: v3.2.0 through 3.2.23CD: v3.3.0, v3.4.0, v3.4.1, v3.5.0, v3.5.1 - v3.5.3, v3.6.0 - v3.6.4, v3.7.0 - v3.7.2, v3.8.0, v3.8.1, v3.9.0, v3.9.1LTS: v2.0.0 - 2.0.29 and IBM supplied MQ Advanced container images SC2: 9.4.0.6 through r1, 9.4.0.6-r2, 9.4.0.7-r1, 9.4.0.10-r1, 9.4.0.10-r2, 9.4.0.11-r1, 9.4.0.11-r2, 9.4.0.11-r3, 9.4.0.12-r1, 9.4.0.15-r1 - 9.4.0.15-r4, 9.4.0.16-r1, 9.4.0.16-r2, 9.4.0.17-r1, 9.4.0.17-r2, 9.4.0.20-r1CD: 9.4.1.0-r1, 9.4.1.0-r2, 9.4.1.1-r1, 9.4.2.0-r1, 9.4.2.0-r2, 9.4.2.1-r1, 9.4.2.1-r2, 9.4.3.0-r1, 9.4.3.0-r2, 9.4.3.1-r1 - 9.4.3.1-r3, 9.4.4.0-r1 - 9.4.4.0-r4, 9.4.4.1-r1, 9.4.5.0-r1, 9.4.5.0-r2LTS: 9.3.0.0-r1, 9.3.0.0-r2, 9.3.0.0-r3, 9.3.0.1-r1, 9.3.0.1-r2, 9.3.0.1-r3, 9.3.0.1-r4, 9.3.0.3-r1, 9.3.0.4-r1, 9.3.0.4-r2, 9.3.0.5-r1, 9.3.0.5-r2, 9.3.0.5-r3, 9.3.0.6-r1, 9.3.0.10-r1, 9.3.0.10-r2, 9.3.0.11-r1,9.3.0.11-r2, 9.3.0.15-r1, 9.3.0.16-r1, 9.3.0.16-r2, 9.3.0.17-r1, 9.3.0.17-r2, 9.3.0.17-r3, 9.3.0.20-r1, 9.3.0.20-r2, 9.3.0.21-r1, 9.3.0.21-r2, 9.3.0.21-r3, 9.3.0.25-r1, 9.4.0.0-r1, 9.4.0.0-r2, 9.4.0.0-r3, 9.4.0.5-r1, 9.4.0.5-r2 IBM MQ stores potentially sensitive information in log files that could be read by a local user. |
| RustFS is a distributed object storage system built in Rust. Prior to 1.0.0-beta.2, RustFS suffers from sensitive information leakage in log outputs. When the server is run with RUST_LOG=debug sensitive credentials including SessionToken (JWT), SecretAccessKey, and full JWT claims are printed in plaintext to the server logs. This vulnerability is fixed in 1.0.0-beta.2. |
| When calicoctl is invoked with --log-level=info or --log-level=debug, the client prints the full contents of its loaded connection-configuration struct to stderr in a single log line. The struct embeds every credential calicoctl uses to talk to the cluster — inline kubeconfig (with bearer token), Kubernetes API bearer token, etcd password, and inline PEM-encoded etcd client certificate and key. Any reader of that stderr stream — CI job logs, session-recording archives, shared support-ticket transcripts, or local filesystem viewers on the host that ran calicoctl — can extract these credentials with zero Kubernetes privilege. calicoctl's default log level is panic, so this issue only triggers when verbose logging is explicitly enabled. |
| When Calico is configured with the Azure IPAM plugin, the Calico CNI binary mutates the incoming CNI configuration to attach subnet information before delegating to the IPAM plugin. After mutating, the Azure IPAM helper logs the entire unmarshaled configuration map (stdinData) at INFO level to /var/log/calico/cni/cni.log on every CNI ADD and DEL invocation — once per pod scheduled or terminated on the node. When the cluster is deployed using token-based Kubernetes authentication, this log entry contains the ServiceAccount token, client key, and certificate authority in plaintext. Any principal with read access to /var/log/calico/cni/cni.log on a node can read these logs and extract the credentials, which grant cluster-wide Calico networking admin privileges. |
| In Calico, the install-cni init container logs the rendered CNI configuration to standard output. When the configuration template uses the __SERVICEACCOUNT_TOKEN__ placeholder (Canal/Flannel-Calico deployments), the installer substitutes the live Kubernetes ServiceAccount bearer token before logging, exposing the token to any authenticated user with pods/log permission in the namespace with calico-node. The token holds patch privileges on pods/status, enabling annotation-based attacks against cluster workloads. The default kubeconfig-based authentication path is not affected. This is a direct regression of TTA-2018-001. |
| This vulnerability in Veeam Agent for Microsoft Windows allows for Local Privilege Escalation. |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes DB2 Connect Server) stores potentially sensitive information in log files that could be read by a local user. |
| Insertion of Sensitive Information into Log File (CWE-532) in some Command Centre Service installers could lead to Service Account credentials exposure.
Mitigating Factor: Only sites that install Command Centre Services with a custom Service Account (not the default Network Service account) are potentially impacted.
Mitigation: For sites concerned about exposure, the recommended action is to change the Service Account password. They can also delete any installer log files, usually found in %programdata%\Gallagher\Command Centre. |
| Dell VxRail versions before 7.0.200 contain a Plain-text Password Storage Vulnerability in VxRail Manager. A sys-admin user may exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account. |
| Insertion of sensitive information into log file vulnerability in syslink software AG Avantra on Linux, Windows allows Resource Leak Exposure.
This issue affects Avantra: before 25.3.0. |
| The auth_parse_options function in auth-options.c in sshd in OpenSSH before 5.7 provides debug messages containing authorized_keys command options, which allows remote authenticated users to obtain potentially sensitive information by reading these messages, as demonstrated by the shared user account required by Gitolite. NOTE: this can cross privilege boundaries because a user account may intentionally have no shell or filesystem access, and therefore may have no supported way to read an authorized_keys file in its own home directory. |
| In Splunk Enterprise versions below 10.2.2 and 10.0.5, and Splunk Cloud Platform versions below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13, a user with a role that has access to the `_internal` index could view session cookies and response bodies that contain sensitive data. |
| An issue pertaining to CWE-532: Insertion of Sensitive Information into Log File was discovered in LupinLin1 jimeng-web-mcp v2.1.2. This allows an attacker to obtain sensitive information. |
| Netatalk 2.1.0 through 4.4.2 inserts LDAP simple-bind passwords into log output in cleartext, which allows an attacker with access to the log files to obtain LDAP credentials. |
| A flaw was found in ansible-collection-community-general. This vulnerability allows for information exposure (IE) of sensitive credentials, specifically plaintext passwords, via verbose output when running Ansible with debug modes. Attackers with access to logs could retrieve these secrets and potentially compromise Keycloak accounts or administrative access. |
| When schema validation is enabled on a collection and an update or insert would violate the collection's schema, the local server log message generated may not have all user data redacted.
This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2. |
| Valtimo is an open-source business process automation platform. From 12.4.0 to 12.33.0 and 13.26.0, the LoggingRestClientCustomizer in the web module automatically intercepts all outgoing HTTP calls made via Spring's RestClient and logs the full request body, response body, and response headers. When an error response is received, this information is included in the thrown HttpClientErrorException message, which is logged at ERROR level by Spring's default exception handling — regardless of the application's DEBUG log level setting. This vulnerability is fixed in 12.33.0 and 13.26.0. |
| n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.13, when n8n-mcp runs in HTTP transport mode, authenticated MCP tools/call requests had their full arguments and JSON-RPC params written to server logs by the request dispatcher and several sibling code paths before any redaction. When a tool call carries credential material — most notably n8n_manage_credentials.data — the raw values can be persisted in logs. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens and OAuth credentials sent through n8n_manage_credentials, per-tenant API keys and webhook auth headers embedded in tool arguments, arbitrary secret-bearing payloads passed to any MCP tool. The issue requires authentication (AUTH_TOKEN accepted by the server), so unauthenticated callers cannot trigger it; the runtime exposure is also reduced by an existing console-silencing layer in HTTP mode, but that layer is fragile and the values are still constructed and passed into the logger. This issue has been patched in version 2.47.13. |
| n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.11, when n8n-mcp runs in HTTP transport mode, incoming requests to the POST /mcp endpoint had their request metadata written to server logs regardless of the authentication outcome. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens from the Authorization header, per-tenant API keys from the, x-n8n-key header in multi-tenant setups, JSON-RPC request payloads sent to the MCP endpoint. Access control itself was not bypassed — unauthenticated requests were correctly rejected with 401 Unauthorized — but sensitive values from those rejected requests could still be persisted in logs. This issue has been patched in version 2.47.11. |
