Insertion of Sensitive Information into Log File

IBM UCD - IBM UrbanCode Deploy 7.2 through 7.2.3.23, and 7.3 through 7.3.2.18 and IBM UCD - IBM DevOps Deploy 8.0 through 8.0.1.13, 8.1 through 8.1.2.6, and 8.2 through 8.2.1.0 IBM DevOps Deploy stores potentially sensitive information in log files that could be read by a local user.Show less

Insertion of sensitive information into log files in Snowflake CLI versions prior to 3.19 allowed plaintext credentials to be written to persistent local debug logs. An attacker could exploit this by obtaining read access to the affected user's local log files, causing credentials such as passwords, tokens, or private key material to be exposed without additional application-level safeguards. Successful exploitation requires credentials to be present in the affected connection context and the resulting logs to be accessible from the local environment. The fix is available in Snowflake CLI version 3.19, and users must manually upgrade.Show less

HCL DevOps Deploy / HCL Launch is susceptible to an exposure of sensitive information vulnerability in output logs. This exposure could allow an attacker with access to the logs to potentially obtain sensitive values related to that step.Show less

HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a sensitive data exposure vulnerability which could allow an attacker to exploit application information to then attempt additional attacks and cause unknown behavior in the application.Show less

Mattermost Plugins versions <=11.6 10.18.11 11.3.6 11.6.5.0 fail to sanitize error responses from the OpenAI API before logging, which allows a user with access to server logs or support packets to obtain a valid or partially reconstructable OpenAI API key via inspection of mattermost.log entries generated during authentication failures. Mattermost Advisory ID: MMSA-2026-00609Show less

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 9.3 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed sensitive information to be written to application logs due to insufficient filtering in a CI/CD API endpoint.Show less

GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.1.1 that under certain conditions could have allowed a user to access sensitive information that had already been committed to a project, due to insufficient output filtering in Duo Workflows.Show less

A flaw was found in foreman-mcp-server. This component utilizes two distinct logging mechanisms that can expose sensitive session and authentication data. One mechanism logs session identifiers, which are treated as authentication credentials, at an informational level. The other, when debug logging is enabled, incompletely sanitizes HTTP request headers, leading to the cleartext logging of sensitive information such as authorization tokens and API keys. This vulnerability can result in a confidentiality breach, as sensitive authentication data is persisted in plain text within container logs, increasing the risk if logs are forwarded to a centralized platform.Show less

A flaw was found in the community.general Ansible collection's nexmo module. The module constructs HTTP requests to the Vonage/Nexmo SMS API by encoding API credentials (api_key and api_secret) into URL query parameters and sending them via GET requests. This causes credentials to be exposed in web server access logs, proxy logs, HTTP Referer headers, and network monitoring tools, despite the Ansible argument specification marking these parameters as no_log. An attacker with access to any of these logging or monitoring points can obtain the full API credentials and gain unauthorized access to the victim's Vonage/Nexmo account.Show less

Module: plugins/modules/keyring_info.py CVSS 3.1: 5.5 MEDIUM — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Issue: The module retrieves a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) and places it directly into result["passphrase"] with no output suppression, no no_log protection, and no documentation warning. Root Cause: Line 105 (protected): keyring_password=dict(type="str", required=True, no_log=True) Line 127 (NOT protected): result["passphrase"] = passphrase Observed Output: { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } Visible via register + debug: { "keyring_result": { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } } Impact: Master passwords, SSH key passphrases and service credentials appear in all Ansible output register: keyring_result followed by debug: var=keyring_result prints passphrase in full Ansible fact caching backends (Redis, JSON file, memcached) may persist the passphrase AWX/Tower job logs silently store the live credential Fix: module.exit_json(changed=False, passphrase=passphrase, _ansible_no_log=True) Also add a documentation warning requiring callers to use no_log: true at the task level. PoCs Fig 1: PoC execution showing passphrase in plaintext output Fig 2: Source code showing no_log=True on input (line 105) vs unprotected output (line 127)Show less

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.23.1rc0, the fix for CVE-2026-22778, which introduced a sanitize_message helper that strips object-repr memory addresses from error messages before they reach the client, is incomplete: several response paths echo str(exc) directly to clients without calling sanitize_message. The unsanitized sites include the Anthropic API router in vllm/entrypoints/anthropic/api_router.py (the POST /v1/messages and POST /v1/messages/count_tokens handlers), the Server-Sent Events streaming converter in vllm/entrypoints/anthropic/serving.py, and the realtime speech-to-text WebSocket in vllm/entrypoints/speech_to_text/realtime/connection.py. These paths catch the exception inside the route coroutine and construct the JSONResponse themselves, bypassing the sanitizing global FastAPI exception handler, and WebSocket frames do not traverse that handler chain at all. Using the same primitive as the parent issue, an unauthenticated attacker can send malformed image bytes through the Anthropic Messages API image content parts so that PIL.Image.open raises an UnidentifiedImageError whose message contains the BytesIO object repr, leaking the heap memory address verbatim in the error.message field of the response body. This vulnerability is fixed in 0.23.1rc0.Show less

An information exposure vulnerability in the Palo Alto Networks GlobalProtect app on macOS enables a local user to learn the configured passcodes for disabling, disconnecting, or uninstalling the GlobalProtect app. After the passcode is known, the user can perform these actions even if the GlobalProtect app configuration would not normally permit them to do so.Show less

MongoDB server may log authentication parameters, including credentials, to the server log during SASL authentication. When connection health metric logging is enabled, the full authentication parameters are written to the log without redaction.Show less

fabric-chaincode-java is a Java based implementation of Hyperledger Fabric chaincode shim APIs. From version 2.3.1 to before version 2.5.10, when chaincode is deployed in chaincode-as-a-service mode with TLS enabled, the chaincode server INFO level logging includes the TLS private key password in plaintext. An attacker with access to the chaincode server logs could recover the TLS private key password. If the attacker can also obtain the TLS private key, they could impersonate the chaincode server. This issue has been patched in version 2.5.10.Show less

OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI exports raw Redis error text as the span status message. Because Redis error replies can contain attacker-controlled or sensitive values, this behavior can exfiltrate tokens, PII, or other confidential input into telemetry backends and inject untrusted text into downstream analysis systems. This issue has been patched in version 0.9.0.Show less

A high security vulnerability affecting Security Center main server installations has been identified. It could allow an attacker with local OS privileges to the main server to access the Server Admin credentials. A third party hired by Genetec found the issue. There is currently no evidence of active exploitation. This vulnerability is associated with specific installation package builds rather than the product version identifier alone. Certain versions (including 5.10.4.0, 5.11.3.0, 5.12.2.0 and 5.13.3.0) were released with both vulnerable and remediated installation packages under the same version number. Consequently, version-based comparison alone is insufficient to determine exposure. Only installations performed using vulnerable builds are affected. Remediated builds can be distinguished using verified installation package hashes. For the complete list of fixed build hashes, refer to the security advisory section.Show less