XmlFrameDecoder in Netty versions prior to 4.1.136.Final and 4.2.16.Final contains a state management flaw that creates a CPU exhaustion vulnerability. The decoder accumulates incoming XML data across multiple decode() invocations but fails to preserve its parsing position between calls. Each time decode() is invoked, it rescans the entire accumulated buffer searching for closing tags rather than resuming from where it left off. Under normal traffic this causes wasteful repeated scanning of already-parsed data. Under adversarial conditions—an attacker sending XML split across many small packets with strategic </ fragments—the rescanning cost grows quadratically with buffer size, rapidly exhausting the thread's CPU allocation.
The attack's impact extends beyond the targeted connection. Netty's event loop model multiplexes all channels onto a single EventLoop thread. When XmlFrameDecoder consumes its thread's CPU, it starves every other connection sharing that reactor—turning a per-connection resource bug into a system-wide denial of service. This cascade effect is not captured in the CVE's 7.5 severity score.
The fix in 4.1.136.Final adds proper state checkpointing so the decoder resumes parsing from its last position rather than rescanning. Upgrade immediately. More critically: audit any custom frame decoder implementations in your codebase. This is a structural pattern flaw, not an isolated bug. The same state-survival failure that affected XmlFrameDecoder likely exists in other protocol decoders that haven't been CVE'd yet, particularly those handling protocols where the parsing state includes cursor position within accumulated data. If you've extended Netty's frame decoding infrastructure, review whether your implementation preserves parsing state across decode() boundaries or rescans accumulated buffers on each call.