| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insertion of sensitive information into log file in Windows Kernel allows an unauthorized attacker to disclose information locally. |
| In Secure Access 12.70 and prior to 14.20, the logging
subsystem may write an unredacted authentication token to logs under
certain configurations. Any party with access to those logs could read
the token and reuse it to access an integrated system. |
| Valtimo is an open-source business process automation platform. In versions 13.0.0 through 13.21.0, the InboxHandlingService logs the full content of every incoming inbox message at INFO level. Inbox messages can contain highly sensitive information including personal data (PII), citizen identifiers (BSN), and case details. This data is exposed to anyone with access to application logs or any Valtimo user with the admin role through the Admin UI logging module. This issue has been fixed in version 13.22.0. If developers are unable to upgrade immediately, they can restrict access to application logs and adjust the log level for com.ritense.inbox to WARN or higher in their application configuration as a workaround. |
| An Insertion of Sensitive Information into Log File vulnerability in B&R PVI client versions prior to 6.5 may be abused by an authenticated local attacker to gather credential information which is processed by the PVI client application. The logging function of the PVI client application is disabled by default and must be explicitly enabled by the user. |
| vLLM is an inference and serving engine for large language models (LLMs). From 0.8.3 to before 0.14.1, when an invalid image is sent to vLLM's multimodal endpoint, PIL throws an error. vLLM returns this error to the client, leaking a heap address. With this leak, we reduce ASLR from 4 billion guesses to ~8 guesses. This vulnerability can be chained a heap overflow with JPEG2000 decoder in OpenCV/FFmpeg to achieve remote code execution. This vulnerability is fixed in 0.14.1. |
| RustFS is a distributed object storage system built in Rust. From versions alpha.13 to alpha.81, RustFS logs sensitive credential material (access key, secret key, session token) to application logs at INFO level. This results in credentials being recorded in plaintext in log output, which may be accessible to internal or external log consumers and could lead to compromise of sensitive credentials. This issue has been patched in version alpha.82. |
| AutoGPT is a platform that allows users to create, deploy, and manage continuous artificial intelligence agents that automate complex workflows. Prior to autogpt-platform-beta-v0.6.46, the AutoGPT platform's Stagehand integration blocks log API keys and authentication secrets in plaintext using logger.info() statements. This occurs in three separate block implementations (StagehandObserveBlock, StagehandActBlock, and StagehandExtractBlock) where the code explicitly calls api_key.get_secret_value() and logs the result. This issue has been patched in autogpt-platform-beta-v0.6.46. |
| In JetBrains YouTrack before 2025.3.119033 access tokens could be exposed in Mailbox logs |
| PlaciPy is a placement management system designed for educational institutions. In version 1.0.0, The application logs highly sensitive data directly to console output without masking or redaction. |
| unity-cli is a command line utility for the Unity Game Engine. Prior to 1.8.2 , the sign-package command in @rage-against-the-pixel/unity-cli logs sensitive credentials in plaintext when the --verbose flag is used. Command-line arguments including --email and --password are output via JSON.stringify without sanitization, exposing secrets to shell history, CI/CD logs, and log aggregation systems. This vulnerability is fixed in 1.8.2. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, and Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the the Splunk _internal index could view the Security Assertion Markup Language (SAML) configurations for Attribute query requests (AQRs) or Authentication extensions in plain text within the conf.log file, depending on which feature is configured. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the `integrationKey`, `secretKey`, and `appSecretKey` secrets, generated by [Duo Two-Factor Authentication for Splunk Enterprise](https://duo.com/docs/splunk), in plain text. |
| Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4].
[1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html
[2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html
[3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html
[4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/
Users are recommended to upgrade to version 3.2.0, which fixes this issue. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Trends. |
| A vulnerability exists in FlashBlade whereby sensitive information may be logged under specific conditions. |
| 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. |
