CWE-532

Plik logu acer_cgi.log w firmware urządzenia jest dostępny bez uwierzytelnienia przez interfejs webowy i zawiera dane logowania w postaci jawnego tekstu. Umożliwia to nieautoryzowany dostęp do systemu przez atakującego zdalnie.

MySQL for PCF tiles 1.7.x before 1.7.10 were discovered to log the AWS access key in plaintext. These credentials were logged to the Service Backup component logs, and not the system log, thus were not exposed outside the Service Backup VM.

Podatność klasy CWE-532 (Insertion of Sensitive Information into Log File) w rodzinie macierzy Hitachi Virtual Storage Platform umożliwia lokalnym użytkownikom uzyskanie dostępu do wrażliwych informacji przechowywanych w plikach logów. Wysoki wynik CVSS 9.9 wynika z szerokiego zakresu wpływu (Scope: Changed) oraz możliwości naruszenia poufności, integralności i dostępności systemu.

Argo CD is a declarative continuous deployment for Kubernetes. Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored in`kubectl.kubernetes.io/last-applied-configuration` annotation. pull request #7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the `kubectl.kubernetes.io/last-applied-configuration` annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have `clusters, get` RBAC access. **Note:** In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive. The bug has been patched in versions 2.8.3, 2.7.14, and 2.6.15. Users are advised to upgrade. Users unable to upgrade should update/deploy cluster secret with `server-side-apply` flag which does not use or rely on `kubectl.kubernetes.io/last-applied-configuration` annotation. Note: annotation for existing secrets will require manual removal.

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.

Platforma agentic AI JunoClaw (oparta na Juno Network) przed wersją 0.x.y-security-1 przekazywała mnemonik BIP-39 (seed wallet) jako jawny parametr tekstowy w wywołaniach narzędzi MCP. Oznacza to, że klucz kryptograficzny do portfela był zapisywany w logach, telemetrii i ruchu sieciowym pomiędzy dostawcą LLM a procesem MCP.

W silniku wnioskowania vLLM (wersje od 0.8.3 do przed 0.14.1) błędnie przetworzone żądanie z nieprawidłowym obrazem powoduje wyciek adresu sterty do klienta, skutecznie redukując ochronę ASLR. Podatność może być łączona z przepełnieniem sterty w dekoderze JPEG2000 (OpenCV/FFmpeg), co prowadzi do zdalnego wykonania kodu (RCE).

Plugin CE21 Suite dla WordPress (do wersji 2.3.1 włącznie) zapisuje wrażliwe dane, w tym dane uwierzytelniające, w publicznie dostępnym pliku logu. Nieuwierzytelniony atakujący może odczytać te dane i przejąć konta innych użytkowników, w tym administratorów.

W platformie Valtimo token dostępowy JWT zalogowanego użytkownika jest przesyłany do zewnętrznego serwisu `api.form.io` w nagłówku `x-jwt-token` wskutek błędnej konfiguracji komponentu Form.io. Atakujący, który przechwyci ten token, może pozyskać dane osobowe użytkownika lub wykonywać żądania do API Valtimo w jego imieniu.

A Session ID leak in the DEBUG log file in Graylog before 4.1.2 allows attackers to escalate privileges (to the access level of the leaked session ID).

A Session ID leak in the audit log in Graylog before 4.1.2 allows attackers to escalate privileges (to the access level of the leaked session ID).

In the Orbitz application 19.31.1 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.

In the Seesaw Parent and Family application 6.2.5 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.

In the Rapid Gator application 0.7.1 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.

In the PowerSchool Mobile application 1.1.8 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.

In the DoorDash application through 11.5.2 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.

In the Dark Horse Comics application 1.3.21 for Android, token information (equivalent to the username and password) is stored in the log during authentication, and may be available to attackers via logcat.

A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user's credentials from the log files.

An issue was discovered in Gallagher Command Centre 8.10 before 8.10.1092(MR2). Upon an upgrade, if a custom service account is in use and the visitor management service is installed, the Windows username and password for this service are logged in cleartext to the Command_centre.log file.

A vulnerability was found in Undertow web server before 2.0.21. An information exposure of plain text credentials through log files because Connectors.executeRootHandler:402 logs the HttpServerExchange object at ERROR level using UndertowLogger.REQUEST_LOGGER.undertowRequestFailed(t, exchange)