Incomplete log sanitization during bulk IPsec policy collection in Brocade SANnav versions before 3.0.1a permit extension switch pre-shared keys to be written to system logs. Individuals with read access to container logs or support archives can obtain these keys, leading to the potential compromise of encrypted network tunnels.
The Botslab G980H dash camera firmware logs sensitive configuration data, including WiFi credentials, in diagnostic logs stored on removable media. These logs remain accessible after support operations, allowing an unauthenticated attacker with physical access to the storage to retrieve sensitive information. This vulnerability affects specific firmware versions of the device.
Improper handling of sensitive data during IPsec policy creation and modification in Brocade SANnav versions before 3.0.1a results in pre-shared keys being recorded in application logs. Individuals with read access to system log files or support bundles can view these credentials, leading to the potential exposure of keys used to secure network tunnels.
CVE-2026-82371 is a vulnerability in Brocade SANnav discovery service where sensitive authentication data is logged in plaintext. This allows individuals with read access to log files to retrieve administrative credentials and active session tokens. The flaw affects Brocade SANnav versions prior to 3.0.1a. Exploiting this vulnerability could lead to compromise of managed network infrastructure and unauthorized access to active application sessions.
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, ?LOG_DEBUG("shutting down Shovel '~ts', ... Shovel state: ~tp", [Name, State]) formats the entire state map. The 'uris' field holds plaintext URIs after credentials_obfuscation:decrypt (called in rabbit_shovel_util:deobfuscated_uris/2). No format_status/1,2 callback exists in rabbit_shovel_worker to redact it. Triggered when an autodelete shovel (src-delete-after = N) completes. With DEBUG logging enabled, autodelete-shovel completion writes the full shovel state map , including decrypted amqp://user:password@host/ URIs , to the broker log file. Preconditions include Shovel plugin enabled with URI-embedded credentials DEBUG log level (non-default) Autodelete shovel configuration Attacker has log read access. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
Dell Command Powershell Provider (DCPP), versions prior to 2.10.2 contain an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information Disclosure.
Jupyter Server versions prior to 2.21.0 contain a vulnerability where the Referer header is logged without scrubbing sensitive tokens during 5xx error responses. This can lead to sensitive tokens being stored in plaintext in server logs. An attacker with access to these logs could recover tokens and gain the affected user's permissions. The issue is fixed in version 2.21.0.
If logging mode is set to DEBUG or a malformed MongoDB connection string is used, application logs may collect sensitive information (if in use) such as passwords and AWS secure access keys.
Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.
The audit_log add-on builds each entry's extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4, which takes :actor from the action callback context verbatim. Any audited action invoked with actor: set to a user record therefore deposits that record, including its hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/1 and filters params against the strategy's configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute sensitive?: true does not help, because that redacts inspect/1 output rather than JSON encoding or raw-term storage.
There is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker's own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises Protocol.UndefinedError and drops the entry unless the user resource derives Jason.Encoder.
This issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.
OpenTelemetry-Go versions from 1.5.0 up to but not including 1.45.0 log detailed internal configuration information at the Info level when internal Info logging is enabled via otel.SetLogger. This can expose sensitive data such as OTLP collector endpoints, the OTLP HTTP Insecure flag, and full Zipkin collector URLs that may contain credentials or tokens. The default logger does not emit this event, and authentication headers, TLS keys, and span payloads are not logged. The issue is fixed in version 1.45.0.
CVE-2026-73457 is a vulnerability in Arista Networks EOS where gNPSI client credentials may be logged in clear text in local or remote accounting logs on affected versions. This exposure occurs when the gRPC Network Packet Sampling Interface (gNPSI) is enabled, potentially allowing authenticated users to access sensitive credential information. The vulnerability affects specific versions of EOS and has a medium severity rating with a CVSS score of 5.3.
CVE-2026-73442 is a vulnerability in Arista Networks EOS affecting versions 4.33.0 through 4.33.9M, 4.34.0 through 4.34.7M, 4.35.0 through 4.35.5M, and 4.36.0 through 4.36.1F. On platforms with VRRP enabled, the peer device VRRP authentication credentials are logged in cleartext. This allows an authenticated user with sufficient privileges to access agent trace logs or forwarded log outputs and obtain these credentials without needing access to the VRRP network segment. The CVSS 3.1 base score is 3.0, indicating low severity. There are no known exploits in the wild and no patch links provided in the input data.
CVE-2026-92237 is a vulnerability in Devolutions PowerShell Universal versions up to 2026.2.5 where sensitive information is inserted into log files by the slow query logging feature. Authenticated users with log read permissions can access application tokens, data protection keys, and other stored credentials via SQL parameter values recorded in system logs on Microsoft SQL Server-backed instances. The vulnerability has a medium severity rating with a CVSS score of 6.5.
CVE-2026-73467 is a vulnerability in Arista Networks EOS where plaintext shared secrets for configured TACACS+ servers may be inserted into log files under certain conditions. This exposure of sensitive information could lead to confidentiality, integrity, and availability impacts. The vulnerability affects multiple versions of EOS up to and including 4.36.1F. The CVSS 3.1 base score is 6.3, indicating a medium severity level. No vendor advisory or patch information is provided, so patch status is not confirmed.
CVE-2026-73466 is a vulnerability in Arista Networks EOS where user passwords may be logged in clear text under certain conditions. This occurs only when specialized non-standard debugging trace levels are explicitly enabled. Exploitation requires authenticated local administrative access to the device shell. Arista discovered this issue internally and is not aware of any active exploitation in the wild.
On affected platforms running Arista EOS, under certain circumstances plaintext private keys 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.
hashi-vault-js versions prior to 0.5.2 expose sensitive information in error messages. The module rethrows raw Axios errors containing request headers and bodies, which may include Vault tokens and secret data. Logging these errors can lead to plaintext exposure of credentials, risking unauthorized Vault access. The issue is fixed in version 0.5.2.
Description
When ZooKeeper authentication is configured, Storm deliberately retains
`storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then
served that configuration verbatim to any caller holding read-only topology permissions, so a user whose
only grant was the ability to view a topology received its ZooKeeper credential.
That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker
heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology
concerned. It is not a write credential on assignments.
The same advisory covers the submission client, which logged the generated payload at INFO on every
submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore
also reached any log aggregation or support bundle collected from the cluster.
Mitigation
Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no
longer written to logs.
Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing
topologies, review retained logs and support bundles for the value, and restrict read-only topology
permissions to trusted principals.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Insertion of sensitive information into log file vulnerability in Apache Syncope.
When AES key of non-standard length (not 16/24/32 bytes) is configured, Syncope will pad the provided value with random characters. The resulting key value is logged.
This issue affects Apache Syncope: from 3.0.15 through 3.0.16, from 4.0.3 through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.