Logging Redactor: PII data in str/repr of non primitive objects was not being redacted

Logging Redactor is a Python library designed to redact sensitive data in logs based on regex patterns and / or dictionary keys. Prior to 0.0.7, personally identifiable information returned by custom object __str__ or __repr__ methods is not redacted when such non-primitive objects are logged, causing sensitive values to appear in logs that are expected to mask them. This issue is fixed in version 0.0.7.

Vikunja before 2.7.1 Link-Share Hash Exposure via Request Path Logging

Vikunja before 2.7.1 contains an information exposure vulnerability that allows log readers to obtain link-share hashes because the request logger records the raw URI of the /shares/:share/auth route. Attackers with access to Vikunja or reverse proxy access logs can reuse non-expiring, non-password-protected share hashes to obtain a project JWT with read, write or admin permission.

IBM MQ is affected by a pasword disclosure vulnerability in the runmqccred utility

IBM MQ 9.2.0.0 through 9.2.0.44 LTS, 9.3.0.0 through 9.3.0.42 LTS, 9.4.0.0 through 9.4.0.26 LTS, 9.4.0.0 through 9.4.5.1 CD, and 10.0.0.0 through 10.0.0.5 LTS and CD stores potentially sensitive information in log files that could be read by a local user.

Vikunja before 2.7.1 Sensitive Token Exposure via URL Query in Access Logs

Vikunja before 2.7.1 embeds live password-reset, email-confirmation and account-deletion tokens in the URL query string of emailed links, so the full request URI, including the token, is written to Vikunja's HTTP access log and any reverse-proxy logs when a user clicks the link. Attackers with read access to those logs can replay an unredeemed password-reset token to take over the account or an account-deletion token to confirm the deletion.

Exposure of Sensitive Environment Variables in Session Event Logs

In JetBrains Junie CLI before 26.6.29 sensitive environment variables were exposed in session event logs

Information Disclosure Vulnerability in Tata Motors iRA and iRA.ev mobile application

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.

OAuth and OIDC tokens written unredacted to server logs by the Generic OAuth, Google and GitLab connectors

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.

Community.general: community.general nexmo — api credentials exposed in get url query string[security] community.general nexmo — api credentials exposed in get url query string

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.

Community.general: community.general keyring_info — os keyring passphrase returned in plaintext

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)

Clevis: clevis: pkcs#11 luks passphrase logged in plaintext to world-readable file

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.

Ansible-core: exposure of sensitive information in ansible vault files due to improper logging

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 exposes shared passwords in logs

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.

Privilege Escalation through Exposure of Invitation Code in Octopus Server Audit Log

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 logs can expose stored third-party credentials

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 Threat Response.

Tanium addressed an insertion of sensitive information into log file vulnerability in Reputation.

Tanium addressed an insertion of sensitive information into log file vulnerability in Reputation.

macOS Logging Redaction Improper – Sensitive Data Exposure

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 Sensitive Information Exposure via Application Logs

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.

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.