CVE Database

Airflow versions before 2.11.1 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive connection parameters were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.11.1 or a later version, which addresses this issue. Users who previously used the CLI to set connections should manually delete entries with those connection sensitive values from the log table. This is similar but not the same issue as CVE-2024-50378

Tanium addressed an insertion of sensitive information into log file vulnerability in TanOS.

Tanium addressed an insertion of sensitive information into log file vulnerability in Interact and TDS.

Tanium addressed an insertion of sensitive information into log file vulnerability in Trends.

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 RSA `accessKey` value from the [<u>Authentication.conf</u> ](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/authentication.conf)file, in plain text.

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.

The vulnerability, if exploited, could allow an attacker with Event Log Reader (S-1-5-32-573) privileges to obtain proxy details, including URL and proxy credentials, from the PI to CONNECT event log files. This could enable unauthorized access to the proxy server.

Insertion of sensitive information into log file in Windows Kernel allows an authorized attacker to disclose information locally.

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 JetBrains YouTrack before 2025.3.119033 access tokens could be exposed in Mailbox logs

Tanium addressed an information disclosure vulnerability in Threat Response.

Neo4j Enterprise and Community editions versions prior to 2026.01.3 and 5.26.21 are vulnerable to a potential information disclosure by a user who has ability to access the local log files. The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access. We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literals enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j.

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.

IBM Aspera Console 3.4.7 stores potentially sensitive information in log files that could be read by a local privileged user.

A vulnerability. When org.apache.linkis.metadata.util.HiveUtils.decode() fails to perform Base64 decoding, it records the complete input parameter string in the log via logger.error(str + "decode failed", e). If the input parameter contains sensitive information such as Hive Metastore keys, plaintext passwords will be left in the log files when decoding fails, resulting in information leakage. Affected Scope Component: Sensitive fields in hive-site.xml (e.g., javax.jdo.option.ConnectionPassword) or other fields encoded in Base64. Version: Apache Linkis 1.0.0 – 1.7.0 Trigger Conditions The value of the configuration item is an invalid Base64 string. Log files are readable by users other than hive-site.xml administrators. Severity: Low The probability of Base64 decoding failure is low. The leakage is only triggered when logs at the Error level are exposed. Remediation Apache Linkis 1.8.0 and later versions have replaced the log with desensitized content. logger.error("URL decode failed: {}", e.getMessage()); // 不再输出 str Users are recommended to upgrade to version 1.8.0, which fixes the issue.