CVE-2026-93565: Io.netty/netty-codec-http: netty rtspdecoder method-token smuggling via trailing control byte

Published Sep 18, 2026
·
Updated

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

Affected Software

2 affected components
Netty netty-codec-http>=4.2.0.Final<=4.2.17.Final
maven/io.netty/netty-codec-http=4.1.137.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven:io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.2.0.Final
  2. Upgrade

    Upgrade maven:io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.2.17.Final
  3. Upgrade

    Upgrade maven:io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.1.137.Final
  4. Compensating control

    If a Netty-based RTSP server/proxy makes authorization/routing decisions based on request.method(), add a compensating control upstream of Netty (e.g., reject or normalize RTSP method tokens containing trailing control bytes such as NUL (0x00) or CR (0x0D) immediately before the space).

Event History

Sep 18, 2026
Data Sourced
via Red Hat·10:00 AM
DescriptionSeverityAffected Software
CVE Published
via MITRE·02:18 PM
Data Sourced
via MITRE·02:18 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

What traffic and deployment conditions make this relevant?

The issue is relevant to Netty-based RTSP servers that use RtspDecoder to process wire-delivered RTSP requests. An attacker can send a method token with a trailing control byte immediately before the separating space, such as PLAY followed by a null byte or carriage return.

2

Does exploitation require authentication or user interaction?

No. The supplied severity vector indicates network reachability, low attack complexity, no privileges required, and no user interaction.

3

How would a malformed request appear to the application?

A request such as PLAY followed by a trailing control byte is decoded as a successful request with decoderResult().isSuccess() true. Its method is RtspMethods.PLAY, using the same cached singleton reference as a clean PLAY request, so the application layer cannot distinguish it from a normal PLAY request.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203