| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS. |
| An issue was discovered in Xen through 4.14.x. A guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes /local/domain/$DOMID for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. Access rights of Xenstore nodes are per domid. Unfortunately, existing granted access rights are not removed when a domain is being destroyed. This means that a new domain created with the same domid will inherit the access rights to Xenstore nodes from the previous domain(s) with the same domid. Because all Xenstore entries of a guest below /local/domain/<domid> are being deleted by Xen tools when a guest is destroyed, only Xenstore entries of other guests still running are affected. For example, a newly created guest domain might be able to read sensitive information that had belonged to a previously existing guest domain. Both Xenstore implementations (C and Ocaml) are vulnerable. |
| An issue was discovered in Xen through 4.14.x. Neither xenstore implementation does any permission checks when reporting a xenstore watch event. A guest administrator can watch the root xenstored node, which will cause notifications for every created, modified, and deleted key. A guest administrator can also use the special watches, which will cause a notification every time a domain is created and destroyed. Data may include: number, type, and domids of other VMs; existence and domids of driver domains; numbers of virtual interfaces, block devices, vcpus; existence of virtual framebuffers and their backend style (e.g., existence of VNC service); Xen VM UUIDs for other domains; timing information about domain creation and device setup; and some hints at the backend provisioning of VMs and their devices. The watch events do not contain values stored in xenstore, only key names. A guest administrator can observe non-sensitive domain and device lifecycle events relating to other guests. This information allows some insight into overall system configuration (including the number and general nature of other guests), and configuration of other guests (including the number and general nature of other guests' devices). This information might be commercially interesting or might make other attacks easier. There is not believed to be exposure of sensitive data. Specifically, there is no exposure of VNC passwords, port numbers, pathnames in host and guest filesystems, cryptographic keys, or within-guest data. |
| An issue was discovered in Xen through 4.14.x. In the Ocaml xenstored implementation, the internal representation of the tree has special cases for the root node, because this node has no parent. Unfortunately, permissions were not checked for certain operations on the root node. Unprivileged guests can get and modify permissions, list, and delete the root node. (Deleting the whole xenstore tree is a host-wide denial of service.) Achieving xenstore write access is also possible. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. |
| CA Service Catalog 17.2 and 17.3 contain a vulnerability in the default configuration of the Setup Utility that may allow a remote attacker to cause a denial of service condition. |
| Invision Community 4.5.4 is affected by cross-site scripting (XSS) in the Field Name field. This vulnerability can allow an attacker to inject the XSS payload in Field Name and each time any user will open that, the XSS triggers and the attacker can able to steal the cookie according to the crafted payload. |
| nopCommerce Store 4.30 is affected by cross-site scripting (XSS) in the Schedule tasks name field. This vulnerability can allow an attacker to inject the XSS payload in Schedule tasks and each time any user will go to that page of the website, the XSS triggers and attacker can able to steal the cookie according to the crafted payload. |
| EGavilan Media EGM Address Book 1.0 contains a SQL injection vulnerability. An attacker can gain Admin Panel access using malicious SQL injection queries to perform remote arbitrary code execution. |
| EGavilan Media Under Construction page with cPanel 1.0 contains a SQL injection vulnerability. An attacker can gain Admin Panel access using malicious SQL injection queries to perform remote arbitrary code execution. |
| OpenCart 3.0.3.6 is affected by cross-site scripting (XSS) in the Profile Image. An admin can upload a profile image as a malicious code using JavaScript. Whenever anyone will see the profile picture, the code will execute and XSS will trigger. |
| OpenCart 3.0.3.6 is affected by cross-site scripting (XSS) in the Subject field of mail. This vulnerability can allow an attacker to inject the XSS payload in the Subject field of the mail and each time any user will open that mail of the website, the XSS triggers and the attacker can able to steal the cookie according to the crafted payload. |
| WonderCMS 3.1.3 is affected by cross-site scripting (XSS) in the Menu component. This vulnerability can allow an attacker to inject the XSS payload in the Setting - Menu and each time any user will visits the website directory, the XSS triggers and attacker can steal the cookie according to the crafted payload. |
| Textpattern CMS 4.6.2 allows CSRF via the prefs subsystem. |
| A Privilege Elevation vulnerability in OPC UA .NET Standard Stack 1.4.363.107 could allow a rogue application to establish a secure connection. |
| Multiple cross-site scripting (XSS) vulnerabilities in Papermerge before 1.5.2 allow remote attackers to inject arbitrary web script or HTML via the rename, tag, upload, or create folder function. The payload can be in a folder, a tag, or a document's filename. If email consumption is configured in Papermerge, a malicious document can be sent by email and is automatically uploaded into the Papermerge web application. Therefore, no authentication is required to exploit XSS if email consumption is configured. Otherwise authentication is required. |
| A cross-Site Scripting (XSS) vulnerability in this.showInvalid and this.showInvalidCountry in SmartyStreets liveAddressPlugin.js 3.2 allows remote attackers to inject arbitrary web script or HTML via any address parameter (e.g., street or country). |
| Editors/LogViewerController.cs in Umbraco through 8.9.1 allows a user to visit a logviewer endpoint even if they lack Applications.Settings access. |
| The CachingResourceDownloadRewriteRule class in Jira Server and Jira Data Center before version 8.5.11, from 8.6.0 before 8.13.3, and from 8.14.0 before 8.15.0 allowed unauthenticated remote attackers to read arbitrary files within WEB-INF and META-INF directories via an incorrect path access check. |
| Affected versions of Atlassian Jira Server and Data Center allow remote attackers to enumerate Jira projects via an Information Disclosure vulnerability in the Jira Projects plugin report page. The affected versions are before version 8.5.11, from version 8.6.0 before 8.13.3, and from version 8.14.0 before 8.14.1. |
