Netty XmlFrameDecoder EUVD-2026-58083

Exploitation requires that the target application has explicitly added io.netty.handler.codec.xml.XmlFrameDecoder to its Netty channel pipeline - this decoder is not included in any default Netty server configuration and must be deliberately configured by the application developer. The Maven artifact io.netty:netty-codec-xml must be present as a runtime dependency. No authentication, prior foothold, or special network position is required beyond TCP connectivity to the listening port; CVSS PR:N confirms unauthenticated access suffices. Exploitation is strictly limited to Netty deployments that: (1) include the netty-codec-xml artifact, (2) explicitly configure XmlFrameDecoder in a channel pipeline, and (3) expose that channel to untrusted network clients. Standard Netty HTTP servers, gRPC services, and WebSocket endpoints are not affected. The 1 MB maxFrameLength acts as an amplifier - larger limits increase the CPU cost of each attack connection.

The CVSS 3.1 score of 7.5 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H is well-calibrated for this vulnerability. Attack complexity is genuinely low: no authentication, no race condition, no specific server state is required beyond the presence of XmlFrameDecoder in the pipeline. The high availability impact is realistic - pinning an EventLoop thread causes a full denial of service for all connections on that thread. The critical limiting factor is deployment scope: XmlFrameDecoder is not part of any default Netty pipeline and must be explicitly added by application developers; only services that handle XML-framed protocols over Netty are exposed. KEV status is not confirmed - no CISA KEV listing was provided - and no EPSS data is available in the provided intelligence. No public exploit code has been identified at time of analysis, though the GHSA advisory details are sufficient to guide reproduction. On balance, this is a genuine priority for any Netty application using XmlFrameDecoder, but the broad Netty ecosystem (HTTP, gRPC, WebSocket servers) is not affected unless the XML codec is explicitly configured.

An unauthenticated attacker connects to a port exposed by a Netty application that has XmlFrameDecoder in its pipeline and slowly sends a stream of </ byte pairs at a low rate to avoid triggering connection timeouts. As the accumulated buffer approaches the configured maxFrameLength (1 MB by default), each new packet arrival triggers a complete rescan of the buffer, consuming progressively more CPU per invocation. Within seconds the EventLoop thread reaches 100% CPU utilization and becomes unable to process any other connections it manages, effectively taking the service offline for all clients on that thread with a trivial amount of malformed input.