| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only 1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas all other domains can use up to 4095 in this model. The recording of the respective limit during domain initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0) servicing other domains may observe event channel allocations to succeed when they should really fail. Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. |
| In SapphireIMS 5.0, it is possible to use the hardcoded credential in clients (username: sapphire, password: ims) and gain access to the portal. Once the access is available, the attacker can inject malicious OS commands on “ping”, “traceroute” and “snmp” functions and execute code on the server. |
| SapphireIMS 5 utilized default sapphire:ims credentials to connect the client to server. This credential is saved in ServerConf.config file in the client. |
| In SapphireIMS 5.0, it is possible to use the hardcoded credential in clients (username: sapphire, password: ims) and gain access to the portal. Once the access is available, the attacker can inject malicious OS commands on “ping”, “traceroute” and “snmp” functions and execute code on the server. We also observed the same is true if the JSESSIONID is completely removed. |
| WSO2 Enterprise Integrator 6.6.0 or earlier contains a stored cross-site scripting (XSS) vulnerability in BPMN explorer tasks. |
| An incorrect permission assignment during the installation script of TeamworkCloud 18.0 thru 19.0 allows a local unprivileged attacker to execute arbitrary code as root. During installation, the user is instructed to set the system enviroment file with world writable permissions (0777 /etc/environment). Any local unprivileged user can execute arbitrary code simply by writing to /etc/environment, which will force all users, including root, to execute arbitrary code during the next login or reboot. In addition, the entire home directory of the twcloud user at /home/twcloud is recursively given world writable permissions. This allows any local unprivileged attacker to execute arbitrary code, as twcloud. This product was previous named Cameo Enterprise Data Warehouse (CEDW). |
| TOTOLINK A3002RU-V2.0.0 B20190814.1034 allows authenticated remote users to modify the system's 'Run Command'. An attacker can use this functionality to execute arbitrary OS commands on the router. |
| Cross Site Scripting (XSS) vulnerability in Beetel router 777VR1 can be exploited via the NTP server name in System Time and "Keyword" in URL Filter. |
| A reflected Cross-site scripting (XSS) vulnerability in Xinuo (formerly SCO) Openserver version 5 and 6 allows remote attackers to inject arbitrary web script or HTML tag via the parameter 'section'. |
| Xinuos (formerly SCO) Openserver v5 and v6 allows attackers to execute arbitrary commands via shell metacharacters in outputform or toclevels parameter to cgi-bin/printbook. |
| Oclean Mobile Application 2.1.2 communicates with an external website using HTTP so it is possible to eavesdrop the network traffic. The content of HTTP payload is encrypted using XOR with a hardcoded key, which allows for the possibility to decode the traffic. |
| 6Kare Emakin 5.0.341.0 is affected by Cross Site Scripting (XSS) via the /rpc/membership/setProfile DisplayName field, which is mishandled when rendering the Activity Stream page. |
| A heap overflow in Sqreen PyMiniRacer (aka Python Mini Racer) before 0.3.0 allows remote attackers to potentially exploit heap corruption. |
| Liferay CMS Portal version 7.1.3 and 7.2.1 have a blind persistent cross-site scripting (XSS) vulnerability in the user name parameter to Calendar. An attacker can insert the malicious payload on the username, lastname or surname fields of its own profile, and the malicious payload will be injected and reflected in the calendar of the user who submitted the payload. An attacker could escalate its privileges in case an admin visits the calendar that injected the payload. |
| SimplePHPscripts News Script PHP Pro 2.3 is affected by a Cross Site Scripting (XSS) vulnerability via the editor_name parameter. |
| AntSword 2.1.8.1 contains a cross-site scripting (XSS) vulnerability in the View Site funtion. When viewing an added site, an XSS payload can be injected in cookies view which can lead to remote code execution. |
| Heap buffer overflow at moddable/xs/sources/xsDebug.c in Moddable SDK before before 20200903. The top stack frame is only partially initialized because the stack overflowed while creating the frame. This leads to a crash in the code sending the stack frame to the debugger. |
