X-Pack Security 5.2.x would allow access to more fields than the user should have seen if the field level security rules used a mix of grant and exclude rules when merging multiple rules with field level security rules for the same index.

In Kibana X-Pack security versions prior to 5.4.3 if a Kibana user opens a crafted Kibana URL the result could be a redirect to an improperly initialized Kibana login screen. If the user enters credentials on this screen, the credentials will appear in the URL bar. The credentials could then be viewed by untrusted parties or logged into the Kibana access logs.

A vulnerability in Kibana could expose sensitive information related to Elastic Stack monitoring in the Kibana page source. Elastic Stack monitoring features provide a way to keep a pulse on the health and performance of your Elasticsearch cluster. Authentication with a vulnerable Kibana instance is not required to view the exposed information. The Elastic Stack monitoring exposure only impacts users that have set any of the optional monitoring.ui.elasticsearch.* settings in order to configure Kibana as a remote UI for Elastic Stack Monitoring. The same vulnerability in Kibana could expose other non-sensitive application-internal information in the page source.

Elasticsearch versions 7.0.0-7.3.2 and 6.7.0-6.8.3 contain a username disclosure flaw was found in the API Key service. An unauthenticated attacker could send a specially crafted request and determine if a username exists in the Elasticsearch native realm.

Elasticsearch versions before 7.11.2 and 6.8.15 contain a document disclosure flaw was found in the Elasticsearch suggester and profile API when Document and Field Level Security are enabled. The suggester and profile API are normally disabled for an index when document level security is enabled on the index. Certain queries are able to enable the profiler and suggester which could lead to disclosing the existence of documents and fields the attacker should not be able to view.

In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 a default master encryption key is used in the process of granting ZooKeeper access to Elasticsearch clusters. Unless explicitly overwritten, this master key is predictable across all ECE deployments. If an attacker can connect to ZooKeeper directly they would be able to access configuration information of other tenants if their cluster ID is known.

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.

Logstash 1.4.x before 1.4.5 and 1.5.x before 1.5.4 with Lumberjack output or the Logstash forwarder does not validate SSL/TLS certificates from the Logstash server, which might allow attackers to obtain sensitive information via a man-in-the-middle attack.

In Logstash versions after 6.4.0 and before 6.8.15 and 7.12.0 a TLS certificate validation flaw was found in the monitoring feature. When specifying a trusted server CA certificate Logstash would not properly verify the certificate returned by the monitoring server. This could result in a man in the middle style attack against the Logstash monitoring data.

The client-forwarder in Elastic Cloud Enterprise versions prior to 1.0.2 do not properly encrypt traffic to ZooKeeper. If an attacker is able to man in the middle (MITM) the traffic between the client-forwarder and ZooKeeper they could potentially obtain sensitive data.

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.

Elasticsearch Security versions 6.5.0 and 6.5.1 contain an XXE flaw in Machine Learning's find_file_structure API. If a policy allowing external network access has been added to Elasticsearch's Java Security Manager then an attacker could send a specially crafted request capable of leaking content of local files on the Elasticsearch node. This could allow a user to access information that they should not have access to.

A race condition flaw was found in the response headers Elasticsearch versions before 7.2.1 and 6.8.2 returns to a request. On a system with multiple users submitting requests, it could be possible for an attacker to gain access to response header containing sensitive data from another user.

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

Logstash prior to version 2.3.4, Elasticsearch Output plugin would log to file HTTP authorization headers which could contain sensitive information.

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

Elasticsearch Alerting and Monitoring in versions before 6.4.1 or 5.6.12 have an information disclosure issue when secrets are configured via the API. The Elasticsearch _cluster/settings API, when queried, could leak sensitive configuration information such as passwords, tokens, or usernames. This could allow an authenticated Elasticsearch user to improperly view these details.

In Elasticsearch versions 6.0.0-beta1 to 6.2.4 a disclosure flaw was found in the _snapshot API. When the access_key and security_key parameters are set using the _snapshot API they can be exposed as plain text by users able to query the _snapshot API.

APM server logs could contain parts of the document body from a partially failed bulk index request. Depending on the nature of the document, this could disclose sensitive information in APM Server error logs.

Elasticsearch Security versions 6.4.0 to 6.4.2 contain an error in the way request headers are applied to requests when using the Active Directory, LDAP, Native, or File realms. A request may receive headers intended for another request if the same username is being authenticated concurrently; when used with run as, this can result in the request running as the incorrect user. This could allow a user to access information that they should not have access to.

Exposure of sensitive information to local unauthorized actors in Elastic Agent and Elastic Security Endpoint can lead to loss of confidentiality and impersonation of Endpoint to the Elastic Stack. This issue was identified by Elastic engineers and Elastic has no indication that it is known or has been exploited by malicious actors.

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.

A document disclosure flaw was found in Elasticsearch versions after 7.6.0 and before 7.11.0 when Document or Field Level Security is used. Get requests do not properly apply security permissions when executing a query against a recently updated document. This affects documents that have been updated and not yet refreshed in the index. This could result in the search disclosing the existence of documents and fields the attacker should not be able to view.

A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. A user with the ability to submit arbitrary queries to Elasticsearch could submit a malformed query that would result in an error message returned containing previously used portions of a data buffer. This buffer could contain sensitive information such as Elasticsearch documents or authentication details.

Elasticsearch X-Pack Security versions 5.0.0 to 5.4.3, when enabled, can result in the Elasticsearch _nodes API leaking sensitive configuration information, such as the paths and passphrases of SSL keys that were configured as part of an authentication realm. This could allow an authenticated Elasticsearch user to improperly view these details.

