CVE-2026-73507 in Netty
Summary
by MITRE • 08/13/2026
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.xml.XmlFrameDecoder.decode() failed to preserve closing-tag parser state across invocations, so an unauthenticated remote attacker could trickle-feed repeated </ sequences that repeatedly rescanned the accumulated buffer and exhausted an EventLoop thread's CPU, causing denial of service with a maxFrameLength of 1 MB. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability in Netty's XmlFrameDecoder represents a critical denial of service weakness that exploits improper state management during XML parsing operations. This flaw affects versions prior to 4.1.136.Final and 4.2.16.Final, where the XmlFrameDecoder implementation fails to maintain accurate parser state information across multiple decode invocations. The specific technical issue manifests when processing repeated closing tag sequences such as "</" that are fed incrementally to the decoder, creating a scenario where the parser continuously rescans previously processed buffer content rather than maintaining proper state tracking.
The operational impact of this vulnerability enables unauthenticated remote attackers to execute sustained denial of service attacks against systems utilizing affected Netty versions. Attackers can exploit this weakness by sending carefully crafted XML data that consists of repeated closing tag sequences, which causes the EventLoop thread to consume excessive CPU resources through continuous buffer rescanning operations. The vulnerability becomes particularly dangerous when combined with a maxFrameLength setting of 1 MB, as it allows attackers to maintain resource exhaustion over extended periods while remaining within acceptable frame size limits.
This vulnerability aligns with CWE-400, specifically addressing unchecked resource consumption in the context of network application frameworks. The flaw demonstrates characteristics consistent with attack patterns described in the ATT&CK framework under T1498, which covers Network Denial of Service techniques. The issue stems from inadequate state management within the XML parsing pipeline, where the decoder fails to properly track parser progress and maintain consistent buffer processing states across multiple invocation cycles.
The fix implemented in versions 4.1.136.Final and 4.2.16.Final addresses this by ensuring proper preservation of closing-tag parser state information throughout the decode process. This correction prevents the repeated rescanning behavior that previously consumed excessive CPU resources and maintains accurate tracking of parsed content positions. Organizations should prioritize upgrading to these fixed versions immediately, as the vulnerability can be exploited without authentication and requires minimal network traffic to cause significant performance degradation.
The broader implications of this vulnerability extend beyond simple resource exhaustion, as it demonstrates how seemingly minor state management issues in network application frameworks can create substantial security risks. The flaw represents a classic example of how asynchronous processing models can introduce subtle but critical race conditions when maintaining parser state across multiple processing cycles. System administrators should implement monitoring for excessive CPU utilization patterns that may indicate exploitation attempts, while also ensuring proper version control and patch management processes are maintained to prevent similar issues from arising in other components of the network application stack.
Security teams should consider this vulnerability as part of comprehensive network defense strategies, particularly when evaluating asynchronous framework security postures. The attack vector requires no privileged access or authentication credentials, making it particularly dangerous in environments where external network exposure is common. Additional mitigations may include implementing rate limiting on XML processing operations and monitoring for unusual patterns of buffer processing that could indicate exploitation attempts against this specific vulnerability.