Filebeat versions through 7.17.9 and 8.6.2 have a flaw in httpjson input that allows the http request Authorization or Proxy-Authorization header contents to be leaked in the logs when debug logging is enabled.

An issue was discovered by Elastic whereby Beats and 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 Beats or Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Beats or 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.

An issue was discovered by Elastic whereby Watcher search input logged the search query results on DEBUG log level. This could lead to raw contents of documents stored in Elasticsearch to be printed in logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by removing this excessive logging. This issue only affects users that use Watcher and have a Watch defined that uses the search input and additionally have set the search input’s logger to DEBUG or finer, for example using: org.elasticsearch.xpack.watcher.input.search, org.elasticsearch.xpack.watcher.input, org.elasticsearch.xpack.watcher, or wider, since the loggers are hierarchical.

An issue was discovered by Elastic whereby the Documents API of App Search logged the raw contents of indexed documents at INFO log level. Depending on the contents of such documents, this could lead to the insertion of sensitive or private information in the App Search logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by changing the log level at which these are logged to DEBUG, which is disabled by default.

An issue was discovered in Fleet Server >= v8.10.0 and < v8.10.3 where Agent enrolment tokens are being inserted into the Fleet Server’s log file in plain text. These enrolment tokens could allow someone to enrol an agent into an agent policy, and potentially use that to retrieve other secrets in the policy including for Elasticsearch and third-party services. Alternatively a threat actor could potentially enrol agents to the clusters and send arbitrary events to Elasticsearch.

If Elastic Endpoint (v7.9.0 - v8.10.3) is configured to use a non-default option in which the logging level is explicitly set to debug, and when Elastic Agent is simultaneously configured to collect and send those logs to Elasticsearch, then Elastic Agent API keys can be viewed in Elasticsearch in plaintext. These API keys could be used to write arbitrary data and read Elastic Endpoint user artifacts.

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.

An issue was discovered whereby APM Server could log at ERROR level, a response from Elasticsearch indicating that indexing the document failed and that response would contain parts of the original document. Depending on the nature of the document that the APM Server attempted to ingest, this could lead to the insertion of sensitive or private information in the APM Server logs.

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

A sensitive data disclosure flaw was found in the way Logstash versions before 5.6.15 and 6.6.1 logs malformed URLs. If a malformed URL is specified as part of the Logstash configuration, the credentials for the URL could be inadvertently logged as part of the error message.

An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error. Elastic has released Kibana 8.11.1 which resolves this issue. The error message recorded in the log may contain account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users. The issue occurs infrequently, only if an error is returned from an Elasticsearch cluster, in cases where there is user interaction and an unhealthy cluster (for example, when returning circuit breaker or no shard exceptions).

The Elastic APM .NET Agent can leak sensitive HTTP header information when logging the details during an application error. Normally, the APM agent will sanitize sensitive HTTP header details before sending the information to the APM server. During an application error it is possible the headers will not be sanitized before being sent.

The Elastic APM agent for Go versions before 1.11.0 can leak sensitive HTTP header information when logging the details during an application panic. Normally, the APM agent will sanitize sensitive HTTP header details before sending the information to the APM server. During an application panic it is possible the headers will not be sanitized before being sent.

Improper restriction of environment variables in Elastic Defend can lead to exposure of sensitive information such as API keys and tokens via automatic transmission of unfiltered environment variables to the stack.

Elasticsearch generally filters out sensitive information and credentials before logging to the audit log. It was found that this filtering was not applied when requests to Elasticsearch use certain deprecated URIs for APIs. The impact of this flaw is that sensitive information such as passwords and tokens might be printed in cleartext in Elasticsearch audit logs. Note that audit logging is disabled by default and needs to be explicitly enabled and even when audit logging is enabled, request bodies that could contain sensitive information are not printed to the audit log unless explicitly configured.

When logging warnings regarding deprecated settings, Logstash before 5.6.6 and 6.x before 6.1.2 could inadvertently log sensitive information.

A sensitive data disclosure flaw was found in the Elasticsearch repository-azure (formerly elasticsearch-cloud-azure) plugin. When the repository-azure plugin is set to log at TRACE level Azure credentials can be inadvertently logged.

Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 contain an information exposure vulnerability. It was discovered that certain exception conditions would result in encryption keys, passwords, and other security sensitive headers being leaked to the allocator logs. An attacker with access to the logging cluster may obtain leaked credentials and perform authenticated actions using these credentials.

Prior to Logstash version 5.0.1, Elasticsearch Output plugin when updating connections after sniffing, would log to file HTTP basic auth credentials.

A flaw was discovered in ECE before 3.1.1 that could lead to the disclosure of the SAML signing private key used for the RBAC features, in deployment logs in the Logging and Monitoring cluster.

Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex

Elasticsearch versions before 7.10.0 and 6.8.14 have an information disclosure issue when audit logging and the emit_request_body option is enabled. The Elasticsearch audit log could contain sensitive information such as password hashes or authentication tokens. This could allow an Elasticsearch administrator to view these details.

