Netty CVE-2026-93494

Exploitation requires that the target application uses Netty's STOMP codec - specifically the StompSubframeDecoder - on a network endpoint the attacker can reach; the trigger is a STOMP frame whose body is sent without its terminating null byte. This is not a Netty default: only applications or Red Hat middleware components (e.g. JBoss EAP 7, Fuse 7, Single Sign-On 7, Camel for Spring Boot 4) that enable STOMP-over-TCP/WebSocket messaging are affected. No authentication (PR:N) or user interaction (UI:N) is needed, but impact is limited to availability and accrues gradually - a single frame leaks one buffer, so a practical DoS requires sustained repeated frames to exhaust memory, and the effect depends on JVM heap/direct-memory limits and restart behavior.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) describes a network-reachable, unauthenticated, availability-only denial of service - no confidentiality or integrity impact. All three exploitation-likelihood signals are absent from the input: no EPSS probability, no CISA KEV listing, and no public POC, so this is 'no public exploit identified at time of analysis' rather than an actively-exploited priority. The severity is driven entirely by the A:H DoS impact; there is no code execution or data exposure. Critically, the vector's PR:N/UI:N assumes the vulnerable code path is reachable, but exploitation is fundamentally gated on the target application actually using Netty's STOMP codec (StompSubframeDecoder) on an attacker-reachable listener - a non-default, application-specific choice not captured in the base score. This is a genuine but conditional DoS: a real concern for services that terminate STOMP-over-TCP/WebSocket, but low real-world urgency absent evidence of exploitation and given the narrow affected surface. No conflicting signals in the data; the main gap is that the base metrics do not reflect the STOMP-codec prerequisite.

An attacker who can reach a service that terminates STOMP frames via Netty's StompSubframeDecoder repeatedly sends crafted STOMP frame bodies that omit the terminating null byte, causing the decoder to allocate ByteBuf buffers that are never released. Sustained over many frames, the leaked buffers exhaust heap/direct memory and crash or hang the application, producing a denial of service. No authentication or user interaction is required, and no public exploit code is currently identified.