| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| spaces_plugin/app.py in SolidUI 0.4.0 has an unnecessary print statement for an OpenAI key. The printed string might be logged. |
| In affected versions of the Octopus Kubernetes worker or agent, sensitive variables could be written to the Kubernetes script pod log in clear-text. This was identified in Version 2 however it was determined that this could also be achieved in Version 1 and the fix was applied to both versions accordingly. |
| In Snowflake ODBC Driver before 3.7.0, in certain code paths, the Driver logged the whole SQL query at the INFO level, aka Insertion of Sensitive Information into a Log File. |
| Improper restriction of environment variables in Elastic Defend can lead to exposure of sensitive information such as API keys and tokens via automatic transmission of unfiltered environment variables to the stack. |
| The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, OCI, Helm repositories and S3-compatible buckets. The source-controller implements the source.toolkit.fluxcd.io API and is a core component of the GitOps toolkit. Prior to version 1.2.5, when source-controller was configured to use an Azure SAS token when connecting to Azure Blob Storage, the token was logged along with the Azure URL when the controller encountered a connection error. An attacker with access to the source-controller logs could use the token to gain access to the Azure Blob Storage until the token expires. This vulnerability was fixed in source-controller v1.2.5. There is no workaround for this vulnerability except for using a different auth mechanism such as Azure Workload Identity. |
|
A potential security vulnerability has been identified in HPE Compute Scale-up Server 3200 server. This vulnerability could cause disclosure of sensitive information in log files.
|
| Insertion of sensitive information into log file for some Intel(R) Local Manageability Service software before version 2316.5.1.2 may allow an authenticated user to potentially enable information disclosure via local access. |
| 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`. |
| 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. |
| Steeltoe is an open source project that provides a collection of libraries that helps users build production-grade cloud-native applications using externalized configuration, service discovery, distributed tracing, application management, and more. When utilizing multiple Eureka server service URLs with basic auth and encountering an issue with fetching the service registry, an error is logged with the Eureka server service URLs but only the first URL is masked. The code in question is `_logger.LogError(e, "FetchRegistry Failed for Eureka service urls: {EurekaServerServiceUrls}", new Uri(ClientConfig.EurekaServerServiceUrls).ToMaskedString());` in the `DiscoveryClient.cs` file which may leak credentials into logs. This issue has been addressed in version 3.2.8 of the Steeltoe.Discovery.Eureka nuget package. |
| Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. When debugging is enabled for Himmelblau in version 1.0.0, the himmelblaud_tasks service leaks an Intune service access token to the system journal. This short-lived token can be used to detect the host's Intune compliance status, and may permit additional administrative operations for the Intune host device (though the API for these operations is undocumented). This is fixed in version 1.1.0. To workaround this issue, ensure that Himmelblau debugging is disabled. |
| Para is a multitenant backend server/framework for object persistence and retrieval. A vulnerability that exists in versions prior to 1.50.8 exposes both access and secret keys in logs without redaction. These credentials are later reused in variable assignments for persistence but do not require logging for debugging or system health purposes. Version 1.50.8 fixes the issue. |
| 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. |
| 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. |
| An information disclosure vulnerability exists in Yugabyte Anywhere, where the LDAP bind password is logged in plaintext within application logs. This flaw results in the unintentional exposure of sensitive information in Yugabyte Anywhere logs, potentially allowing unauthorized users with access to these logs to view the LDAP bind password. An attacker with log access could exploit this vulnerability to gain unauthorized access to the LDAP server, leading to potential exposure or compromise of LDAP-managed resources
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. |
| 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. |
| AnyDesk through 8.1.0 on Windows, when Allow Direct Connections is enabled, inadvertently exposes a public IP address within network traffic. The attacker must know the victim's AnyDesk ID. |
| Kubernetes secrets-store-sync-controller in versions before 0.0.2 discloses service account tokens in logs. |
| Shared Access Signature token is not masked in the backup configuration response and is also exposed in the yb_backup logs |
| Information disclosure and exposure of authentication FTP credentials over the debug port 1604 in the MINOVA TTA service. This allows unauthenticated remote access to an active FTP account containing sensitive internal data and import structures. In environments where this FTP server is part of automated business processes (e.g. EDI or data integration), this could lead to data manipulation, extraction, or abuse. Debug ports 1602, 1603 and 1636 also expose service architecture information and system activity logs |