An issue was discovered by Elastic whereby sensitive information is recorded in Kibana logs in the event of an error. The issue impacts only Kibana version 8.10.0 when logging in the JSON layout or when the pattern layout is configured to log the %meta pattern. Elastic has released Kibana 8.10.1 which resolves this issue. The error object recorded in the log contains request information, which can include sensitive data, such as authentication credentials, cookies, authorization headers, query params, request paths, and other metadata. Some examples of sensitive data which can be included in the logs are account credentials for kibana_system, kibana-metricbeat, or Kibana end-users.

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 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 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 local, authenticated user with shell can obtain the hashed values of login passwords and shared secrets via raw objmon configuration files. This issue affects all versions of Junos OS Evolved prior to 19.1R1.

A local, authenticated user with shell can obtain the hashed values of login passwords via configd streamer log. This issue affects all versions of Junos OS Evolved prior to 19.3R1.

IBM UrbanCode Deploy (UCD) through 7.1.2.21, 7.2 through 7.2.3.14, and 7.3 through 7.3.2.0 / IBM DevOps Deploy 8.0 through 8.0.1.4 and 8.1 through 8.1 stores potentially sensitive authentication token information in log files that could be read by a local user.

A local, authenticated user with shell can view sensitive configuration information via the ev.ops configuration file. This issue affects all versions of Junos OS Evolved prior to 19.2R1.

Insertion of sensitive information into log file in Windows ETL Channel allows an authorized attacker to disclose information locally.

A local, authenticated user with shell can obtain the hashed values of login passwords via configd traces. This issue affects all versions of Junos OS Evolved prior to 19.3R1.

A flaw was found in the Ansible Engine when using module_args. Tasks executed with check mode (--check-mode) do not properly neutralize sensitive data exposed in the event data. This flaw allows unauthorized users to read this data. The highest threat from this vulnerability is to confidentiality.

An Improper Output Neutralization for Logs flaw was found in Ansible when using the uri module, where sensitive data is exposed to content and json output. This flaw allows an attacker to access the logs or outputs of performed tasks to read keys used in playbooks from other users within the uri module. The highest threat from this vulnerability is to data confidentiality.

Sensitive information leak through log files. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 35739, Acronis Cyber Protect 16 (Linux, macOS, Windows) before build 37391.

Insecure permissions for log files of AVSystem Unified Management Platform (UMP) 23.07.0.16567~LTS allow members (with local access to the UMP application server) to access credentials to authenticate to all services, and to decrypt sensitive data stored in the database.

GoReleaser builds Go binaries for several platforms, creates a GitHub release and then pushes a Homebrew formula to a tap repository. `goreleaser release --debug` log shows secret values used in the in the custom publisher. This vulnerability is fixed in 1.24.0.

When TACACS+ audit forwarding is configured on BIG-IP or BIG-IQ system, sharedsecret is logged in plaintext in the audit log.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

HCL DevOps Deploy / HCL Launch stores potentially sensitive authentication token information in log files that could be read by a local user.

When on BIG-IP DNS or BIG-IP LTM enabled with DNS Services License, and a TSIG key is created, it is logged in plaintext in the audit log.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

MongoDB server may log authentication parameters, including credentials, to the server log during SASL authentication. When connection health metric logging is enabled, the full authentication parameters are written to the log without redaction.

An information-disclosure flaw was found in the way Heketi before 10.1.0 logs sensitive information. This flaw allows an attacker with local access to the Heketi server to read potentially sensitive information such as gluster-block passwords.

An information-disclosure flaw was found in the way that gluster-block before 0.5.1 logs the output from gluster-block CLI operations. This includes recording passwords to the cmd_history.log file which is world-readable. This flaw allows local users to obtain sensitive information by reading the log file. The highest threat from this vulnerability is to data confidentiality.

Sensitive information written to a log file vulnerability was found in jaegertracing/jaeger before version 1.18.1 when the Kafka data store is used. This flaw allows an attacker with access to the container's log file to discover the Kafka credentials.

A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V2.12). The affected application writes sensitive data, such as usernames and passwords in log files. A local attacker with access to the log files could use this information to launch further attacks.

There is an information leakage vulnerability in FusionCompute 6.5.1, eCNS280_TD V100R005C00 and V100R005C10. Due to the improperly storage of specific information in the log file, the attacker can obtain the information when a user logs in to the device. Successful exploit may cause the information leak.

IBM Watson CP4D Data Stores 4.0.0 through 4.8.4 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 264838.

An issue was discovered in AdGuard plugin before 1.11.22 for Safari on MacOS. AdGaurd verbosely logged each url that Safari accessed when the plugin was active. These logs went into the MacOS general logs for any unsandboxed process to read. This may be disabled in version 1.11.22.

Insertion of sensitive information into log file in Windows Failover Cluster allows an authorized attacker to disclose information locally.

The Snowflake Connector for Python provides an interface for developing Python applications that can connect to Snowflake and perform all standard operations. Prior to version 3.12.3, when the logging level was set by the user to DEBUG, the Connector could have logged Duo passcodes (when specified via the `passcode` parameter) and Azure SAS tokens. Additionally, the SecretDetector logging formatter, if enabled, contained bugs which caused it to not fully redact JWT tokens and certain private key formats. Snowflake released version 3.12.3 of the Snowflake Connector for Python, which fixes the issue. In addition to upgrading, users should review their logs for any potentially sensitive information that may have been captured.