CVE-2026-44891: 
Java 취약성 분석 및 완화

CVE-2026-44891 is a Denial of Service vulnerability in Netty's StompSubframeDecoder component, caused by unbounded accumulation of STOMP frame headers in memory. The io.netty.handler.codec.stomp.StompSubframeDecoder fails to limit the total number of headers or their cumulative size per frame — the maxLineLength parameter only restricts individual header lines, not the aggregate count. An unauthenticated remote attacker can exploit this to exhaust JVM heap memory and crash any server exposing a STOMP endpoint built on StompSubframeDecoder. Affected versions are Netty prior to 4.1.136.Final (4.1.x branch) and prior to 4.2.16.Final (4.2.x branch). The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The StompSubframeDecoder accumulates parsed headers into a DefaultStompHeadersSubframe object in memory without enforcing any cap on the total number of headers per frame. While the maxLineLength parameter prevents individual header lines from being excessively long, an attacker can bypass this by sending a large number of short, valid headers (e.g., a:1\n) in a single STOMP frame. These accumulate in the JVM heap until an OutOfMemoryError is thrown, crashing the server. No authentication or special privileges are required, and the attack is fully automatable over the network (GitHub Advisory, Netty PR #17063).

Successful exploitation results in a complete availability loss for the targeted server process — the JVM throws an OutOfMemoryError, causing the Netty-based STOMP server to crash. There is no confidentiality or integrity impact; the vulnerability is purely a Denial of Service. Any application or service that uses Netty's StompSubframeDecoder to expose a STOMP endpoint is vulnerable, and a single malicious connection is sufficient to trigger the crash, requiring no sustained flooding (GitHub Advisory).

1. Identify target: Locate a server running a Netty-based application that exposes a STOMP endpoint using StompSubframeDecoder (e.g., messaging brokers, Spring-based WebSocket servers using STOMP over Netty).
2. Establish TCP connection: Open a raw TCP socket connection to the target server's STOMP port (commonly 8080, 61613, or a custom port).
3. Send STOMP command line: Write the STOMP command CONNECT\n to the socket to begin a STOMP frame.
4. Flood with short headers: In a loop, write large batches of minimal valid headers (e.g., a:1\n) to the socket — the public PoC sends 1,000 such headers per batch, repeated 50,000 times, for a total of 50 million header entries accumulated in the server's DefaultStompHeadersSubframe.
5. Trigger OOM crash: The server's JVM heap is exhausted as headers accumulate without bound, causing an OutOfMemoryError and crashing the STOMP endpoint or the entire server process (GitHub Advisory).

• Network: High volume of inbound TCP connections or sustained data streams to the STOMP port from a single or small set of source IPs; connections that send data continuously without completing a valid STOMP frame.
• Logs: Java OutOfMemoryError stack traces in application logs referencing io.netty.handler.codec.stomp.StompSubframeDecoder or DefaultStompHeadersSubframe; JVM crash logs (hs_err_pid*.log) generated around the time of the incident.
• Process/System: Sudden spike in JVM heap usage visible in JMX/monitoring tools followed by process termination; server process restart events logged by the process supervisor (e.g., systemd, Docker restart policies).
• Application: Unexpected service unavailability or restart of the Netty-based STOMP service without a corresponding infrastructure event.

Upgrade Netty to version 4.1.136.Final (4.1.x branch) or 4.2.16.Final (4.2.x branch), which enforce a limit on the total number of headers per STOMP frame (GitHub Advisory, Netty 4.2.16 Release, Netty 4.1.136 Release). If immediate patching is not feasible, implement network-level controls such as rate limiting connections to the STOMP port, restricting access to trusted source IPs only, or placing a reverse proxy in front of the STOMP endpoint that enforces header count limits. Reducing the JVM heap size is not an effective mitigation as it only lowers the threshold before the crash occurs.

The vulnerability was reported by researcher violetagg and disclosed by Netty maintainer normanmaurer via the GitHub Security Advisory program on July 14, 2026 (GitHub Advisory). The fix was included in a broader security release that addressed multiple Netty codec vulnerabilities simultaneously, including issues in SPDY, DNS, HAProxy, HTTP/2, and WebSocket handlers (Netty PR #17063). A brief mention appeared on Mastodon via The Hacker Wire shortly after the NVD publication. Coverage has been primarily technical, with scanner vendors Qualys and Nessus adding detection plugins (IDs 5015412 and 327823 respectively).