How to solve CVE-2023-44487

The CVE-2023-44487 vulnerability can be exploited by multiplexing requests through the HTTP/2 protocol and rapidly resetting the streams. This chain of events will result in high server resource consumption and eventually cause a Denial of Service. Let’s see which packages are affected and the current resolution or mitigation of the issue.

HTTP/2 RESET of Connections

Firstly, some background: multiplexing allows the client and server to send multiple request and response messages through one HTTP/2 connection at the same time. Multiplexing allows to transfer of multiple streams in parallel without requiring multiple TCP connections.

In the context of an HTTP/2 Connection, to send an RST_STREAM frame in a Java HTTP/2 client (using libraries like Jetty or OkHttp), you typically have methods or functions for sending HTTP/2 frames. Here’s an example of how you might use the Jetty HTTP/2 client to reset a stream:

// Assuming you have a ClientSession and streamId to reset
ClientSession session = ...;
int streamId = ...;

// Create an RST_STREAM frame
RstStreamFrame frame = new RstStreamFrame(streamId, ErrorCode.CANCEL);

// Send the RST_STREAM frame
session.newFrame(frame, new Callback.Adapter());

This results in an excess of server activities in terms of stream setup and teardown, without reaching the server’s predefined limit for the highest number of active streams per connection. Consequently, the server experiences a denial of service due to the consumption of its resources.

Mitigation of CVE-2023-44487

Java Middleware Products are vulnerable to this issue mostly through the io.netty:netty-codec-http2 library. In order to fix this vulnerability you should upgrade this library to version 4.1.100. For example:


For example, with WildFly 30 you will get this security fix available thanks to this JIRA:

On the other hand, if you are not able to upgrade the core library which is vulnerable to CVE-2023-44487 then you can opt for these mitigations:

Disable http2 endpoints to circumvent the flaw altogether until a fix is available. On WildFly, you can check if HTTP/2 is enable on your Undertow server as follows:

    "outcome" => "success",
    "result" => true

Then, to disable HTTP/2 on Undertow you can proceed as follows:


Finally, if you cannot disable HTTP/2 in your servers, you can mitigate the issue by applying IP-based blocking or flood protection and rate control tools at network endpoints to filter incoming traffic.


This article was a walk-though the CVE-2023-44487 vulnerability and how it can cause a Denial of Service vector in the HTTP/2 protocol due to a stream of RST frames.