| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| Fujitsu / Fsas Technologies ETERNUS SF ACM/SC/Express (DX / AF Management Software) before 16.8-16.9.1 PA 2025-12, when collected maintenance data is accessible by a principal/authority other than ETERNUS SF Admin, allows an attacker to potentially affect system confidentiality, integrity, and availability. |
| 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. |
| 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. |
| Microsoft Identity Web is a library which contains a set of reusable classes used in conjunction with ASP.NET Core for integrating with the Microsoft identity platform (formerly Azure AD v2.0 endpoint) and AAD B2C. This vulnerability affects confidential client applications, including daemons, web apps, and web APIs. Under specific circumstances, sensitive information such as client secrets or certificate details may be exposed in the service logs of these applications. Service logs are intended to be handled securely. Service logs generated at the information level or credential descriptions containing local file paths with passwords, Base64 encoded values, or Client secret. Additionally, logs of services using Base64 encoded certificates or certificate paths with password credential descriptions are also affected if the certificates are invalid or expired, regardless of the log level. Note that these credentials are not usable due to their invalid or expired status. To mitigate this vulnerability, update to Microsoft.Identity.Web 3.8.2 or Microsoft.Identity.Abstractions 9.0.0. |
| 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. |
| 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. |
| A vulnerability exists in Docker Desktop prior to version 4.39.0 that could lead to the unintentional disclosure of sensitive information via application logs. In affected versions, proxy configuration data—potentially including sensitive details—was written to log files in clear text whenever an HTTP GET request was made through a proxy. An attacker with read access to these logs could obtain the proxy information and leverage it for further attacks or unauthorized access. Starting with version 4.39.0, Docker Desktop no longer logs the proxy string, thereby mitigating this risk. |
| The SAP NetWeaver Application Server ABAP and ABAP Platform Internet Communication Manager (ICM) permits authorized users with admin privileges and local access to log files to read sensitive information, resulting in information disclosure. This leads to high impact on the confidentiality of the application, with no impact on integrity or availability. |
| 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. |
| Certain errors of the upstream libraries will insert sensitive information in the OTRS or ((OTRS)) Community Edition log mechanism and mails send to the system administrator.
This issue affects:
* OTRS 7.0.X
* OTRS 8.0.X
* OTRS 2023.X
* OTRS 2024.X
* ((OTRS)) Community Edition: 6.0.x
Products based on the ((OTRS)) Community Edition also very likely to be affected |
| kanidim-provision is a helper utility that uses kanidm's API to provision users, groups and oauth2 systems. Prior to version 1.2.0, a faulty function intrumentation in the (optional) kanidm patches provided by kandim-provision will cause the provisioned admin credentials to be leaked to the system log. This only impacts users which both use the provided patches and provision their `admin` or `idm_admin` account credentials this way. No other credentials are affected. Users should recompile kanidm with the newest patchset from tag `v1.2.0` or higher. As a workaround, the user can set the log level `KANIDM_LOG_LEVEL` to any level higher than `info`, for example `warn`. |
| An issue was discovered in Westermo WeOS 5 (5.24 through 5.24.4). A threat actor potentially can gain unauthorized access to sensitive information via system logging information (syslog verbose logging that includes credentials). |
| Insertion of sensitive information into log file issue exists in "region PAY" App for Android prior to 1.5.28. If exploited, sensitive user information may be exposed to an attacker who has access to the application logs. |
| @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. |
| Insertion of Sensitive Information into Log File vulnerability in Hitachi Virtual Storage Platform, Hitachi Virtual Storage Platform VP9500, Hitachi Virtual Storage Platform G1000, G1500, Hitachi Virtual Storage Platform F1500, Hitachi Virtual Storage Platform 5100, 5500, 5100H, 5500H, Hitachi Virtual Storage Platform 5200, 5600, 5200H, 5600H, Hitachi Unified Storage VM, Hitachi Virtual Storage Platform G100, G200, G400, G600, G800, Hitachi Virtual Storage Platform F400, F600, F800, Hitachi Virtual Storage Platform G130, G150, G350, G370, G700, G900, Hitachi Virtual Storage Platform F350, F370, F700, F900, Hitachi Virtual Storage Platform E390, E590, E790, E990, E1090, E390H, E590H, E790H, E1090H allows
local users to gain sensitive information.This issue affects Hitachi Virtual Storage Platform: before DKCMAIN Ver. 70-06-74-00/00, SVP Ver. 70-06-58/00; Hitachi Virtual Storage Platform VP9500: before DKCMAIN Ver. 70-06-74-00/00, SVP Ver. 70-06-58/00; Hitachi Virtual Storage Platform G1000, G1500: before DKCMAIN Ver. 80-06-92-00/00, SVP Ver. 80-06-87/00; Hitachi Virtual Storage Platform F1500: before DKCMAIN Ver. 80-06-92-00/00, SVP Ver. 80-06-87/00; Hitachi Virtual Storage Platform 5100, 5500,5100H, 5500H: before DKCMAIN Ver. 90-08-81-00/00, SVP Ver. 90-08-81/00, before DKCMAIN Ver. 90-08-62-00/00, SVP Ver. 90-08-62/00, before DKCMAIN Ver. 90-08-43-00/00, SVP Ver. 90-08-43/00; Hitachi Virtual Storage Platform 5200, 5600,5200H, 5600H: before DKCMAIN Ver. 90-08-81-00/00, SVP Ver. 90-08-81/00, before DKCMAIN Ver. 90-08-62-00/00, SVP Ver. 90-08-62/00, before DKCMAIN Ver. 90-08-43-00/00, SVP Ver. 90-08-43/00; Hitachi Unified Storage VM: before DKCMAIN Ver. 73-03-75-X0/00, SVP Ver. 73-03-74/00, before DKCMAIN Ver. 73(75)-03-75-X0/00, SVP Ver. 73(75)-03-74/00; Hitachi Virtual Storage Platform G100, G200, G400, G600, G800: before DKCMAIN Ver. 83-06-19-X0/00, SVP Ver. 83-06-20-X0/00, before DKCMAIN Ver. 83-05-47-X0/00, SVP Ver. 83-05-51-X0/00; Hitachi Virtual Storage Platform F400, F600, F800: before DKCMAIN Ver. 83-06-19-X0/00, SVP Ver. 83-06-20-X0/00, before DKCMAIN Ver. 83-05-47-X0/00, SVP Ver. 83-05-51-X0/00; Hitachi Virtual Storage Platform G130, G150, G350, G370, G700, G900: before DKCMAIN Ver. 88-08-09-XX/00, SVP Ver. 88-08-11-X0/02; Hitachi Virtual Storage Platform F350, F370, F700, F900: before DKCMAIN Ver. 88-08-09-XX/00, SVP Ver. 88-08-11-X0/02; Hitachi Virtual Storage Platform E390, E590, E790, E990, E1090, E390H, E590H, E790H, E1090H: before DKCMAIN Ver. 93-06-81-X0/00, SVP Ver. 93-06-81-X0/00, before DKCMAIN Ver. 93-06-62-X0/00, SVP Ver. 93-06-62-X0/00, before DKCMAIN Ver. 93-06-43-X0/00, SVP Ver. 93-06-43-X0/00.
|
| 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. |
| Passwords are stored in clear-text logs. An attacker can retrieve passwords. As for the affected products/models/versions, see the reference URL. |
| Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password.
This is only exploitable if:
1) Logging is enabled;
2) Redis is using password authentication;
3) Those logs are accessible to an attacker, who can reach that redis instance.
**Note:**
It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password. |
| CWE-532: Insertion of Sensitive Information into Log Files vulnerability exists that could cause the disclosure
of FTP server credentials when the FTP server is deployed, and the device is placed in debug mode by an
administrative user and the debug files are exported from the device. |
