| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| This vulnerability exists in the iRA 2.0 and iRA.ev mobile applications due to the recording of authentication tokens in application logs used for development and debugging. A local attacker with an access to logs could exploit this vulnerability by retrieving and misusing the exposed session tokens.
Successful exploitation of this vulnerability could allow the attacker to impersonate the associated user and gain unauthorized access to vehicle related information and services. |
| OpenHuman is an open-source agent harness available as a desktop application and Rust library. In affected versions before 0.57.5, the approval gate uses the JSON-RPC bearer token as an approval session identifier. This exposes the credential through persisted approval records, events, debug logs, and RPC responses, including during normal desktop operation. An attacker who obtains these artifacts can recover the token and access the core RPC interface while it remains valid. This can expose sensitive agent and integration data and permit privileged operations. Stable tokens remain usable until rotated; launch-specific tokens remain usable while the corresponding core instance is active. The fix is included in version 0.57.5. |
| A user with read access to Grafana's server logs, or to a log store they are shipped to, can recover the OAuth and OIDC access, refresh and ID tokens of users who sign in through the Generic OAuth, Google or GitLab providers. Grafana writes these tokens to its logs unredacted when an access or ID token is not a valid JWT, when the ID token is missing (at debug level) or is not a string (exposure of sensitive information in log files). The exposure is bounded by the scopes granted to the configured OAuth client. |
| 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. |
| 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) |
| A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon logs LUKS disk encryption passphrases in plaintext to a log file. The log file is created without restrictive permissions, making it world-readable under the default process umask. A local attacker can read the log file to obtain the LUKS passphrase. |
| A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions. |
| Element Call is a native Matrix video conferencing application. From 0.16.0 until 0.20.3, the standalone Element Call `SPA` logs the `password` URL query parameter. When a user submits an error report, called a rageshake, these logs are shared with the application operator. Users can therefore unintentionally disclose the shared `password` used to encrypt the call, potentially compromising call confidentiality. Avoiding submission of bug reports or debug logs prevents this disclosure path in affected versions. Upgrading does not remove secrets from previously collected `rageshakes`, which require separate cleanup by the log-server operator. This issue is fixed in version 0.20.3. |
| In affected versions of Octopus Server, creating a user invitation writes the invitation code to the audit event log. When the invitation is linked to a space, a user in that space with appropriate permissions could read the code from the audit event. Successfully exploiting this by redeeming the unclaimed invitation could allow the user to escalate privileges however this is dependant on the permissions assigned for the invited user. |
| Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials. These OAuth tokens are not Docker account tokens. Docker Desktop 4.94.0 and 4.95.0 addressed the known logging paths, but logs containing credentials can remain after upgrading. Docker Desktop 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Threat Response. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Reputation. |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to access sensitive user data. |
| OpenPanel before 3.0.0 contains an information exposure vulnerability that writes database connection URLs and email template data to standard output logs. Users with log access can obtain database credentials from migration startup logs and password-reset tokens logged when SMTP_HOST and RESEND_API_KEY are unset. |
| 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. |
| Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. Prior to 0.29.0, the Kubernetes protocol listener uses AcceptAnyClientCert in warpgate-protocol-kubernetes/src/server/client_certs.rs to accept certificates at the TLS layer and defer validation to warpgate-protocol-kubernetes/src/server/auth.rs, where authentication and lookup failures are rendered verbatim in an HTTP 500 response body. The Kubernetes application in warpgate-protocol-kubernetes/src/server/mod.rs lacks the outer request-logging wrapper used by the HTTP protocol, and failures in warpgate-protocol-kubernetes/src/server/handlers.rs can short-circuit before its inner log point. An unauthenticated network client can therefore induce failures and receive ASN.1/DER parser diagnostics or sea_orm database errors without the attempt being recorded in the gateway log. The disclosed information is limited to internal diagnostics, and no user-data, integrity, or availability impact is established. This issue is fixed in version 0.29.0. |
| A logging issue was addressed with improved data redaction. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. A malicious application may be able to bypass Privacy preferences. |
| On affected platforms running Arista EOS, under certain circumstances user passwordss may be written in clear text to log files during operations when specialized non-standard debugging trace levels are explicitly enabled.
To exploit these vulnerabilities, a malicious actor must already possess authenticated local administrative access to the device shell, and specialized non-standard debugging trace levels must be explicitly enabled.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks. |
| 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. |
| Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly. |
