| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| Insertion of sensitive information into log file in Windows Kernel allows an authorized attacker to disclose information locally. |
| Insertion of sensitive information into log file in Windows Kernel allows an authorized attacker to disclose information locally. |
| Insertion of sensitive information into log file in Windows Kernel allows an authorized attacker to disclose information locally. |
| SpiceDB is an open source database system for creating and managing security-critical application permissions. In versions 1.49.0 through 1.51.0, when SpiceDB starts with log level info, the startup "configuration" log will include the full datastore DSN, including the plaintext password, inside DatastoreConfig.URI. This issue has been fixed in version 1.51.1. If users are unable to immediately upgrade, they can work around this issue by changing the log level to warn or error. |
| A vulnerability exists in FlashBlade whereby sensitive information may be logged under specific conditions. |
| Dell PowerScale OneFS, versions prior to 9.12.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 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. |
| CWE-532 Insertion of Sensitive Information into Log File vulnerability exists that could cause confidential information to be exposed when a Web Admin user executes a malicious file provided by an attacker. |
| 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. |
| Backstage is an open framework for building developer portals. Prior to version 3.1.4, a malicious scaffolder template can bypass the log redaction mechanism to exfiltrate secrets provided run through task event logs. This issue has been patched in version 3.1.4. |
| HCL Sametime for Android is impacted by a sensitive information disclosure. Hostnames information is written in application logs and certain URL |
| A potential vulnerability was reported in the Lenovo FileZ Android application that, under certain conditions, could allow a local authenticated user to retrieve some sensitive data stored in a log file. |
