| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Proofpoint Insider Threat Management Server (formerly ObserveIT Server) before 7.11.1 allows stored XSS. |
| An Authentication Bypass vulnerability in the SAML Authentication component of BlackBerry Workspaces Server (deployed with Appliance-X) version(s) 10.1, 9.1 and earlier could allow an attacker to potentially gain access to the application in the context of the targeted user’s account. |
| An Information Disclosure vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially gain access to a victim's web history. |
| A Remote Code Execution vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially cause the spreadsheet application to run commands on the victim’s local machine with the authority of the user. |
| A Denial of Service due to Improper Input Validation vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially to prevent any new user connections. |
| It was discovered that Kibana was not validating a user supplied path, which would load .pbf files. Because of this, a malicious user could arbitrarily traverse the Kibana host to load internal files ending in the .pbf extension. |
| Elastic Enterprise Search App Search versions before 7.14.0 are vulnerable to an issue where API keys were missing authorization via an alternate route. Using this vulnerability, an authenticated attacker could utilize API keys belonging to higher privileged users. |
| Elastic Enterprise Search App Search versions before 7.14.0 was vulnerable to an issue where API keys were not bound to the same engines as their creator. This could lead to a less privileged user gaining access to unauthorized engines. |
| Elasticsearch before 7.14.0 did not apply document and field level security to searchable snapshots. This could lead to an authenticated user gaining access to information that they are unauthorized to view. |
| All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters. While in the default setting the anonymous user has no permissions and is unable to successfully query any Elasticsearch APIs, an attacker could leverage the anonymous user to gain insight into certain details of a deployed cluster. |
| In Elasticsearch versions before 7.13.3 and 6.8.17 an uncontrolled recursion vulnerability that could lead to a denial of service attack was identified in the Elasticsearch Grok parser. A user with the ability to submit arbitrary queries to Elasticsearch could create a malicious Grok query that will crash the Elasticsearch node. |
| 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. |
| Kibana contains an embedded version of the Chromium browser that the Reporting feature uses to generate the downloadable reports. If a user with permissions to generate reports is able to render arbitrary HTML with this browser, they may be able to leverage known Chromium vulnerabilities to conduct further attacks. Kibana contains a number of protections to prevent this browser from rendering arbitrary content. |
| Elastic App Search versions after 7.11.0 and before 7.12.0 contain an XML External Entity Injection issue (XXE) in the App Search web crawler beta feature. Using this vector, an attacker whose website is being crawled by App Search could craft a malicious sitemap.xml to traverse the filesystem of the host running the instance and obtain sensitive files. |
| Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users. |
| 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. |
| In Elasticsearch versions before 7.11.2 and 6.8.15 a document disclosure flaw was found when Document or Field Level Security is used. Search queries do not properly preserve security permissions when executing certain cross-cluster search queries. This could result in the search disclosing the existence of documents the attacker should not be able to view. This could result in an attacker gaining additional insight into potentially sensitive indices. |
| In Kibana versions before 7.12.0 and 6.8.15 a flaw in the session timeout was discovered where the xpack.security.session.idleTimeout setting is not being respected. This was caused by background polling activities unintentionally extending authenticated users sessions, preventing a user session from timing out. |
| 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. |
| 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. |
