In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.
Jetty is a Java based web server and servlet engine. An HTTP/2 SSL connection that is established and TCP congested will be leaked when it times out. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The vulnerability is patched in 9.4.54, 10.0.20, 11.0.20, and 12.0.6.
In Eclipse Parsson before 1.0.4 and 1.1.3, a document with a large depth of nested objects can allow an attacker to cause a Java stack overflow exception and denial of service. Eclipse Parsson allows processing (e.g. parse, generate, transform and query) JSON documents.
In Eclipse Mosquito before and including 2.0.5, establishing a connection to the mosquitto server without sending data causes the EPOLLOUT event to be added, which results excessive CPU consumption. This could be used by a malicious actor to perform denial of service type attack. This issue is fixed in 2.0.6
In Eclipse Jetty version 9.3.x and 9.4.x, the server is vulnerable to Denial of Service conditions if a remote client sends either large SETTINGs frames container containing many settings, or many small SETTINGs frames. The vulnerability is due to the additional CPU and memory allocations required to handle changed settings.
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.
In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.3, an attacker can cause a denial of service by specially crafted packets. The core issue is missing closing of a file in case of an error condition, resulting in the 404 error for each further file request. Users can work-around the issue by disabling the PUT request support. This issue follows an incomplete fix of CVE-2025-0726.
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.3, an attacker can cause an integer underflow and a subsequent denial of service by writing a very large file, by specially crafted packets with Content-Length in one packet smaller than the data request size of the other packet. A possible workaround is to disable HTTP PUT support. This issue follows an incomplete fix of CVE-2025-0727
In NetX Duo component HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.3, an attacker can cause an integer underflow and a subsequent denial of service by writing a very large file, by specially crafted packets with Content-Length smaller than the data request size. A possible workaround is to disable HTTP PUT support. This issue follows an uncomplete fix in CVE-2025-0728.
In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting.
Eclipse tinydtls 0.8.2 for Eclipse IoT allows remote attackers to cause a denial of service (DTLS peer crash) by sending a "Change cipher spec" packet without pre-handshake.
In Eclipse Mosquitto 1.4.15 and earlier, a Memory Leak vulnerability was found within the Mosquitto Broker. Unauthenticated clients can send crafted CONNECT packets which could cause a denial of service in the Mosquitto Broker.
In Eclipse Mosquitto version from 1.0 to 1.4.15, a Null Dereference vulnerability was found in the Mosquitto library which could lead to crashes for those applications using the library.
In Eclipse Mosquitto 1.4.14, a user can shutdown the Mosquitto server simply by filling the RAM memory with a lot of connections with large payload. This can be done without authentications if occur in connection phase of MQTT protocol.
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.2, an attacker can cause an integer underflow and a subsequent denial of service by writing a very large file, by specially crafted packets with Content-Length in one packet smaller than the data request size of the other packet. A possible workaround is to disable HTTP PUT support.
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.2, an attacker can cause an integer underflow and a subsequent denial of service by writing a very large file, by specially crafted packets with Content-Length smaller than the data request size. A possible workaround is to disable HTTP PUT support.
There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally.
In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client). This is fixed in the 4.5.10 version. Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc)
In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets.
The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function.
In Eclipse Californium version 2.0.0 to 2.7.2 and 3.0.0-3.5.0 a DTLS resumption handshake falls back to a DTLS full handshake on a parameter mismatch without using a HelloVerifyRequest. Especially, if used with certificate based cipher suites, that results in message amplification (DDoS other peers) and high CPU load (DoS own peer). The misbehavior occurs only with DTLS_VERIFY_PEERS_ON_RESUMPTION_THRESHOLD values larger than 0.
The package org.eclipse.milo:sdk-server before 0.6.8 are vulnerable to Denial of Service (DoS) when bypassing the limitations for excessive memory consumption by sending multiple CloseSession requests with the deleteSubscription parameter equal to False.
In Eclipse Wakaama, ever since its inception until 2021-01-14, the CoAP parsing code does not properly sanitize network-received data.
In Eclipse Hono version 1.3.0 and 1.4.0 the AMQP protocol adapter does not verify the size of AMQP messages received from devices. In particular, a device may send messages that are bigger than the max-message-size that the protocol adapter has indicated during link establishment. While the AMQP 1.0 protocol explicitly disallows a peer to send such messages, a hand crafted AMQP 1.0 client could exploit this behavior in order to send a message of unlimited size to the adapter, eventually causing the adapter to fail with an out of memory exception.
In Eclipse Californium version 2.3.0 to 2.6.0, the certificate based (x509 and RPK) DTLS handshakes accidentally fails, because the DTLS server side sticks to a wrong internal state. That wrong internal state is set by a previous certificate based DTLS handshake failure with TLS parameter mismatch. The DTLS server side must be restarted to recover this. This allow clients to force a DoS.
In Eclipse Parsson before versions 1.1.4 and 1.0.5, Parsing JSON from untrusted sources can lead malicious actors to exploit the fact that the built-in support for parsing numbers with large scale in Java has a number of edge cases where the input text of a number can lead to much larger processing time than one would expect. To mitigate the risk, parsson put in place a size limit for the numbers as well as their scale.
Eclipse Jetty provides a web server and servlet container. In versions 11.0.0 through 11.0.15, 10.0.0 through 10.0.15, and 9.0.0 through 9.4.52, an integer overflow in `MetaDataBuilder.checkSize` allows for HTTP/2 HPACK header values to exceed their size limit. `MetaDataBuilder.java` determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded. However, when length is very large and huffman is true, the multiplication by 4 in line 295 will overflow, and length will become negative. `(_size+length)` will now be negative, and the check on line 296 will not be triggered. Furthermore, `MetaDataBuilder.checkSize` allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2. This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server. Users of HTTP/2 can be impacted by a remote denial of service attack. The issue has been fixed in versions 11.0.16, 10.0.16, and 9.4.53. There are no known workarounds.
In versions 1.6 to 2.0.11 of Eclipse Mosquitto, an MQTT v5 client connecting with a large number of user-property properties could cause excessive CPU usage, leading to a loss of performance and possible denial of service.
A stack buffer overflow in /ddsi/q_bitset.h of Eclipse IOT Cyclone DDS Project v0.1.0 causes the DDS subscriber server to crash.
A heap buffer overflow in /src/dds_stream.c of Eclipse IOT Cyclone DDS Project v0.1.0 causes the DDS subscriber server to crash.
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.2, an attacker can cause a denial of service by specially crafted packets. The core issue is missing closing of a file in case of an error condition, resulting in the 404 error for each further file request. Users can work-around the issue by disabling the PUT request support.
In Mosquitto before 2.0.16, a memory leak occurs when clients send v5 CONNECT packets with a will message that contains invalid property types.
In Eclipse Wakaama (formerly liblwm2m) 1.0, core/er-coap-13/er-coap-13.c in lwm2mserver in the LWM2M server mishandles invalid options, leading to a memory leak. Processing of a single crafted packet leads to leaking (wasting) 24 bytes of memory. This can lead to termination of the LWM2M server after exhausting all available memory.
In Eclipse Mosquitto versions 2.07 and earlier, the server will crash if the client tries to send a PUBLISH packet with topic length = 0.
In Eclipse OpenJ9 prior to the 0.14.0 release, the Java bytecode verifier incorrectly allows a method to execute past the end of bytecode array causing crashes. Eclipse OpenJ9 v0.14.0 correctly detects this case and rejects the attempted class load.
In Eclipse Mosquitto versions 1.5 to 1.5.2 inclusive, if a message is published to Mosquitto that has a topic starting with $, but that is not $SYS, e.g. $test/test, then an assert is triggered that should otherwise not be reachable and Mosquitto will exit.
In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests.
Eclipse Californium is a Java implementation of RFC7252 - Constrained Application Protocol for IoT Cloud services. In versions prior to 3.7.0, and 2.7.4, Californium is vulnerable to a Denial of Service. Failing handshakes don't cleanup counters for throttling, causing the threshold to be reached without being released again. This results in permanently dropping records. The issue was reported for certificate based handshakes, but may also affect PSK based handshakes. It generally affects client and server as well. This issue is patched in version 3.7.0 and 2.7.4. There are no known workarounds. main: commit 726bac57659410da463dcf404b3e79a7312ac0b9 2.7.x: commit 5648a0c27c2c2667c98419254557a14bac2b1f3f
In MPLS environments, receipt of a specific SNMP packet may cause the routing protocol daemon (RPD) process to crash and restart. By continuously sending a specially crafted SNMP packet, an attacker can repetitively crash the RPD process causing prolonged denial of service. No other Juniper Networks products or platforms are affected by this issue. Affected releases are Juniper Networks Junos OS : 12.1X46 versions prior to 12.1X46-D77 on SRX Series; 12.3 versions prior to 12.3R12-S10; 12.3X48 versions prior to 12.3X48-D75 on SRX Series; 14.1X53 versions prior to 14.1X53-D48 on EX/QFX series; 15.1 versions prior to 15.1R4-S9, 15.1R7-S2; 15.1F6 versions prior to 15.1F6-S11; 15.1X49 versions prior to 15.1X49-D141, 15.1X49-D144, 15.1X49-D150 on SRX Series; 15.1X53 versions prior to 15.1X53-D234 on QFX5200/QFX5110 Series; 15.1X53 versions prior to 15.1X53-D68 on QFX10K Series; 15.1X53 versions prior to 15.1X53-D471, 15.1X53-D490 on NFX Series; 15.1X53 versions prior to 15.1X53-D590 on EX2300/EX3400 Series; 15.1X54 on ACX Series; 16.1 versions prior to 16.1R3-S10, 16.1R4-S11, 16.1R6-S5, 16.1R7; 16.1X65 versions prior to 16.1X65-D48; 16.2 versions prior to 16.2R2-S6; 17.1 versions prior to 17.1R2-S8, 17.1R3; 17.2 versions prior to 17.2R1-S7, 17.2R3; 17.2X75 versions prior to 17.2X75-D92, 17.2X75-D102, 17.2X75-D110; 17.3 versions prior to 17.3R3; 17.4 versions prior to 17.4R1-S4, 17.4R2; 18.1 versions prior to 18.1R1-S1, 18.1R2-S1, 18.1R3; 18.2X75 versions prior to 18.2X75-D10.
The srxpfe process may crash on SRX Series services gateways when the UTM module processes a specific fragmented HTTP packet. The packet is misinterpreted as a regular TCP packet which causes the processor to crash. This issue affects all SRX Series platforms that support URL-Filtering and have web-filtering enabled. Affected releases are Juniper Networks Junos OS: 12.3X48 versions prior to 12.3X48-D85 on SRX Series; 15.1X49 versions prior to 15.1X49-D181, 15.1X49-D190 on SRX Series; 17.3 versions on SRX Series; 17.4 versions prior to 17.4R1-S8, 17.4R2-S5, 17.4R3 on SRX Series; 18.1 versions prior to 18.1R3-S6 on SRX Series; 18.2 versions prior to 18.2R2-S1, 18.2R3 on SRX Series; 18.3 versions prior to 18.3R1-S2, 18.3R2 on SRX Series; 18.4 versions prior to 18.4R1-S1, 18.4R2 on SRX Series.
When BGP tracing is enabled an incoming BGP message may cause the Junos OS routing protocol daemon (rpd) process to crash and restart. While rpd restarts after a crash, repeated crashes can result in an extended DoS condition. Affected releases are Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S4, 16.1R7-S5; 16.2 versions prior to 16.2R2-S9, 16.2R3; 17.1 versions prior to 17.1R3; 17.2 versions prior to 17.2R3-S1; 17.3 versions prior to 17.3R3-S3, 17.3R3-S4, 17.3R4; 17.4 versions prior to 17.4R1-S7, 17.4R2-S3, 17.4R2-S4, 17.4R3; 18.1 versions prior to 18.1R2-S4, 18.1R3-S4, 18.1R4; 18.2 versions prior to 18.2R2-S2, 18.2R2-S3, 18.2R3; 18.2X75 versions prior to 18.2X75-D40; 18.3 versions prior to 18.3R1-S3, 18.3R2; 18.4 versions prior to 18.4R1-S2, 18.4R2. This issue does not affect Junos releases prior to 16.1R1.
Receipt of a specific packet on the out-of-band management interface fxp0 may cause the system to crash and restart (vmcore). By continuously sending a specially crafted packet to the fxp0 interface, an attacker can repetitively crash the rpd process causing prolonged Denial of Service (DoS). Affected releases are Juniper Networks SRX5000 Series: 12.1X46 versions prior to 12.1X46-D82; 12.3X48 versions prior to 12.3X48-D80; 15.1X49 versions prior to 15.1X49-D160.
On Junos devices with the BGP graceful restart helper mode enabled or the BGP graceful restart mechanism enabled, a BGP session restart on a remote peer that has the graceful restart mechanism enabled may cause the local routing protocol daemon (RPD) process to crash and restart. By simulating a specific BGP session restart, an attacker can repeatedly crash the RPD process causing prolonged denial of service (DoS). Graceful restart helper mode for BGP is enabled by default. No other Juniper Networks products or platforms are affected by this issue. Affected releases are Juniper Networks Junos OS: 16.1 versions prior to 16.1R7; 16.1X65 versions prior to 16.1X65-D48; 16.2 versions prior to 16.2R2-S8; 17.1 versions prior to 17.1R2-S7, 17.1R3; 17.2 versions prior to 17.2R1-S7, 17.2R3; 17.2X75 versions prior to 17.2X75-D92, 17.2X75-D102, 17.2X75-D110; 17.3 versions prior to 17.3R2-S2, 17.3R3; 17.4 versions prior to 17.4R1-S4, 17.4R2; 18.1 versions prior to 18.1R2. Junos OS releases prior to 16.1R1 are not affected.
A vulnerability has been found in INSTAR 2K+ and 4K 3.11.1 Build 1124. This vulnerability affects unknown code of the component Backend IPC Server. The manipulation leads to denial of service. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
On Junos devices with the BGP graceful restart helper mode enabled or the BGP graceful restart mechanism enabled, a certain sequence of BGP session restart on a remote peer that has the graceful restart mechanism enabled may cause the local routing protocol daemon (RPD) process to crash and restart. Repeated crashes of the RPD process can cause prolonged Denial of Service (DoS). Graceful restart helper mode for BGP is enabled by default. No other Juniper Networks products or platforms are affected by this issue. Affected releases are Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S3; 16.2 versions prior to 16.2R2-S9; 17.1 versions prior to 17.1R3; 17.2 versions prior to 17.2R3; 17.2X75 versions prior to 17.2X75-D105; 17.3 versions prior to 17.3R3-S2; 17.4 versions prior to 17.4R1-S7, 17.4R2-S2, 17.4R3; 18.1 versions prior to 18.1R3-S2; 18.2 versions prior to 18.2R2; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D30; 18.3 versions prior to 18.3R1-S4, 18.3R2. Junos OS releases prior to 16.1R1 are not affected.
Wago 750 Series PLCs with firmware version 10 and prior include a remote attack may take advantage of an improper implementation of the 3 way handshake during a TCP connection affecting the communications with commission and service tools. Specially crafted packets may also be sent to Port 2455/TCP/IP, used in Codesys management software, which may result in a denial-of-service condition of communications with commissioning and service tools.
A vulnerability has been found in Open5GS up to 2.7.5. Affected by this issue is the function esm_handle_pdn_connectivity_request of the file src/mme/esm-handler.c of the component AMF Component. The manipulation leads to denial of service. The attack may be launched remotely. Upgrading to version 2.7.6 is able to address this issue. The name of the patch is 701505102f514cbde2856cd2ebc9bedb7efc820d. It is recommended to upgrade the affected component.
A vulnerability was identified in Open5GS up to 2.7.5. Affected by this vulnerability is the function amf_npcf_am_policy_control_build_create/amf_nsmf_pdusession_build_create_sm_context of the file src/amf/npcf-build.c of the component AMF. The manipulation leads to denial of service. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.7.6 is able to address this issue. The patch is named cf63dd63197bf61a4b041aa364ba6a6199ab15e4. It is recommended to upgrade the affected component.
A vulnerability was found in Open5GS up to 2.7.5. This affects the function gmm_state_exception of the file src/amf/gmm-sm.c of the component AMF. The manipulation leads to denial of service. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.7.6 is able to address this issue. The identifier of the patch is f47f2bd4f7274295c5fbb19e2f806753d183d09a. It is recommended to upgrade the affected component.