Sensitive Terraform Output Values Printed At Info Logging Level In Kitchen-Terraform

Kitchen-Terraform provides a set of Test Kitchen plugins which enable the use of Test Kitchen to converge a Terraform configuration and verify the resulting infrastructure systems with InSpec controls. Kitchen-Terraform v7.0.0 introduced a regression which caused all Terraform output values, including sensitive values, to be printed at the `info` logging level during the `kitchen converge` action. Prior to v7.0.0, the output values were printed at the `debug` level to avoid writing sensitive values to the terminal by default. An attacker would need access to the local machine in order to gain access to these logs during an operation. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Brocade Fabric OS switch passwords when debugging is enabled

Brocade SANnav versions before 2.2.2 log Brocade Fabric OS switch passwords when debugging is enabled.

Brocade SANnav Information Disclosure Vulnerability

Possible information exposure through log file vulnerability where sensitive fields are recorded in the debug-enabled logs when debugging is turned on in Brocade SANnav before 2.3.0 and 2.2.2a

Switch passwords and authorization IDs are printed in the embedded MLS DB file

An information exposure through log file vulnerability exists in Brocade SANnav before Brocade SANnav 2.2.2, where Brocade Fabric OS Switch passwords and authorization IDs are printed in the embedded MLS DB file.

configuration secrets are logged in support-save

An information exposure through log file vulnerability exists in Brocade SANnav before Brocade SANnav 2.2.2, where configuration secrets are logged in supportsave. Supportsave file is generated by an admin user troubleshooting the switch. The Logged information may include usernames and passwords, and secret keys.

Insertion of Sensitive Information into Brocade SANnav Log File

A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a could allow a privileged user to print the SANnav encrypted key in PostgreSQL startup logs. This could provide attackers with an additional, less-protected path to acquiring the encryption key.

Encryption key is stored in the DR log files

When Brocade SANnav before v2.3.1 and v2.3.0a servers are configured in Disaster Recovery mode, the encryption key is stored in the DR log files. This could provide attackers with an additional, less-protected path to acquiring the encryption key.

Encryption key in the console when a privileged user executes the script to replace the Brocade SANnav Management Portal standby node.

A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints the encryption key in the console when a privileged user executes the script to replace the Brocade SANnav Management Portal standby node. This could provide attackers an additional, less protected path to acquiring the encryption key.

Brocade Fabric OS switch encrypted passwords in the Brocade SANnav Standby node's support save

A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints Brocade Fabric OS switch encrypted passwords in the Brocade SANnav Standby node's support save.

IBM Db2 information disclosure

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5 is vulnerable to an information disclosure vulnerability as sensitive information may be included in a log file under specific conditions.

In JetBrains YouTrack before 2024.3.55417 permanent tokens could be exposed in logs

Automation user secret logged to Apache access log

Transmission of credentials within query parameters in Checkmk <= 2.1.0p26, <= 2.0.0p35, and <= 2.2.0b6 (beta) may cause the automation user's secret to be written to the site Apache access log.

IBM UrbanCode Deploy information disclosure

IBM UrbanCode Deploy (UCD) 7.0 through 7.0.5.20, 7.1 through 7.1.2.16, 7.2 through 7.2.3.9, 7.3 through 7.3.2.4 and IBM DevOps Deploy 8.0 through 8.0.0.1 is vulnerable to a sensitive information due to insufficient obfuscation of sensitive values from some log files. IBM X-Force ID: 279979.

IBM UrbanCode Deploy information disclosure

IBM UrbanCode Deploy (UCD) 7.0 through 7.0.5.24, 7.1 through 7.1.2.10, and 7.2 through 7.2.3.13 stores potentially sensitive information in log files that could be read by a local user with access to HTTP request logs.

Filebeat versions through 7.17.9 and 8.6.2 have a flaw in httpjson input that allows the http request Authorization or Proxy-Authorization header contents to be leaked in the logs when debug logging is enabled.

Dell Grab for Windows, versions 5.0.4 and below, contains a cleartext storage of sensitive information vulnerability in its appsync module. An authenticated local attacker could potentially exploit this vulnerability, leading to information disclosure that could be used to access the appsync application with elevated privileges.

Insertion of sensitive information into log file in the Open CAS software for Linux maintained by Intel before version 22.6.2 may allow a privileged user to potentially enable information disclosure via local access.

Potential log injection in reset user endpoint in ckan

A user endpoint didn't perform filtering on an incoming parameter, which was added directly to the application log. This could lead to an attacker injecting false log entries or corrupt the log file format. This has been fixed in the CKAN versions 2.9.11 and 2.10.4. Users are advised to upgrade. Users unable to upgrade should override the `/user/reset` endpoint to filter the `id` parameter in order to exclude newlines.

Jenkins HashiCorp Vault Plugin 360.v0a_1c04cf807d and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log when push mode for durable task logging is enabled.

Insecure Variable Substitution in Vela

Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. **To exploit this** the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as insensitive. While Vela provides secrets masking, secrets exposure is not entirely solved by the masking process. A docker image (plugin) can easily expose secrets if they are not handled properly, or altered in some way. There is a responsibility on the end-user to understand how values injected into a plugin are used. This is a risk that exists for many CICD systems (like GitHub Actions) that handle sensitive runtime variables. Rather, the greater risk is that users who restrict a secret to the "no commands" option and use image restriction can still have their secret value exposed via substitution tinkering, which turns the image and command restrictions into a false sense of security. This issue has been addressed in version 0.23.2. Users are advised to upgrade. Users unable to upgrade should not provide sensitive values to plugins that can potentially expose them, especially in `parameters` that are not intended to be used for sensitive values, ensure plugins (especially those that utilize shared secrets) follow best practices to avoid logging parameters that are expected to be sensitive, minimize secrets with `pull_request` events enabled, as this allows users to change pipeline configurations and pull in secrets to steps not typically part of the CI process, make use of the build approval setting, restricting builds from untrusted users, and limit use of shared secrets, as they are less restrictive to access by nature.