CVE-2026-73507: 
Java vulnerability analysis and mitigation

CVE-2026-73507 is a Denial of Service vulnerability in Netty's XmlFrameDecoder caused by CPU exhaustion via malformed XML input. The io.netty.handler.codec.xml.XmlFrameDecoder.decode() method failed to preserve closing-tag parser state across invocations, allowing an unauthenticated remote attacker to trickle-feed repeated </ sequences that caused repeated rescanning of the accumulated buffer, exhausting an EventLoop thread's CPU. Affected versions include all Netty releases prior to 4.1.136.Final and 4.2.0.Final through 4.2.15.Final. The vulnerability was published on August 13, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is uncontrolled resource consumption (CWE-400) in XmlFrameDecoder.decode(). Because the decoder did not track a "pending closing tag" state between successive decode() calls, each new </ sequence in the input caused the decoder to rescan the entire accumulated buffer from the beginning to locate the closing > character. An attacker exploiting this flaw sends a stream of repeated </ byte sequences (trickle-feeding) over a network connection, causing the EventLoop thread to spend unbounded CPU time rescanning a buffer that can grow up to the configured maxFrameLength (default 1 MB). No authentication or special privileges are required. The fix, committed in commit 5b68c61 and commit bb2ff68, tracks the pending closing-tag state in the main decode loop and rejects nested < characters before the closing tag terminator, causing malformed repeated closing tags to fail fast.

Successful exploitation causes a Denial of Service by exhausting the CPU of a Netty EventLoop thread, rendering the affected service unresponsive to legitimate clients. Because Netty's event-driven model relies on a small pool of EventLoop threads to handle all I/O, blocking a single thread with CPU-intensive parsing can degrade or halt processing for all connections handled by that thread. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue affecting any application that uses Netty's XmlFrameDecoder to process untrusted XML input over the network (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of publication. The NVD SSVC assessment classifies exploitation as "none" and the attack as "automatable," meaning it can be scripted without human interaction. The EPSS score is approximately 0.0046 (0.46%), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only network access and no credentials, making it low-complexity for any attacker who can reach a service using the vulnerable XmlFrameDecoder (GitHub Advisory).

1. Reconnaissance: Identify services using Netty's XmlFrameDecoder (e.g., custom XML-over-TCP services, messaging middleware built on Netty) that are reachable over the network and running a vulnerable version (< 4.1.136.Final or 4.2.0.Final–4.2.15.Final).
2. Establish connection: Open a TCP connection to the target service that uses XmlFrameDecoder for framing incoming XML data.
3. Trickle-feed malformed payload: Slowly send a stream of repeated </ byte sequences without ever completing a valid closing tag (i.e., never sending the terminating > character). For example, send </</</</</... in small chunks to keep the buffer growing.
4. Trigger repeated rescanning: Each new </ sequence causes XmlFrameDecoder.decode() to rescan the entire accumulated buffer from the start, consuming increasing amounts of CPU proportional to buffer size (up to maxFrameLength, default 1 MB).
5. Achieve DoS: The EventLoop thread handling the connection becomes CPU-saturated, degrading or halting processing for all other connections on that thread, effectively causing a Denial of Service (GitHub Advisory).

• Network: Sustained TCP connections to the Netty service sending small, repeated </ byte sequences without completing valid XML frames; unusually low data throughput from a connection that remains open for an extended period.
• Process/System: Abnormally high CPU utilization on the JVM process hosting the Netty application, particularly on EventLoop threads (observable via thread dumps showing threads stuck in XmlFrameDecoder.decode()).
• Logs: Application logs may show slow or stalled processing of XML frames; JVM thread dumps revealing EventLoop threads in a tight loop within io.netty.handler.codec.xml.XmlFrameDecoder.
• Metrics: Spike in EventLoop task queue depth or latency metrics; drop in request throughput correlated with a specific connection or source IP.

Upgrade to Netty 4.1.136.Final or 4.2.16.Final, which contain the fix for this vulnerability (Netty 4.1.136.Final Release, Netty 4.2.16.Final Release). If an immediate upgrade is not possible, consider placing a network-level rate limiter or connection throttle in front of services using XmlFrameDecoder to limit the rate at which untrusted clients can send data. Additionally, reducing the maxFrameLength configuration to the smallest practical value will limit the maximum buffer size that can be rescanned, reducing the CPU impact per connection.