Credential disclosure in syft when SYFT_ATTEST_PASSWORD environment variable set in syft

syft is a a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. A password disclosure flaw was found in Syft versions v0.69.0 and v0.69.1. This flaw leaks the password stored in the SYFT_ATTEST_PASSWORD environment variable. The `SYFT_ATTEST_PASSWORD` environment variable is for the `syft attest` command to generate attested SBOMs for the given container image. This environment variable is used to decrypt the private key (provided with `syft attest --key <path-to-key-file>`) during the signing process while generating an SBOM attestation. This vulnerability affects users running syft that have the `SYFT_ATTEST_PASSWORD` environment variable set with credentials (regardless of if the attest command is being used or not). Users that do not have the environment variable `SYFT_ATTEST_PASSWORD` set are not affected by this issue. The credentials are leaked in two ways: in the syft logs when `-vv` or `-vvv` are used in the syft command (which is any log level >= `DEBUG`) and in the attestation or SBOM only when the `syft-json` format is used. Note that as of v0.69.0 any generated attestations by the `syft attest` command are uploaded to the OCI registry (if you have write access to that registry) in the same way `cosign attach` is done. This means that any attestations generated for the affected versions of syft when the `SYFT_ATTEST_PASSWORD` environment variable was set would leak credentials in the attestation payload uploaded to the OCI registry. This issue has been patched in commit `9995950c70` and has been released as v0.70.0. There are no workarounds for this vulnerability. Users are advised to upgrade.

Argo CD leaks repository credentials in user-facing error messages and in logs

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All versions of Argo CD starting with v2.6.0-rc1 have an output sanitization bug which leaks repository access credentials in error messages. These error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI). The user must have `applications, create` or `applications, update` RBAC access to reach the code which may produce the error. The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository. If the user has `repositories, update` access, they may edit an existing repository to introduce a URL typo or otherwise force an error message. But if they have that level of access, they are probably intended to have access to the credentials anyway. A patch for this vulnerability has been released in version 2.6.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Server Response Disclosure in RapidDiag Salesforce.com Log File

In Splunk Enterprise versions below 9.0.8, the Splunk RapidDiag utility discloses server responses from external applications in a log file.

Sensitive information disclosure in AdminManager logging channel

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6, the software potentially exposes plaintext passwords for local native authentication Splunk users. This exposure could happen when you configure the Splunk Enterprise AdminManager log channel at the DEBUG logging level.

Sensitive information disclosure in REST_Calls logging channel

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6, the software potentially exposes sensitive HTTP parameters to the `_internal` index. This exposure could happen if you configure the Splunk Enterprise `REST_Calls` log channel at the DEBUG logging level.

Session Token Disclosure to Internal Log Files in Splunk Add-on Builder

In Splunk Add-on Builder versions below 4.1.4, the application writes user session tokens to its internal log files when you visit the Splunk Add-on Builder or when you build or edit a custom app or add-on.

IBM Security Key Lifecycle Manager information disclosure

IBM Security Guardium Key Lifecycle Manager 3.0, 3.0.1, 4.0, 4.1, and 4.1.1 could allow an authenticated user to obtain sensitive information from log files. IBM X-Force ID: 247602.

Arbitrary File Overwrite Vulnerability

A highly privileged account can overwrite arbitrary files on the system with log output. The log file path tags were not sanitized properly.

In Spring Vault, versions 3.0.x prior to 3.0.2 and versions 2.3.x prior to 2.3.3 and older versions, an application is vulnerable to insertion of sensitive information into a log file when it attempts to revoke a Vault batch token.

assisted-installer: Image Pull Secret leaked through log files

A vulnerability was found in OpenShift Assisted Installer. During generation of the Discovery ISO, image pull secrets were leaked as plaintext in the installation logs. An authenticated user could exploit this by re-using the image pull secret to pull container images from the registry as the associated user.

Sensitive information exposure in the logs of greader API in FreshRSS

FreshRSS is a self-hosted RSS feed aggregator. When using the greader API, the provided password is logged in clear in `users/_/log_api.txt` in the case where the authentication fails. The issues occurs in `authorizationToUser()` in `greader.php`. If there is an issue with the request or the credentials, `unauthorized()` or `badRequest()` is called. Both these functions are printing the return of `debugInfo()` in the logs. `debugInfo()` will return the content of the request. By default, this will be saved in `users/_/log_api.txt` and if the const `COPY_LOG_TO_SYSLOG` is true, in syslogs as well. Exploiting this issue requires having access to logs produced by FreshRSS. Using the information from the logs, a malicious individual could get users' API keys (would be displayed if the users fills in a bad username) or passwords.

smartCARS 3 Password Stored as plain text in Error Log

smartCARS 3 is flight tracking software. In version 0.5.8 and prior, all persons who have failed login attempts will have their password stored in error logs. This problem doesn't occur in version 0.5.9. As a workaround, delete the affected log file, and ensure one logs in correctly.

directus vulnerable to Insertion of Sensitive Information into Log File

Directus is a real-time API and App dashboard for managing SQL database content. Prior to version 9.23.3, the `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. This issue is patched in version 9.23.3.

WordPress Media Library Assistant plugin <= 3.00 - Unauthenticated Error Log Disclosure vulnerability

Unauthenticated Error Log Disclosure vulnerability in Media Library Assistant plugin <= 3.00 on WordPress.

Juiker app - Information Leakage

Juiker app stores debug logs which contains sensitive information to mobile external storage. An unauthenticated physical attacker can access these files to acquire partial user information such as personal contacts.

Veracode Scan Jenkins Plugin before 23.3.19.0, when the "Connect using proxy" option is enabled and configured with proxy credentials and when the Jenkins global system setting debug is enabled and when a scan is configured for remote agent jobs, allows users (with access to view the job log) to discover proxy credentials.

Sensitive information disclosure possible on misconfigured failed backups of non-H2 databases in gocd

GoCD is an open source continuous delivery server. In GoCD versions from 20.5.0 and below 23.1.0, if the server environment is not correctly configured by administrators to provide access to the relevant PostgreSQL or MySQL backup tools, the credentials for database access may be unintentionally leaked to admin alerts on the GoCD user interface. The vulnerability is triggered only if the GoCD server host is misconfigured to have backups enabled, but does not have access to the `pg_dump` or `mysqldump` utility tools to backup the configured database type (PostgreSQL or MySQL respectively). In such cases, failure to launch the expected backup utility reports the shell environment used to attempt to launch in the server admin alert, which includes the plaintext database password supplied to the configured tool. This vulnerability does not affect backups of the default on-disk H2 database that GoCD is configured to use. This issue has been addressed and fixed in GoCD 23.1.0. Users are advised to upgrade. Users unable to upgrade may disable backups, or administrators should ensure that the required `pg_dump` (PostgreSQL) or `mysqldump` (MySQL) binaries are available on the GoCD server when backups are triggered.

An issue was discovered in Acuant AsureID Sentinel before 5.2.149. It uses the root of the C: drive for the i-Dentify and Sentinel Installer log files, aka CORE-7362.

Logstash Insertion of Sensitive Information into Log File

An issue was identified by Elastic whereby sensitive information is recorded in Logstash logs under specific circumstances. The prerequisites for the manifestation of this issue are: * Logstash is configured to log in JSON format https://www.elastic.co/guide/en/logstash/current/running-logstash-command-line.html , which is not the default logging format. * Sensitive data is stored in the Logstash keystore and referenced as a variable in Logstash configuration.

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.1 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 281677.