X-Pack 5.1.1 did not properly apply document and field level security to multi-search and multi-get requests so users without access to a document and/or field may have been able to access this information.

Elastic X-Pack Security versions prior to 5.4.1 and 5.3.3 did not always correctly apply Document Level Security to index aliases. This bug could allow a user with restricted permissions to view data they should not have access to when performing certain operations against an index alias.

Secret token configuration is never applied when using ECK <2.8 with APM Server >=8.0. This could lead to anonymous requests to an APM Server being accepted and the data ingested into this APM deployment.

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 identified in Kibana where a user without access to Fleet can view Elastic Agent policies that could contain sensitive information. The nature of the sensitive information depends on the integrations enabled for the Elastic Agent and their respective versions.

It was discovered that Kibana’s JIRA connector & IBM Resilient connector could be used to return HTTP response data on internal hosts, which may be intentionally hidden from public view. Using this vulnerability, a malicious user with the ability to create connectors, could utilize these connectors to view limited HTTP response data on hosts accessible to the cluster.

An issue was identified in Fleet Server where Fleet policies that could contain sensitive information were logged on INFO and ERROR log levels. The nature of the sensitive information largely depends on the integrations enabled.

Logstash 1.5.x before 1.5.3 and 1.4.x before 1.4.4 allows remote attackers to read communications between Logstash Forwarder agent and Logstash server.

The Control Panel in Parallels Plesk Panel 10.2.0 build 20110407.20 generates web pages containing external links in response to GET requests with query strings for smb/app/search-data/catalogId/marketplace and certain other files, which makes it easier for remote attackers to obtain sensitive information by reading (1) web-server access logs or (2) web-server Referer logs, related to a "cross-domain Referer leakage" issue.

The CSPSource::schemeMatches function in WebKit/Source/core/frame/csp/CSPSource.cpp in the Content Security Policy (CSP) implementation in Blink, as used in Google Chrome before 52.0.2743.82, does not apply http :80 policies to https :443 URLs and does not apply ws :80 policies to wss :443 URLs, which makes it easier for remote attackers to determine whether a specific HSTS web site has been visited by reading a CSP report. NOTE: this vulnerability is associated with a specification change after CVE-2016-1617 resolution.

OpenStack Nova before 2012.1 allows someone with access to an EC2_ACCESS_KEY (equivalent to a username) to obtain the EC2_SECRET_KEY (equivalent to a password). Exposing the EC2_ACCESS_KEY via http or tools that allow man-in-the-middle over https could allow an attacker to easily obtain the EC2_SECRET_KEY. An attacker could also presumably brute force values for EC2_ACCESS_KEY.

Lexmark X, W, T, E, and C devices before 2012-02-09 allow attackers to obtain sensitive information by reading passwords within exported settings.

RSA Access Manager Server 5.5.3 before 5.5.3.172, 6.0.4 before 6.0.4.53, and 6.1 before 6.1.2.01 does not properly perform cache updates, which allows remote attackers to obtain sensitive information via unspecified vectors.

Tor before 0.2.2.24-alpha continues to use a reachable bridge that was previously configured but is not currently configured, which might allow remote attackers to obtain sensitive information about clients in opportunistic circumstances by monitoring network traffic to the bridge port.

The Bluetooth service (com/android/phone/BluetoothHeadsetService.java) in Android 2.3 before 2.3.6 allows remote attackers within Bluetooth range to obtain contact data via an AT phonebook transfer.

WebKit, as used in Apple Safari before 4.1.3 and 5.0.x before 5.0.3, Google Chrome before 6.0.472.53, and webkitgtk before 1.2.6, does not properly restrict read access to images derived from CANVAS elements, which allows remote attackers to bypass the Same Origin Policy and obtain potentially sensitive image data via a crafted web site.

The RSA 1.5 algorithm implementation in the JOSE_JWE class in JWE.php in jose-php before 2.2.1 lacks the Random Filling protection mechanism, which makes it easier for remote attackers to obtain cleartext data via a Million Message Attack (MMA).

Mozilla Firefox before 45.0 does not properly restrict the availability of IFRAME Resource Timing API times, which allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via crafted JavaScript code that leverages history.back and performance.getEntries calls after restoring a browser session. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-7207.

Microsoft Internet Explorer 6 through 9 does not properly use the Content-Disposition HTTP header to control rendering of the HTTP response body, which allows remote attackers to read content from a different (1) domain or (2) zone via a crafted web site, aka "Content-Disposition Information Disclosure Vulnerability."

Insufficient policy enforcement in V8 in Google Chrome prior to 14.0.0.0 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page.

The implementation of HTML content creation in Microsoft Internet Explorer 6 through 8 does not remove the Anchor element during pasting and editing, which might allow remote attackers to obtain sensitive deleted information by visiting a web page, aka "Anchor Element Information Disclosure Vulnerability."

The renderer implementation in Google Chrome before 51.0.2704.63 does not properly restrict public exposure of classes, which allows remote attackers to obtain sensitive information via vectors related to extensions.

Opera before 10.50 on Windows, before 10.52 on Mac OS X, and before 10.60 on UNIX platforms makes widget properties accessible to third-party domains, which allows remote attackers to obtain potentially sensitive information via a crafted web site.

Microsoft Internet Explorer 6 through 8 does not properly handle unspecified special characters in Cascading Style Sheets (CSS) documents, which allows remote attackers to obtain sensitive information from a different (1) domain or (2) zone via a crafted web site, aka "CSS Special Character Information Disclosure Vulnerability."

uri.js in Google V8 before 5.1.281.26, as used in Google Chrome before 51.0.2704.63, uses an incorrect array type, which allows remote attackers to obtain sensitive information by calling the decodeURI function and leveraging "type confusion."