CVE-2026-93565 in Netty
Summary
by MITRE • 09/18/2026
### Summary `RtspMethods.valueOf()` silently strips trailing control bytes (any character with code point <= 0x20, the full range that `String.trim()` removes) before performing a cache lookup against its ten pre-populated method constants. A wire-delivered RTSP request whose method token ends with a trailing control byte — for example `PLAY\x00` or `PLAY\r`, immediately before the separating space — is decoded by `RtspDecoder` as a fully successful PLAY request, with `decoderResult().isSuccess() == true and request.method() == RtspMethods.PLAY` (same object reference as the cached singleton). The application layer cannot distinguish this from a clean `PLAY` request.
This is the same root cause as #16723 and #16971, in a sibling that those fixes did not reach. The fix for `HttpMethod` hardened `HttpMethod.valueOf()` directly, but `RtspMethods.valueOf()` has its own independent `checkNonEmptyAfterTrim()` call that runs before the cache lookup — meaning a trailing-control-byte token hits the cache before the hardened `HttpMethod` constructor ever sees it.
### Reproduction
Minimal wire-level reproduction
Send the following raw bytes to any Netty-based RTSP server using R
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in this analysis stems from a critical input validation flaw within the RtspMethods.valueOf() method of the Netty framework. This function is responsible for mapping incoming string tokens into predefined, immutable singleton constants representing valid RTSP methods such as PLAY, DESCRIBE, or OPTIONS. The core technical deficiency lies in how the method handles whitespace and control characters prior to performing a lookup against its internal cache. Specifically, RtspMethods.valueOf() invokes a check that effectively strips trailing control bytes—defined here as any character with a code point less than or equal to 0x20—including null bytes, carriage returns, and line feeds. This behavior mirrors the legacy logic of String.trim(), which removes leading and trailing whitespace but fails to enforce strict token boundaries required for secure protocol parsing. Consequently, when an attacker sends a wire-delivered RTSP request where the method token is followed by such control characters before the mandatory space delimiter, the decoder processes it as valid. For instance, sending PLAY\x00 or PLAY\r results in the RtspDecoder successfully decoding the request, setting decoderResult().isSuccess() to true and assigning the request.method field to the exact same singleton object reference as a clean PLAY command. This silent normalization means that from the perspective of the application layer, there is no distinguishable difference between a properly formatted request and one containing injected control characters, effectively bypassing any security controls or logic that might rely on strict string equality for method validation.
This issue represents a sibling vulnerability to previously reported issues #16723 and #16971, which addressed similar flaws in the HttpMethod class used for HTTP protocol handling. While those fixes hardened the HttpMethod.valueOf() constructor directly, they did not propagate to RtspMethods because it maintains an independent validation path. The RtspMethods implementation performs its own checkNonEmptyAfterTrim() call before attempting a cache lookup. This architectural separation means that even if the underlying string representation is malformed or contains trailing control bytes, the trimming logic executes successfully and returns a valid cached constant. This creates a consistency gap across protocol handlers within the same framework, where HTTP requests might be strictly validated while RTSP requests remain susceptible to normalization-based bypasses. The root cause is fundamentally an improper neutralization of special elements during input processing, allowing attackers to manipulate how the application interprets command boundaries without triggering error states or rejection mechanisms.
The operational impact of this vulnerability is significant for any service relying on Netty’s RTSP implementation for media streaming management. Because the server accepts and processes requests with trailing control characters as valid commands, an attacker can potentially exploit this ambiguity in several ways. First, it may facilitate command injection attacks if downstream components or custom handlers perform additional string matching that does not account for these hidden bytes. Second, it could lead to state confusion where a request intended for one purpose is misinterpreted due to the presence of control characters that might interact unexpectedly with other parts of the protocol parser. Furthermore, this behavior violates the principle of least privilege and strict input validation expected in network protocols. RTSP relies on precise tokenization defined by RFC 2326, which mandates specific formatting rules for method lines. By silently accepting non-compliant requests, the server exposes itself to potential denial-of-service conditions through resource exhaustion if malformed packets are processed deeply into the stack, or more subtly, it undermines integrity checks that depend on exact string matches for authentication tokens or session identifiers embedded in headers following the method line.
To mitigate this vulnerability, immediate remediation is required by updating the RtspMethods.valueOf() logic to enforce strict token boundaries similar to those implemented in HttpMethod. The validation should reject any input containing trailing control characters rather than stripping them silently. This ensures that only syntactically correct RTSP requests are processed at the protocol level. Developers integrating Netty into their applications should also implement additional server-side checks to validate incoming request lines against RFC 2326 specifications, ensuring that method tokens do not contain embedded whitespace or control codes. Monitoring logs for unusual patterns in decoded methods can help detect exploitation attempts while patches are being deployed. This fix aligns with industry standards such as CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and CWE-20 Improper Input Validation, which emphasize the need to reject malformed input rather than attempting to sanitize it in ways that may obscure security-relevant differences. Additionally, this issue relates to ATT&CK technique T1568 Dynamic Resolution Techniques where attackers might use encoding or obfuscation to bypass detection; strict validation prevents such evasion at the protocol parsing layer.