| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Sylabs Singularity 3.5.x and 3.6.x, and SingularityPRO before 3.5-8, has an Incorrect Check of a Function's Return Value. |
| Improper check in CheckboxGroup in com.vaadin:vaadin-checkbox-flow versions 1.2.0 prior to 2.0.0 (Vaadin 12.0.0 prior to 14.0.0), 2.0.0 prior to 3.0.0 (Vaadin 14.0.0 prior to 14.5.0), 3.0.0 through 4.0.1 (Vaadin 15.0.0 through 17.0.11), 14.5.0 through 14.6.7 (Vaadin 14.5.0 through 14.6.7), and 18.0.0 through 20.0.5 (Vaadin 18.0.0 through 20.0.5) allows attackers to modify the value of a disabled Checkbox inside enabled CheckboxGroup component via unspecified vectors. |
| All versions of the CODESYS V3 Runtime Toolkit for VxWorks from version V3.5.8.0 and before version V3.5.17.10 have Improper Handling of Exceptional Conditions. |
| rxvt-unicode 9.22, rxvt 2.7.10, mrxvt 0.5.4, and Eterm 0.9.7 allow (potentially remote) code execution because of improper handling of certain escape sequences (ESC G Q). A response is terminated by a newline. |
| Improper handling of exceptional conditions in SuiteLink server while processing command 0x01 |
| An improper check for unusual or exceptional conditions issue exists within the parsing DGN files from Drawings SDK (Version 2022.4 and prior) resulting from the lack of proper validation of the user-supplied data. This may result in several of out-of-bounds problems and allow attackers to cause a denial-of-service condition or execute code in the context of the current process. |
| Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In affected versions Envoy transitions a H/2 connection to the CLOSED state when it receives a GOAWAY frame without any streams outstanding. The connection state is transitioned to DRAINING when it receives a SETTING frame with the SETTINGS_MAX_CONCURRENT_STREAMS parameter set to 0. Receiving these two frames in the same I/O event results in abnormal termination of the Envoy process due to invalid state transition from CLOSED to DRAINING. A sequence of H/2 frames delivered by an untrusted upstream server will result in Denial of Service in the presence of untrusted **upstream** servers. Envoy versions 1.19.1, 1.18.4 contain fixes to stop processing of pending H/2 frames after connection transition to the CLOSED state. |
| An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Net::IMAP does not raise an exception when StartTLS fails with an an unknown response, which might allow man-in-the-middle attackers to bypass the TLS protections by leveraging a network position between the client and the registry to block the StartTLS command, aka a "StartTLS stripping attack." |
| Mintty before 3.4.7 mishandles Bracketed Paste Mode. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability combined with a Race Condition in the flow daemon (flowd) of Juniper Networks Junos OS on SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2 allows an unauthenticated network based attacker sending specific traffic to cause a crash of the flowd/srxpfe process, responsible for traffic forwarding in SRX, which will cause a Denial of Service (DoS). Continued receipt and processing of this specific traffic will create a sustained Denial of Service (DoS) condition. This issue can only occur when specific packets are trying to create the same session and logging for session-close is configured as a policy action. Affected platforms are: SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2. Not affected platforms are: SRX4000 Series, SRX5000 Series with SPC3, and vSRX Series. This issue affects Juniper Networks Junos OS SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability combined with Improper Handling of Exceptional Conditions in Juniper Networks Junos OS on QFX Series and PTX Series allows an unauthenticated network based attacker to cause increased FPC CPU utilization by sending specific IP packets which are being VXLAN encapsulated leading to a partial Denial of Service (DoS). Continued receipted of these specific traffic will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on QFX Series: All versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S13, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S7; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S3, 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2, 20.2R3; 20.3 versions prior to 20.3R1-S1, 20.3R2. Juniper Networks Junos OS on PTX Series: All versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S3; 19.4 versions prior to 19.4R1-S4, 19.4R3-S5; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3-S1; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2-S1, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2. |
| An Improper Handling of Exceptional Conditions vulnerability in Juniper Networks Junos OS and Junos OS Evolved allows an attacker to inject a specific BGP update, causing the routing protocol daemon (RPD) to crash and restart, leading to a Denial of Service (DoS). Continued receipt and processing of the BGP update will create a sustained Denial of Service (DoS) condition. This issue affects very specific versions of Juniper Networks Junos OS: 19.3R3-S2; 19.4R3-S3; 20.2 versions 20.2R2-S3 and later, prior to 20.2R3-S2; 20.3 versions 20.3R2 and later, prior to 20.3R3; 20.4 versions 20.4R2 and later, prior to 20.4R3; 21.1 versions prior to 21.1R2. Juniper Networks Junos OS 20.1 is not affected by this issue. This issue also affects Juniper Networks Junos OS Evolved: All versions prior to 20.4R2-S3-EVO, 20.4R3-EVO; 21.1-EVO versions prior to 21.1R2-EVO; 21.2-EVO versions prior to 21.2R2-EVO. |
| An Improper Check for Unusual or Exceptional Conditions in packet processing on the MS-MPC/MS-MIC utilized by Juniper Networks Junos OS allows a malicious attacker to send a specific packet, triggering the MS-MPC/MS-MIC to reset, causing a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue only affects specific versions of Juniper Networks Junos OS on MX Series: 17.3R3-S11; 17.4R2-S13; 17.4R3 prior to 17.4R3-S5; 18.1R3-S12; 18.2R2-S8, 18.2R3-S7, 18.2R3-S8; 18.3R3-S4; 18.4R3-S7; 19.1R3-S4, 19.1R3-S5; 19.2R1-S6; 19.3R3-S2; 19.4R2-S4, 19.4R2-S5; 19.4R3-S2; 20.1R2-S1; 20.2R2-S2, 20.2R2-S3, 20.2R3; 20.3R2, 20.3R2-S1; 20.4R1, 20.4R1-S1, 20.4R2; 21.1R1; This issue does not affect any version of Juniper Networks Junos OS prior to 15.1X49-D240; |
| A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64. |
| Possible denial of service due to improper handling of debug register trap from user applications in Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile |
| VIGRA Computer Vision Library Version-1-11-1 contains a segmentation fault vulnerability in the impex.hxx read_image_band() function, in which a crafted file can cause a denial of service. |
| TensorFlow is an end-to-end open source platform for machine learning. Passing invalid arguments (e.g., discovered via fuzzing) to `tf.raw_ops.SparseCountSparseOutput` results in segfault. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range. |
| TensorFlow is an end-to-end open source platform for machine learning. Passing a complex argument to `tf.transpose` at the same time as passing `conjugate=True` argument results in a crash. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range. |
| TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service via `CHECK`-fail in `tf.strings.substr` with invalid arguments. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range. |
| TensorFlow is an end-to-end open source platform for machine learning. Incomplete validation in `SparseAdd` results in allowing attackers to exploit undefined behavior (dereferencing null pointers) as well as write outside of bounds of heap allocated data. The implementation(https://github.com/tensorflow/tensorflow/blob/656e7673b14acd7835dc778867f84916c6d1cac2/tensorflow/core/kernels/sparse_sparse_binary_op_shared.cc) has a large set of validation for the two sparse tensor inputs (6 tensors in total), but does not validate that the tensors are not empty or that the second dimension of `*_indices` matches the size of corresponding `*_shape`. This allows attackers to send tensor triples that represent invalid sparse tensors to abuse code assumptions that are not protected by validation. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range. |
