| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Splunk MCP Server app versions below 1.0.3 , a user who holds a role with access to the Splunk `_internal` index or possesses the high-privilege capability `mcp_tool_admin` could view users session and authorization tokens in clear text.<br><br>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. <br><br>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) and [Connecting to MCP Server and Admin settings](https://help.splunk.com/en/splunk-enterprise/mcp-server-for-splunk-platform/connecting-to-mcp-server-and-admin-settings) in the Splunk documentation for more information. |
| The Terraform Provider for Linode versions prior to v3.9.0 logged sensitive information including some passwords, StackScript content, and object storage data in debug logs without redaction. Provider debug logging is not enabled by default. This issue is exposed when debug/provider logs are explicitly enabled (for example in local troubleshooting, CI/CD jobs, or centralized log collection). If enabled, sensitive values may be written to logs and then retained, shared, or exported beyond the original execution environment. An authenticated user with access to provider debug logs (through log aggregation systems, CI/CD pipelines, or debug output) would thus be able to extract these sensitive credentials. Versions 3.9.0 and later sanitize debug logs by logging only non-sensitive metadata such as labels, regions, and resource IDs while redacting credentials, tokens, keys, scripts, and other sensitive content. Some other mitigations and workarounds are available. Disable Terraform/provider debug logging or set it to `WARN` level or above, restrict access to existing and historical logs, purge/retention-trim logs that may contain sensitive values, and/or rotate potentially exposed secrets/credentials. |
| Improper handling of configuration values in ZKConfig in Apache ZooKeeper 3.8.5 and 3.9.4 on all platforms allows an attacker to expose sensitive information stored in client configuration in the client's logfile. Configuration values are exposed at INFO level logging rendering potential production systems affected by the issue. Users are recommended to upgrade to version 3.8.6 or 3.9.5 which fixes this issue. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Interact and TDS. |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to writing of sensitive Information in a log file. |
| HCL Sametime for iOS is impacted by a sensitive information disclosure. Hostnames information is written in application logs and certain URLs. |
| HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to 25.0.0, the /server-status endpoint is publicly accessible and exposes sensitive information including authentication tokens (user_token), user activity, client IP addresses, and server configuration details. This allows any unauthenticated user to monitor real-time user interactions and gather internal infrastructure information. This vulnerability is fixed in 25.0.0. |
| The log files in Apache web server contain information directly supplied by clients and does not filter or quote control characters, which could allow remote attackers to hide HTTP requests and spoof source IP addresses when logs are viewed with UNIX programs such as cat, tail, and grep. |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Tahoe 26.3. A malicious app may be able to read sensitive location information. |
| The issue was resolved by sanitizing logging. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.3 and iPadOS 26.3. An app may be able to enumerate a user's installed apps. |
| Insertion of sensitive information into log file in Windows Kernel allows an authorized attacker to disclose information locally. |
| Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via ~/.cassandra/cqlsh_history local file access.
Users are recommended to upgrade to version 4.0.20, which fixes this issue.
--
Description: Cassandra's command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlsh_history file in the user's home directory.
However, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk. |
| 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. |
| Improper restriction of environment variables in Elastic Defend can lead to exposure of sensitive information such as API keys and tokens via automatic transmission of unfiltered environment variables to the stack. |
| 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. |
| 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. |
| Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. When debugging is enabled for Himmelblau in version 1.0.0, the himmelblaud_tasks service leaks an Intune service access token to the system journal. This short-lived token can be used to detect the host's Intune compliance status, and may permit additional administrative operations for the Intune host device (though the API for these operations is undocumented). This is fixed in version 1.1.0. To workaround this issue, ensure that Himmelblau debugging is disabled. |
| 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. |
| 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. |
| canonical/get-workflow-version-action is a GitHub composite action to get commit SHA that GitHub Actions reusable workflow was called with. Prior to 1.0.1, if the get-workflow-version-action step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated—causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs. Anyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs. The opportunity to exploit this vulnerability is limited—the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Users using the github-token input are impacted. This vulnerability is fixed in 1.0.1. |
