Cloudera Manager 5.x before 5.7.1 places Sensitive Data in cleartext Readable Files.
Cloudera Manager before 4.8.3 and 5.x before 5.0.1 allows remote authenticated users to obtain sensitive configuration information via the API.
IBM Big SQL on IBM Cloud Pak for Data 7.1.0, 7.1.1, 7.2.0, and 7.2.3 could allow an authenticated user with appropriate permissions to obtain sensitive information by bypassing data masking rules using a CREATE TABLE SELECT statement. IBM X-Force ID: 220480.
An issue was discovered in Cloudera Manager before 5.13.4, 5.14.x before 5.14.4, and 5.15.x before 5.15.1. A read-only user can access sensitive cluster information.
Secret data of processes managed by CM is not secured by file permissions.
Cloudera Search in CDH before 5.7.0 allows unauthorized document access because Solr Queries by document id can bypass Sentry document-level security via the RealTimeGetHandler.
Nomad Community and Nomad Enterprise (“Nomad”) are vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs. This vulnerability, identified as CVE-2025-1296, is fixed in Nomad Community Edition 1.9.7 and Nomad Enterprise 1.9.7, 1.8.11, and 1.7.19.
In affected versions of the Octopus Kubernetes worker or agent, sensitive variables could be written to the Kubernetes script pod log in clear-text. This was identified in Version 2 however it was determined that this could also be achieved in Version 1 and the fix was applied to both versions accordingly.
When logging warnings regarding deprecated settings, Logstash before 5.6.6 and 6.x before 6.1.2 could inadvertently log sensitive information.
TYPO3 is an open source PHP based web content management system. In versions 9.0.0 through 9.5.27, 10.0.0 through 10.4.17, and 11.0.0 through 11.3.0, user credentials may been logged as plain-text. This occurs when explicitly using log level debug, which is not the default configuration. TYPO3 versions 9.5.28, 10.4.18, 11.3.1 contain a patch for this vulnerability.
Insertion of Sensitive Information into Log File vulnerability in upKeeper Solutions upKeeper Manager allows Use of Known Domain Credentials.This issue affects upKeeper Manager: from 5.2.0 before 5.2.12.
A plain keystore password is written to a system log file in SAP HANA Extended Application Services, 1.0, which could endanger confidentiality of SSL communication.
An exposure of sensitive information vulnerability exists in Jenkins SSH Agent Plugin 1.15 and earlier in SSHAgentStepExecution.java that exposes the SSH private key password to users with permission to read the build log.
GitLab CE/EE, versions 8.0 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, would log access tokens in the Workhorse logs, permitting administrators with access to the logs to see another user's token.
In JetBrains YouTrack before 2025.3.119033 access tokens could be exposed in Mailbox logs
IBM Security Access Manager Appliance 8.0.0 through 8.0.1.6, and 9.0.0 through 9.0.3.1 stores potentially sensitive information in log files that could be read by a remote user. IBM X-Force ID: 128617.
An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. It incorrectly logged sensitive suppression deletions, which should not have been visible to users with access to view AbuseFilter log data.
In cPanel before 57.9999.54, user log files become world-readable when rotated by cpanellogd (SEC-125).
Prior to Logstash version 5.0.1, Elasticsearch Output plugin when updating connections after sniffing, would log to file HTTP basic auth credentials.
IBM Spectrum Protect Plus 10.1.0 through 10.1.5 discloses highly sensitive information in plain text in the virgo log file which could be used in further attacks against the system. IBM X-Force ID: 181779.
IBM Kenexa LMS on Cloud 13.1 and 13.2 - 13.2.4 stores potentially sensitive information in in log files that could be read by an authenticated user.
IBM Storage Defender - Resiliency Service 2.0.0 through 2.0.18 could disclose sensitive user credentials in log files.
A flaw was discovered in ECE before 3.4.0 that might lead to the disclosure of sensitive information such as user passwords and Elasticsearch keystore settings values in logs such as the audit log or deployment logs in the Logging and Monitoring cluster. The affected APIs are PATCH /api/v1/user and PATCH /deployments/{deployment_id}/elasticsearch/{ref_id}/keystore
IBM BigFix Remote Control before 9.1.3 allows remote authenticated users to obtain sensitive information by reading error logs.
An information disclosure vulnerability exists in Yugabyte Anywhere, where the LDAP bind password is logged in plaintext within application logs. This flaw results in the unintentional exposure of sensitive information in Yugabyte Anywhere logs, potentially allowing unauthorized users with access to these logs to view the LDAP bind password. An attacker with log access could exploit this vulnerability to gain unauthorized access to the LDAP server, leading to potential exposure or compromise of LDAP-managed resources This issue affects YugabyteDB Anywhere: from 2.20.0.0 before 2.20.7.0, from 2.23.0.0 before 2.23.1.0, from 2024.1.0.0 before 2024.1.3.0.
A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V8.1), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V8.1), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V8.1), SCALANCE M812-1 ADSL-Router family (All versions < V8.1), SCALANCE M816-1 ADSL-Router family (All versions < V8.1), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V8.1), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions < V8.1), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V8.1), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V8.1), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V8.1), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V8.1), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V8.1), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions < V8.1), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions < V8.1), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V8.1), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions < V8.1), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions < V8.1), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions < V8.1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V8.1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V8.1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V8.1), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V8.1). Affected devices insert sensitive information about the generation of 2FA tokens into log files. This could allow an authenticated remote attacker to forge 2FA tokens of other users.
Couchbase Server 6.6.x through 7.x before 7.0.4 exposes Sensitive Information to an Unauthorized Actor.
In JetBrains TeamCity before 2024.07 parameters of the "password" type could leak into the build log in some specific cases
TYPO3 is an open source web content management system. Prior to versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, and 11.5.11, system internal credentials or keys (e.g. database credentials) can be logged as plaintext in exception handlers, when logging the complete exception stack trace. TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, 11.5.11 contain a fix for the problem.
Vault and Vault Enterprise (“Vault”) may expose sensitive information when enabling an audit device which specifies the `log_raw` option, which may log sensitive information to other audit devices, regardless of whether they are configured to use `log_raw`.
Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. **To exploit this** the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as insensitive. While Vela provides secrets masking, secrets exposure is not entirely solved by the masking process. A docker image (plugin) can easily expose secrets if they are not handled properly, or altered in some way. There is a responsibility on the end-user to understand how values injected into a plugin are used. This is a risk that exists for many CICD systems (like GitHub Actions) that handle sensitive runtime variables. Rather, the greater risk is that users who restrict a secret to the "no commands" option and use image restriction can still have their secret value exposed via substitution tinkering, which turns the image and command restrictions into a false sense of security. This issue has been addressed in version 0.23.2. Users are advised to upgrade. Users unable to upgrade should not provide sensitive values to plugins that can potentially expose them, especially in `parameters` that are not intended to be used for sensitive values, ensure plugins (especially those that utilize shared secrets) follow best practices to avoid logging parameters that are expected to be sensitive, minimize secrets with `pull_request` events enabled, as this allows users to change pipeline configurations and pull in secrets to steps not typically part of the CI process, make use of the build approval setting, restricting builds from untrusted users, and limit use of shared secrets, as they are less restrictive to access by nature.
Jenkins MQ Notifier Plugin 1.4.0 and earlier logs potentially sensitive build parameters as part of debug information in build logs by default.
An insertion of sensitive information into the log file in the audit log in GitHub Enterprise Server was identified that could allow an attacker to gain access to the management console. To exploit this, an attacker would need access to the log files for the GitHub Enterprise Server appliance, a backup archive created with GitHub Enterprise Server Backup Utilities, or a service which received streamed logs. This vulnerability affected all versions of GitHub Enterprise Server since 3.8 and was fixed in version 3.8.12, 3.9.7, 3.10.4, and 3.11.1.
An issue was discovered by Elastic whereby Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.
A vulnerability. When org.apache.linkis.metadata.util.HiveUtils.decode() fails to perform Base64 decoding, it records the complete input parameter string in the log via logger.error(str + "decode failed", e). If the input parameter contains sensitive information such as Hive Metastore keys, plaintext passwords will be left in the log files when decoding fails, resulting in information leakage. Affected Scope Component: Sensitive fields in hive-site.xml (e.g., javax.jdo.option.ConnectionPassword) or other fields encoded in Base64. Version: Apache Linkis 1.0.0 – 1.7.0 Trigger Conditions The value of the configuration item is an invalid Base64 string. Log files are readable by users other than hive-site.xml administrators. Severity: Low The probability of Base64 decoding failure is low. The leakage is only triggered when logs at the Error level are exposed. Remediation Apache Linkis 1.8.0 and later versions have replaced the log with desensitized content. logger.error("URL decode failed: {}", e.getMessage()); // 不再输出 str Users are recommended to upgrade to version 1.8.0, which fixes the issue.
On F5 BIG-IP 15.1.x versions prior to 15.1.5.1 and 14.1.x versions prior to 14.1.4.6, when installing Net HSM, the scripts (nethsm-safenet-install.sh and nethsm-thales-install.sh) expose the Net HSM partition password. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
An insertion of sensitive information into log file vulnerabilities [CWE-532] in FortiManager version 7.4.0, version 7.2.3 and below, version 7.0.8 and below, version 6.4.12 and below, version 6.2.11 and below and FortiAnalyzer version 7.4.0, version 7.2.3 and below, version 7.0.8 and below, version 6.4.12 and below, version 6.2.11 and below eventlog may allow any low privileged user with access to event log section to retrieve certificate private key and encrypted password logged as system log.
NetApp Cloud Manager versions prior to 3.9.9 log sensitive information that is available only to authenticated users. Customers with auto-upgrade enabled should already be on a fixed version while customers using on-prem connectors with auto-upgrade disabled are advised to upgrade to a fixed version.
Retool (self-hosted enterprise) through 3.40.0 inserts resource authentication credentials into sent data. Credentials for users with "Use" permissions can be discovered (by an authenticated attacker) via the /api/resources endpoint. The earliest affected version is 3.18.1.
PuppetDB logging included potentially sensitive system information.
In SonarQube before 10.4 and 9.9.4 LTA, encrypted values generated using the Settings Encryption feature are potentially exposed in cleartext as part of the URL parameters in the logs (such as SonarQube Access Logs, Proxy Logs, etc).
Since version 5.2.0, when using deferrable mode with the path of a Kubernetes configuration file for authentication, the Airflow worker serializes this configuration file as a dictionary and sends it to the triggerer by storing it in metadata without any encryption. Additionally, if used with an Airflow version between 2.3.0 and 2.6.0, the configuration dictionary will be logged as plain text in the triggerer service without masking. This allows anyone with access to the metadata or triggerer log to obtain the configuration file and use it to access the Kubernetes cluster. This behavior was changed in version 7.0.0, which stopped serializing the file contents and started providing the file path instead to read the contents into the trigger. Users are recommended to upgrade to version 7.0.0, which fixes this issue.
A flaw was discovered in bolt-server and ace where running a task with sensitive parameters results in those sensitive parameters being logged when they should not be. This issue only affects SSH/WinRM nodes (inventory service nodes).
NetApp Cloud Manager versions prior to 3.9.9 log sensitive information when an Active Directory connection fails. The logged information is available only to authenticated users. Customers with auto-upgrade enabled should already be on a fixed version while customers using on-prem connectors with auto-upgrade disabled are advised to upgrade to a fixed version.
IBM Business Automation Workflow 22.0.2, 23.0.1, 23.0.2, and 24.0.0 stores potentially sensitive information in log files under certain situations that could be read by an authenticated user. IBM X-Force ID: 284868.
APM server logs contain document body from a partially failed bulk index request. For example, in case of unavailable_shards_exception for a specific document, since the ES response line contains the document body, and that APM server logs the ES response line on error, the document is effectively logged.
An exposure of sensitive information to an unauthorized actor vulnerability in Fortinet FortiADC 7.4.0, FortiADC 7.2 all versions, FortiADC 7.1 all versions, FortiADC 7.0 all versions, FortiADC 6.2 all versions may allow an admin with read-only permission to get the external resources password via the logs of the product
An issue was discovered whereby Elastic Agent will leak secrets from the agent policy elastic-agent.yml only when the log level is configured to debug. By default the log level is set to info, where no leak occurs.
An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error or in the event where debug level logging is enabled in Kibana. Elastic has released Kibana 8.11.2 which resolves this issue. The messages recorded in the log may contain Account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users, Elastic Security package policy objects which can contain private keys, bearer token, and sessions of 3rd-party integrations and finally Authorization headers, client secrets, local file paths, and stack traces. The issue may occur in any Kibana instance running an affected version that could potentially receive an unexpected error when communicating to Elasticsearch causing it to include sensitive data into Kibana error logs. It could also occur under specific circumstances when debug level logging is enabled in Kibana. Note: It was found that the fix for ESA-2023-25 in Kibana 8.11.1 for a similar issue was incomplete.
IBM Cloud Pak for Automation 20.0.3, 20.0.2-IF002 - Business Automation Application Designer Component stores potentially sensitive information in log files that could be obtained by an unauthorized user. IBM X-Force ID: 194966.