| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| canonical/get-workflow-version-action is a GitHub composite action to get commit SHA that GitHub Actions reusable workflow was called with. Prior to 1.0.1, if the get-workflow-version-action step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated—causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs. Anyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs. The opportunity to exploit this vulnerability is limited—the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Users using the github-token input are impacted. This vulnerability is fixed in 1.0.1. |
| traQ is a messenger application built for Digital Creators Club traP. Prior to version 3.25.0, a vulnerability exists where sensitive information, such as OAuth tokens, are recorded in log files when an error occurs during the execution of an SQL query. An attacker could intentionally trigger an SQL error by methods such as placing a high load on the database. This could allow an attacker who has the authority to view the log files to illicitly acquire the recorded sensitive information. This vulnerability has been patched in version 3.25.0. If upgrading is not possible, a temporary workaround involves reviewing access permissions for SQL error logs and strictly limiting access to prevent unauthorized users from viewing them. |
| Insertion of Sensitive Information into Log File vulnerability in StylemixThemes Masterstudy LMS Starter.This issue affects Masterstudy LMS Starter: from n/a through 1.1.8. |
| An information disclosure vulnerability exists in the backup configuration process where the SAS token is not masked in the configuration response. This oversight results in sensitive information leakage within the yb_backup log files, exposing the SAS token in plaintext. The leakage occurs during the backup procedure, leading to potential unauthorized access to resources associated with the SAS token. This issue affects YugabyteDB Anywhere: from 2.20.0.0 before 2.20.7.0, from 2.23.0.0 before 2.23.1.0, from 2024.1.0.0 before 2024.1.3.0. |
| In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment. This vulnerability is patched in CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.
For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first.
Environment variables are exposed only from workflow runs that satisfy all of the following conditions:
- Code scanning workflow configured to scan the Java/Kotlin languages.
- Running in a repository containing Kotlin source code.
- Running with debug artifacts enabled.
- Using CodeQL Action versions <= 3.28.2, and CodeQL CLI versions >= 2.9.2 (May 2022) and <= 2.20.2.
- The workflow run fails before the CodeQL database is finalized within the `github/codeql-action/analyze` step.
- Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.
The `GITHUB_TOKEN` exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above:
- Using CodeQL Action versions >= 3.26.11 (October 2024) and <= 3.28.2, or >= 2.26.11 and < 3.
- Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).
In rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory GHSA-gqh3-9prg-j95m for more details.
In CodeQL CLI versions >= 2.9.2 and <= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. This is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories.
On Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.
The intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.
Therefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the `GITHUB_TOKEN` and any user-configured secrets made available via environment variables.
The impact of the `GITHUB_TOKEN` leaked in this environment is limited:
- For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions >= 3.26.11 and <= 3.28.2, or >= 2.26.11 and < 3, which in turn use the `actions/artifacts v4` library, the debug artifact is uploaded before the workflow job completes. During this time the `GITHUB_TOKEN` is still valid, providing an opportunity for attackers to gain access to the repository.
- For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked `GITHUB_TOKEN` has been revoked and cannot be used to access the repository. |
| Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Starting in version 0.7.0 and prior to versions 0.7.15 and 0.8.3, Himmelblau is vulnerable to leaking credentials in debug logs. When debug logging is enabled, user access tokens are inadvertently logged, potentially exposing sensitive authentication data. Similarly, Kerberos Ticket-Granting Tickets (TGTs) are logged when debug logging is enabled. Both issues pose a risk of exposing sensitive credentials, particularly in environments where debug logging is enabled. Himmelblau versions 0.7.15 and 0.8.3 contain a patch that fixes both issues. Some workarounds are available for users who are unable to upgrade. For the **logon compliance script issue**, disable the `logon_script` option in `/etc/himmelblau/himmelblau.conf`, and avoid using the `-d` flag when starting the `himmelblaud` daemon. For the Kerberos CCache issue, one may disable debug logging globally by setting the `debug` option in `/etc/himmelblau/himmelblau.conf` to `false` and avoiding the `-d` parameter when starting `himmelblaud`. |
| The Woo Manage Fraud Orders plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.6.1 through publicly exposed log files. This makes it possible for unauthenticated attackers to view potentially sensitive information about users contained in the exposed log files. |
| @backstage/plugin-scaffolder-backend is the backend for the default Backstage software templates. Prior to version 2.1.1, duplicate logging of the input values in the fetch:template action in the Scaffolder meant that some of the secrets were not properly redacted. If ${{ secrets.x }} is not passed through to fetch:template there is no impact. This issue has been resolved in 2.1.1 of the scaffolder-backend plugin. A workaround for this issue involves Template Authors removing the use of ${{ secrets }} being used as an argument to fetch:template. |
| PCL (Plain Craft Launcher) Community Edition is a Minecraft launcher. In PCL CE versions 2.12.0-beta.5 to 2.12.0-beta.9, the login credentials used during the third-party login process are accidentally recorded in the local log file. Although the log file is not automatically uploaded or shared, if the user manually sends the log file, there is a risk of leakage. This is fixed in version 2.12.0-beta.10. |
| Rucio is a software framework that provides functionality to organize, manage, and access large volumes of scientific data using customizable policies. The common Rucio helm-charts for the `rucio-server`, `rucio-ui`, and `rucio-webui` define the log format for the apache access log of these components. The `X-Rucio-Auth-Token`, which is part of each request header sent to Rucio, is part of this log format. Thus, each access log line potentially exposes the credentials (Internal Rucio token, or JWT in case of OIDC authentication) of the user. Due to the length of the token (Especially for a JWT) the tokens are often truncated, and thus not usable as credential; nevertheless, the (partial) credential should not be part of the logfile. The impact of this issue is amplified if the access logs are made available to a larger group of people than the instance administrators themselves. An updated release has been supplied for the `rucio-server`, `rucio-ui` and `rucio-webui` helm-chart. The change was also retrofitted for the currently supported Rucio LTS releases. The patched versions are rucio-server 37.0.2, 35.0.1, and 32.0.1; rucio-ui 37.0.4, 35.0.1, and 32.0.2; and rucio-webui 37.0.2, 35.1.1, and 32.0.1. As a workaround, one may update the `logFormat` variable and remove the `X-Rucio-Auth-Token`. |
| wire-ios is an iOS client for the Wire secure messaging application. From Wire iOS 3.111.1 to before 3.124.1, messages that were visible in the view port have been logged to the iOS system logs in clear text. Wire application logs created and managed by the application itself were not affected, especially not the logs users can export and send to Wire support. The iOS logs can only be accessed if someone had (physical) access to the underlying unlocked device. The issue manifested itself by calling canOpenUrl() and passing an invalid URL object. When iOS then performs the check and fails, it logs the contents to the system log. This is not documented behaviour. Wire released an emergency fix with version 3.124.1. As a workaround, users can reset their iOS device to remove the offending logs. Since Wire cannot access or modify iOS system logs, there's no other workaround other than a reset. |
| zot is ancontainer image/artifact registry based on the Open Container Initiative Distribution Specification. Prior to version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f), when using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup. Version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f) fixes the issue. |
| A problem with the Palo Alto Networks Cortex XDR Microsoft 365 Defender Pack can result in exposure of user credentials in application logs. Normally, these application logs are only viewable by local users and are included when generating logs for troubleshooting purposes. This means that these credentials are exposed to recipients of the application logs. |
| Metabase is an open source Business Intelligence and Embedded Analytics tool. When admins change Snowflake connection details in Metabase (either updating a password or changing password to private key or vice versa), Metabase would not always purge older Snowflake connection details from the application database. In order to remove older and stale connection details, Metabase would try one connection method at a time and purge all the other connection methods from the application database. When Metabase found a connection that worked, it would log (log/infof "Successfully connected, migrating to: %s" (pr-str test-details)) which would then print the username and password to the logger. This is fixed in 52.17.1, 53.9.5 and 54.1.5 in both the OSS and enterprise editions. Versions 51 and lower are not impacted. |
| Insertion of sensitive information into log file for some Intel(R) Local Manageability Service software before version 2514.7.16.0 may allow an authenticated user to potentially enable information disclosure via local access. |
| NVIDIA Omniverse Launcher for Windows and Linux contains a vulnerability in the launcher logs, where a user could cause sensitive information to be written to the log files through proxy servers. A successful exploit of this vulnerability might lead to information disclosure. |
| A flaw exists in FlashArray whereby the Key Encryption Key (KEK) is logged during key rotation when RDL is configured. |
| NVIDIA Cumulus Linux and NVOS products contain a vulnerability, where hashed user passwords are not properly suppressed in log files, potentially disclosing information to unauthorized users. |
| In Splunk Add-on for Palo Alto Networks versions below 2.0.2, the add-on exposes client secrets in plain text in the _internal index during the addition of new “Data Security Accounts“. 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. 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) in the Splunk documentation for more information. |
| Buildx is a Docker CLI plugin that extends build capabilities using BuildKit.
Cache backends support credentials by setting secrets directly as attribute values in cache-to/cache-from configuration. When supplied as user input, these secure values may be inadvertently captured in OpenTelemetry traces as part of the arguments and flags for the traced CLI command. OpenTelemetry traces are also saved in BuildKit daemon's history records.
This vulnerability does not impact secrets passed to the Github cache backend via environment variables or registry authentication. |
