Monthly
Progress MarkLogic Server deployments on Microsoft Azure running 12.x releases before 12.1.0 or 11.x releases before 11.3.7 can write security-sensitive authentication information into diagnostic logs under a specific, non-default configuration, allowing anyone with read access to those logs to harvest credentials or secrets and use them to reach protected cloud resources. The exposure is confidentiality-only: the vulnerability itself provides no code execution, integrity, or availability impact, and it is limited to Azure-hosted deployments - on-premises and other non-Azure installations appear out of scope. Exploitation requires an attacker to already have access to the diagnostic logs (through log storage, a log aggregation pipeline, or insider/lateral access) and requires the triggering configuration to be present; no public exploit code and no confirmed active exploitation were identified at time of analysis. Note that the vendor-published CVSS 3.1 vector (AV:N/AC:L/PR:N, 7.5) describes a remote unauthenticated attack, which conflicts with the description, CWE-532, and our assessed vector (AV:L/AC:H/PR:L, confidentiality-only), so the practical attack path should be treated as a log-access-dependent secret disclosure rather than an unauthenticated remote breach.
MarkLogic Server 11.x before 11.3.7 and 12.x before 12.1.0 can write security-sensitive values - information that enables access to protected resources - into diagnostic logs when the server is running in specific, non-default configurations. Anyone who can already read those logs (filesystem access, a log-aggregation/SIEM pipeline, backup or archive copies, or an account permitted to view logs) can harvest that data and use it to obtain unauthorized access, so the exposure is genuine but gated on two preconditions: a particular logging configuration must be present, and the attacker must already hold low-privileged log read access. No public exploit code or confirmed active exploitation (no CISA KEV listing) was identified at time of analysis, and the independent assessment rates this as a confidentiality-only, local-context issue (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), making it a moderate-priority hardening problem rather than an emergency despite the 8.1 vendor score.
Sensitive information is inserted into log files by the Apache Geode Web Management component in versions 2.0.0 through 2.0.2, so any party able to read those logs can recover the exposed confidential values (CWE-532, high confidentiality impact only). The NVD entry scores this 7.5 under CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, but our independent assessment applies AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - the practical constraint is obtaining access to the generated log output or a UI that surfaces it, so real-world exploitation is materially harder than the 7.5 network-vector score implies and authentication requirements are not settled by the available data. Exploitation is not confirmed actively exploited (CISA KEV does not list this CVE), no public exploit code has been identified at time of analysis, and EPSS is low at 0.17 percent (6th percentile), making this a moderate-priority information-disclosure issue rather than an urgent remote-compromise risk.
Certain ASUS router models write DDNS (dynamic DNS) account credentials into the readable system log, so an attacker who already holds high-privilege administrative access and sits on the same or an adjacent network segment (LAN/Wi-Fi) can harvest those secrets from the log and potentially redirect DNS settings. The exposure is confirmed by the vendor (ASUS) and rated 8.4 High under CVSS 4.0, but the prerequisite of authenticated management access plus network adjacency makes it a context-dependent, moderate-priority issue rather than a mass-exploitable one; no public exploit code has been identified at time of analysis and no CISA KEV listing applies. The leak only yields credentials on devices where DDNS is actually configured and enabled.
Dell Container Storage Modules releases before 1.18.0 write sensitive information into their log files, so a low-privileged, authenticated remote user who can read those logs can obtain credentials, tokens, or other confidential data recorded there. The issue carries a CVSS 3.1 base score of 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), inflated primarily by the scope change to components beyond the vulnerable module rather than by ease of mass exploitation. There is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing), so the practical risk is bounded by the prerequisite of existing low-privileged authentication plus read access to the module's log output.
Armatura One's backup and restore routine writes the complete database connection command - including the database superuser password in plaintext - into a log file stored on the host, so anyone able to read that log recovers credentials sufficient to take full control of the backend database. Exploitation is access-gated: it requires local access to the server operating system (CVSS vector AV:L/PR:L), the privilege to read the affected log, and a prior backup or restore operation to have actually populated the file with the credential, which makes the realistic risk post-compromise privilege escalation or insider abuse rather than remote attack. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue has been published through CISA's ICS advisory program (ICSA-26-274-01), indicating deployments in operational-technology and physical-security environments.
Workload secrets managed by Edgeless Systems' Contrast confidential-computing platform are written to Kubernetes pod logs, letting anyone with log-read access recover secrets that are meant to be visible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner. All Contrast releases up to and including 1.8.0 are affected whenever the Contrast initializer runs at the default CONTRAST_LOG_LEVEL of info (the same leak also occurs at debug), so installations that never customized the initializer log level are exposed by default; deployments that do not use workload secrets at all are unaffected. Recovering the leaked value requires low-privileged access - Kubernetes get or list permission on pods/logs (PR:L in the assessed vector) or read access to the underlying Kubernetes log storage - this is a passive confidentiality disclosure with no code execution, and no public exploit has been identified at time of analysis.
Workload secrets are written to the initializer's standard output at INFO level in Edgeless Systems Contrast versions 1.9.0 through 1.12.1, so any Kubernetes principal that holds get or list permission on the pods/logs subresource in the affected namespace can read them from the container log stream. Because those workload secrets back Contrast's encrypted storage and HashiCorp Vault integration, the storage keys and Vault credentials derived from them must also be treated as compromised, giving the attacker a path to decrypt protected data and reach Vault-backed secrets. The flaw is a regression of GHSA-h5f8-crrq-4pw8 (originally fixed in 1.8.1 but never ported to the main branch), patchable in 1.12.2; there is no public exploit identified at time of analysis and no KEV listing, so risk is driven by the low barrier of an existing log-read RBAC grant rather than by active exploitation.
Incomplete log sanitization in Brocade SANnav before 3.0.1a causes extension switch IPsec pre-shared keys (PSKs) to be written in cleartext to system logs during the bulk IPsec policy collection workflow, allowing any principal with read access to container logs or exported support archives to recover those keys and potentially compromise the IPsec-protected tunnels that rely on them. The issue is local and authenticated (CVSS 3.1 AV:L/AC:L/PR:L/UI:N, confidentiality-only per independent assessment), not remotely reachable, and it is tied specifically to that diagnostic collection path rather than to arbitrary attacker input; no public exploit code has been identified at time of analysis. The 8.4 CVSS 4.0 vendor score (which also asserts high integrity impact via VI:H) should not be used as the sole triage signal, since the practical outcome depends on the attacker both holding log/support-bundle read privileges and being able to reach and reuse the leaked PSKs against the switch fabric.
Pre-shared keys used for IPsec tunnel configuration are recorded in cleartext inside application log files by Brocade SANnav versions before 3.0.1a, so anyone who can read those logs or an exported support bundle can recover credentials that protect network tunnels. The exposure is triggered only when IPsec policies are actually created or modified in SANnav, and the assessed vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a local, authenticated precondition rather than anonymous remote reach, meaning an insider or a holder of an exported bundle is the realistic actor. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, so priority should be driven by the sensitivity of the logged keys and by how broadly log files and support bundles are shared; the vendor has addressed it in 3.0.1a.
Progress MarkLogic Server deployments on Microsoft Azure running 12.x releases before 12.1.0 or 11.x releases before 11.3.7 can write security-sensitive authentication information into diagnostic logs under a specific, non-default configuration, allowing anyone with read access to those logs to harvest credentials or secrets and use them to reach protected cloud resources. The exposure is confidentiality-only: the vulnerability itself provides no code execution, integrity, or availability impact, and it is limited to Azure-hosted deployments - on-premises and other non-Azure installations appear out of scope. Exploitation requires an attacker to already have access to the diagnostic logs (through log storage, a log aggregation pipeline, or insider/lateral access) and requires the triggering configuration to be present; no public exploit code and no confirmed active exploitation were identified at time of analysis. Note that the vendor-published CVSS 3.1 vector (AV:N/AC:L/PR:N, 7.5) describes a remote unauthenticated attack, which conflicts with the description, CWE-532, and our assessed vector (AV:L/AC:H/PR:L, confidentiality-only), so the practical attack path should be treated as a log-access-dependent secret disclosure rather than an unauthenticated remote breach.
MarkLogic Server 11.x before 11.3.7 and 12.x before 12.1.0 can write security-sensitive values - information that enables access to protected resources - into diagnostic logs when the server is running in specific, non-default configurations. Anyone who can already read those logs (filesystem access, a log-aggregation/SIEM pipeline, backup or archive copies, or an account permitted to view logs) can harvest that data and use it to obtain unauthorized access, so the exposure is genuine but gated on two preconditions: a particular logging configuration must be present, and the attacker must already hold low-privileged log read access. No public exploit code or confirmed active exploitation (no CISA KEV listing) was identified at time of analysis, and the independent assessment rates this as a confidentiality-only, local-context issue (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), making it a moderate-priority hardening problem rather than an emergency despite the 8.1 vendor score.
Sensitive information is inserted into log files by the Apache Geode Web Management component in versions 2.0.0 through 2.0.2, so any party able to read those logs can recover the exposed confidential values (CWE-532, high confidentiality impact only). The NVD entry scores this 7.5 under CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, but our independent assessment applies AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - the practical constraint is obtaining access to the generated log output or a UI that surfaces it, so real-world exploitation is materially harder than the 7.5 network-vector score implies and authentication requirements are not settled by the available data. Exploitation is not confirmed actively exploited (CISA KEV does not list this CVE), no public exploit code has been identified at time of analysis, and EPSS is low at 0.17 percent (6th percentile), making this a moderate-priority information-disclosure issue rather than an urgent remote-compromise risk.
Certain ASUS router models write DDNS (dynamic DNS) account credentials into the readable system log, so an attacker who already holds high-privilege administrative access and sits on the same or an adjacent network segment (LAN/Wi-Fi) can harvest those secrets from the log and potentially redirect DNS settings. The exposure is confirmed by the vendor (ASUS) and rated 8.4 High under CVSS 4.0, but the prerequisite of authenticated management access plus network adjacency makes it a context-dependent, moderate-priority issue rather than a mass-exploitable one; no public exploit code has been identified at time of analysis and no CISA KEV listing applies. The leak only yields credentials on devices where DDNS is actually configured and enabled.
Dell Container Storage Modules releases before 1.18.0 write sensitive information into their log files, so a low-privileged, authenticated remote user who can read those logs can obtain credentials, tokens, or other confidential data recorded there. The issue carries a CVSS 3.1 base score of 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), inflated primarily by the scope change to components beyond the vulnerable module rather than by ease of mass exploitation. There is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing), so the practical risk is bounded by the prerequisite of existing low-privileged authentication plus read access to the module's log output.
Armatura One's backup and restore routine writes the complete database connection command - including the database superuser password in plaintext - into a log file stored on the host, so anyone able to read that log recovers credentials sufficient to take full control of the backend database. Exploitation is access-gated: it requires local access to the server operating system (CVSS vector AV:L/PR:L), the privilege to read the affected log, and a prior backup or restore operation to have actually populated the file with the credential, which makes the realistic risk post-compromise privilege escalation or insider abuse rather than remote attack. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue has been published through CISA's ICS advisory program (ICSA-26-274-01), indicating deployments in operational-technology and physical-security environments.
Workload secrets managed by Edgeless Systems' Contrast confidential-computing platform are written to Kubernetes pod logs, letting anyone with log-read access recover secrets that are meant to be visible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner. All Contrast releases up to and including 1.8.0 are affected whenever the Contrast initializer runs at the default CONTRAST_LOG_LEVEL of info (the same leak also occurs at debug), so installations that never customized the initializer log level are exposed by default; deployments that do not use workload secrets at all are unaffected. Recovering the leaked value requires low-privileged access - Kubernetes get or list permission on pods/logs (PR:L in the assessed vector) or read access to the underlying Kubernetes log storage - this is a passive confidentiality disclosure with no code execution, and no public exploit has been identified at time of analysis.
Workload secrets are written to the initializer's standard output at INFO level in Edgeless Systems Contrast versions 1.9.0 through 1.12.1, so any Kubernetes principal that holds get or list permission on the pods/logs subresource in the affected namespace can read them from the container log stream. Because those workload secrets back Contrast's encrypted storage and HashiCorp Vault integration, the storage keys and Vault credentials derived from them must also be treated as compromised, giving the attacker a path to decrypt protected data and reach Vault-backed secrets. The flaw is a regression of GHSA-h5f8-crrq-4pw8 (originally fixed in 1.8.1 but never ported to the main branch), patchable in 1.12.2; there is no public exploit identified at time of analysis and no KEV listing, so risk is driven by the low barrier of an existing log-read RBAC grant rather than by active exploitation.
Incomplete log sanitization in Brocade SANnav before 3.0.1a causes extension switch IPsec pre-shared keys (PSKs) to be written in cleartext to system logs during the bulk IPsec policy collection workflow, allowing any principal with read access to container logs or exported support archives to recover those keys and potentially compromise the IPsec-protected tunnels that rely on them. The issue is local and authenticated (CVSS 3.1 AV:L/AC:L/PR:L/UI:N, confidentiality-only per independent assessment), not remotely reachable, and it is tied specifically to that diagnostic collection path rather than to arbitrary attacker input; no public exploit code has been identified at time of analysis. The 8.4 CVSS 4.0 vendor score (which also asserts high integrity impact via VI:H) should not be used as the sole triage signal, since the practical outcome depends on the attacker both holding log/support-bundle read privileges and being able to reach and reuse the leaked PSKs against the switch fabric.
Pre-shared keys used for IPsec tunnel configuration are recorded in cleartext inside application log files by Brocade SANnav versions before 3.0.1a, so anyone who can read those logs or an exported support bundle can recover credentials that protect network tunnels. The exposure is triggered only when IPsec policies are actually created or modified in SANnav, and the assessed vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a local, authenticated precondition rather than anonymous remote reach, meaning an insider or a holder of an exported bundle is the realistic actor. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, so priority should be driven by the sensitivity of the logged keys and by how broadly log files and support bundles are shared; the vendor has addressed it in 3.0.1a.