CVE-2026-44891: 
Java Análisis y mitigación de vulnerabilidades

CVE-2026-44891 is a Denial of Service vulnerability in Netty's StompSubframeDecoder caused by unbounded header accumulation in STOMP frames. The io.netty:netty-codec-stomp Maven package is affected across versions >= 4.2.0.Alpha1 through <= 4.2.15.Final and all versions <= 4.1.135.Final. The vulnerability was published on July 14, 2026, by Netty maintainer normanmaurer and credited to reporter violetagg. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Netty Advisory).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). While StompSubframeDecoder enforces a maxLineLength parameter to restrict the length of individual header lines, it imposes no limit on the total number of headers or their cumulative size within a single STOMP frame. An unauthenticated attacker can send a TCP connection carrying a STOMP frame with an arbitrarily large number of short headers (e.g., a:1\n), which are continuously accumulated in memory within DefaultStompHeadersSubframe until the JVM throws an OutOfMemoryError. No authentication or special privileges are required; any network-accessible STOMP endpoint using this decoder is exploitable (GitHub Advisory, Netty Advisory).

Successful exploitation causes a JVM OutOfMemoryError that crashes the affected Netty-based service, resulting in a complete loss of availability. There is no impact on confidentiality or data integrity — the attack is purely a Denial of Service. Any application exposing a STOMP endpoint via Netty's StompSubframeDecoder is vulnerable, and a single malicious connection is sufficient to exhaust server memory and take the service offline (GitHub Advisory).

1. Reconnaissance: Identify services exposing a STOMP endpoint over TCP (commonly port 61613 or custom ports) that are built on Netty's StompSubframeDecoder using network scanning tools such as Nmap or Shodan.
2. Establish TCP connection: Open a raw TCP socket connection to the target STOMP endpoint (e.g., new Socket("<target>", <port>)).
3. Send STOMP command: Write a valid STOMP command header to initiate a frame, such as CONNECT\n, to begin the STOMP handshake.
4. Flood with short headers: Repeatedly write large batches of minimal headers (e.g., a:1\n) to the output stream — the advisory PoC sends 1,000 headers per batch for 50,000 iterations, totaling 50 million headers.
5. Trigger OutOfMemoryError: The server accumulates all headers in DefaultStompHeadersSubframe without any limit, exhausting JVM heap memory and causing an OutOfMemoryError that crashes the service (GitHub Advisory, Netty Advisory).

• Network: High-volume TCP connections to the STOMP port from a single source IP; sustained data transfer on a single connection without a corresponding frame terminator (\0).
• Logs: JVM crash logs or application logs containing java.lang.OutOfMemoryError: Java heap space originating from Netty's STOMP codec stack; repeated log entries from io.netty.handler.codec.stomp.StompSubframeDecoder.
• Process: Sudden termination or restart of the Netty-based service process; heap dump files (e.g., java_pid*.hprof) generated in the working directory indicating OOM conditions.
• System: Spike in JVM heap usage visible in JMX/monitoring dashboards immediately preceding service crash, correlated with a single active STOMP connection (GitHub Advisory).

Netty has released patched versions 4.2.16.Final and 4.1.136.Final for the io.netty:netty-codec-stomp package, which implement limits on the total number of headers and their cumulative size per STOMP frame. Users should upgrade to these versions immediately. As a temporary workaround, operators can implement external rate limiting or connection-level restrictions (e.g., via a reverse proxy or firewall) to limit the volume of data a single client can send to the STOMP endpoint within a time window (GitHub Advisory, Netty Advisory).