LiveActive security incident?Get immediate response
CVE archive

September 2020

Browse CVE records published in September 2020, with severity, affected products, CWE, KEV, and source-backed vulnerability context.

Showing 50 of 1721 matching CVEs · Page 9 of 35.

Unknown · CVSS Not scored

CVE-2020-25762: An issue was discovered in SourceCodester Seat Reservation System 1.0.

An issue was discovered in SourceCodester Seat Reservation System 1.0. The file admin_class.php does not perform input validation on the username and password parameters. An attacker can send malicious input in the post request to /admin/ajax.php?action=login and bypass authentication, extract sensitive information etc.

Published Sep 29, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25770: An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local atta...

An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the target in order to exploit these vulnerabilities. The subs affected in this vulnerability makes it unique compared to similar CVEs such as CVE-2020-24564 and CVE-2020-25771.

Published Sep 28, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25828: An issue was discovered in MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4.

An issue was discovered in MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4. The non-jqueryMsg version of mw.message().parse() doesn't escape HTML. This affects both message contents (which are generally safe) and the parameters (which can be based on user input). (When jqueryMsg is loaded, it correctly accepts only whitelisted tags in message contents, and escapes all parameters. Situations with an unloaded jqueryMsg are rare in practice, but can for example occur for Special:SpecialPages on a wiki with no extensions installed.)

Published Sep 27, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25771: An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local atta...

An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the target in order to exploit these vulnerabilities. The subs affected in this vulnerability makes it unique compared to similar CVEs such as CVE-2020-24564 and CVE-2020-25770.

Published Sep 28, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25748: A Cleartext Transmission issue was discovered on Rubetek RV-3406, RV-3409, and RV-3411 cameras (firmware ve...

A Cleartext Transmission issue was discovered on Rubetek RV-3406, RV-3409, and RV-3411 cameras (firmware versions v342, v339). Someone in the middle can intercept and modify the video data from the camera, which is transmitted in an unencrypted form. One can also modify responses from NTP and RTSP servers and force the camera to use the changed values.

Published Sep 25, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25747: The Telnet service of Rubetek RV-3406, RV-3409, and RV-3411 cameras (firmware versions v342, v339) can allo...

The Telnet service of Rubetek RV-3406, RV-3409, and RV-3411 cameras (firmware versions v342, v339) can allow a remote attacker to gain access to RTSP and ONFIV services without authentication. Thus, the attacker can watch live streams from the camera, rotate the camera, change some settings (brightness, clarity, time), restart the camera, or reset it to factory settings.

Published Sep 25, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25750: An issue was discovered in DotPlant2 before 2020-09-14.

An issue was discovered in DotPlant2 before 2020-09-14. In class Pay2PayPayment in payment/Pay2PayPayment.php, there is an XXE vulnerability in the checkResult function. The user input ($_POST['xml']) is used for simplexml_load_string without sanitization. NOTE: This vulnerability only affects products that are no longer supported by the maintainer

Published Sep 18, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25626: A flaw was found in Django REST Framework versions before 3.12.0 and before 3.11.2.

A flaw was found in Django REST Framework versions before 3.12.0 and before 3.11.2. When using the browseable API viewer, Django REST Framework fails to properly escape certain strings that can come from user input. This allows a user who can control those strings to inject malicious <script> tags, leading to a cross-site-scripting (XSS) vulnerability.

Published Sep 30, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25599: An issue was discovered in Xen through 4.14.x.

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.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25601: An issue was discovered in Xen through 4.14.x.

An issue was discovered in Xen through 4.14.x. There is a lack of preemption in evtchn_reset() / evtchn_destroy(). In particular, the FIFO event channel model allows guests to have a large number of event channels active at a time. Closing all of these (when resetting all event channels or when cleaning up after the guest) may take extended periods of time. So far, there was no arrangement for preemption at suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these operations. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable depends on underlying hardware characteristics.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25598: An issue was discovered in Xen 4.14.x.

An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs, typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0, cannot exploit the vulnerability.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25596: An issue was discovered in Xen through 4.14.x.

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.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25602: An issue was discovered in Xen through 4.14.x.

An issue was discovered in Xen through 4.14.x. An x86 PV guest can trigger a host OS crash when handling guest access to MSR_MISC_ENABLE. When a guest accesses certain Model Specific Registers, Xen first reads the value from hardware to use as the basis for auditing the guest access. For the MISC_ENABLE MSR, which is an Intel specific MSR, this MSR read is performed without error handling for a #GP fault, which is the consequence of trying to read this MSR on non-Intel hardware. A buggy or malicious PV guest administrator can crash Xen, resulting in a host Denial of Service. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are not vulnerable. Only x86 systems that do not implement the MISC_ENABLE MSR (0x1a0) are vulnerable. AMD and Hygon systems do not implement this MSR and are vulnerable. Intel systems do implement this MSR and are not vulnerable. Other manufacturers have not been checked. Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests cannot exploit the vulnerability.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25603: An issue was discovered in Xen through 4.14.x.

An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25604: An issue was discovered in Xen through 4.14.x.

An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25597: An issue was discovered in Xen through 4.14.x.

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.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25600: An issue was discovered in Xen through 4.14.x.

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.

Published Sep 23, 2020 · Updated Aug 4, 2024

Critical · CVSS 9.8

CVE-2020-25575: An issue was discovered in the failure crate through 0.1.5 for Rust.

An issue was discovered in the failure crate through 0.1.5 for Rust. It may introduce "compatibility hazards" in some applications, and has a type confusion flaw when downcasting. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: This may overlap CVE-2019-25010

Published Sep 14, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25595: An issue was discovered in Xen through 4.14.x.

An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec "backdoor" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does.

Published Sep 23, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25288: An issue was discovered in MantisBT before 2.24.3.

An issue was discovered in MantisBT before 2.24.3. When editing an Issue in a Project where a Custom Field with a crafted Regular Expression property is used, improper escaping of the corresponding form input's pattern attribute allows HTML injection and, if CSP settings permit, execution of arbitrary JavaScript.

Published Sep 30, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25269: An issue was discovered in InspIRCd 2 before 2.0.29 and 3 before 3.6.0.

An issue was discovered in InspIRCd 2 before 2.0.29 and 3 before 3.6.0. The pgsql module contains a use after free vulnerability. When combined with the sqlauth or sqloper modules, this vulnerability can be used for remote crashing of an InspIRCd server by any user able to connect to a server.

Published Sep 11, 2020 · Updated Aug 4, 2024

Unknown · CVSS Not scored

CVE-2020-25276: An issue was discovered in PrimeKey EJBCA 6.x and 7.x before 7.4.1.

An issue was discovered in PrimeKey EJBCA 6.x and 7.x before 7.4.1. When using a client certificate to enroll over the EST protocol, no revocation check is performed on that certificate. This vulnerability can only affect a system that has EST configured, uses client certificates to authenticate enrollment, and has had such a certificate revoked. This certificate needs to belong to a role that is authorized to enroll new end entities. (To completely mitigate this problem prior to upgrade, remove any revoked client certificates from their respective roles.)

Published Sep 11, 2020 · Updated Aug 4, 2024