CWE-532

iDrive RemotePC before 7.6.48 on Windows allows information disclosure. A locally authenticated attacker can read the system’s Personal Key in world-readable %PROGRAMDATA% log files.

A flaw was found in several ansible modules, where parameters containing credentials, such as secrets, were being logged in plain-text on managed nodes, as well as being made visible on the controller node when run in verbose mode. These parameters were not protected by the no_log feature. An attacker can take advantage of this information to steal those credentials, provided when they have access to the log files containing them. The highest threat from this vulnerability is to data confidentiality. This flaw affects Red Hat Ansible Automation Platform in versions before 1.2.2 and Ansible Tower in versions before 3.8.2.

A flaw was found in the AMQ Broker that discloses JDBC encrypted usernames and passwords when provided in the AMQ Broker application logfile when using the jdbc persistence functionality. Versions shipped in Red Hat AMQ 7 are vulnerable.

TYPO3 is an open source PHP based web content management system. In versions 9.0.0 through 9.5.27, 10.0.0 through 10.4.17, and 11.0.0 through 11.3.0, user credentials may been logged as plain-text. This occurs when explicitly using log level debug, which is not the default configuration. TYPO3 versions 9.5.28, 10.4.18, 11.3.1 contain a patch for this vulnerability.

Nextcloud server is an open source, self hosted personal cloud. In affected versions logging of exceptions may have resulted in logging potentially sensitive key material for the Nextcloud Encryption-at-Rest functionality. It is recommended that the Nextcloud Server is upgraded to 20.0.12, 21.0.4 or 22.1.0. If upgrading is not an option users are advised to disable system logging to resolve this issue until such time that an upgrade can be performed Note that ff you do not use the Encryption-at-Rest functionality of Nextcloud you are not affected by this bug.

check-spelling is a github action which provides CI spell checking. In affected versions and for a repository with the [check-spelling action](https://github.com/marketplace/actions/check-spelling) enabled that triggers on `pull_request_target` (or `schedule`), an attacker can send a crafted Pull Request that causes a `GITHUB_TOKEN` to be exposed. With the `GITHUB_TOKEN`, it’s possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository. As a workaround users may can either: [Disable the workflow](https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow) until you’ve fixed all branches or Set repository to [Allow specific actions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#allowing-specific-actions-to-run). check-spelling isn’t a verified creator and it certainly won’t be anytime soon. You could then explicitly add other actions that your repository uses. Set repository [Workflow permissions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#setting-the-permissions-of-the-github_token-for-your-repository) to `Read repository contents permission`. Workflows using `check-spelling/check-spelling@main` will get the fix automatically. Workflows using a pinned sha or tagged version will need to change the affected workflows for all repository branches to the latest version. Users can verify who and which Pull Requests have been running the action by looking up the spelling.yml action in the Actions tab of their repositories, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml – you can filter PRs by adding ?query=event%3Apull_request_target, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml?query=event%3Apull_request_target.