A flaw was found in Netty RtspDecoder. The `RtspMethods.valueOf()` function incorrectly strips trailing control bytes from method tokens in Real-Time Streaming Protocol (RTSP) requests. A remote attacker can exploit this by sending a specially crafted RTSP request, leading to method-token smuggling. This vulnerability allows an attacker to bypass method-based access controls and can also be used to launder malicious requests through Netty-based RTSP proxies, making them appear legitimate to backend systems.
Metrics
Affected Vendors & Products
| Vendors | Products |
|---|---|
|
Redhat
Subscribe
|
Amq Broker
Subscribe
Amq Clients
Subscribe
Apicurio Registry
Subscribe
Build Keycloak
Subscribe
Camel Quarkus
Subscribe
Camel Spring Boot
Subscribe
Debezium
Subscribe
Jboss Data Grid
Subscribe
Jboss Enterprise Application Platform
Subscribe
Jboss Fuse
Subscribe
Quarkus
Subscribe
Red Hat Single Sign On
Subscribe
|
No data.
No data.
No data.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
See https://github.com/netty/netty/security/advisories/GHSA-h75q-xqrh-59rf for fixed versions and remediation guidance.
References
History
Sat, 19 Sep 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
Fri, 18 Sep 2026 21:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | ### 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 | A flaw was found in Netty RtspDecoder. The `RtspMethods.valueOf()` function incorrectly strips trailing control bytes from method tokens in Real-Time Streaming Protocol (RTSP) requests. A remote attacker can exploit this by sending a specially crafted RTSP request, leading to method-token smuggling. This vulnerability allows an attacker to bypass method-based access controls and can also be used to launder malicious requests through Netty-based RTSP proxies, making them appear legitimate to backend systems. |
Fri, 18 Sep 2026 14:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | ### 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 | |
| Title | Io.netty/netty-codec-http: netty rtspdecoder method-token smuggling via trailing control byte | |
| First Time appeared |
Redhat
Redhat amq Broker Redhat amq Clients Redhat apicurio Registry Redhat build Keycloak Redhat camel Quarkus Redhat camel Spring Boot Redhat debezium Redhat jboss Data Grid Redhat jboss Enterprise Application Platform Redhat jboss Fuse Redhat quarkus Redhat red Hat Single Sign On |
|
| Weaknesses | CWE-1035 | |
| CPEs | cpe:/a:redhat:amq_broker:7 cpe:/a:redhat:amq_clients:2023 cpe:/a:redhat:apicurio_registry:3 cpe:/a:redhat:build_keycloak: cpe:/a:redhat:camel_quarkus:3 cpe:/a:redhat:camel_spring_boot:4 cpe:/a:redhat:debezium:3 cpe:/a:redhat:jboss_data_grid:8 cpe:/a:redhat:jboss_enterprise_application_platform:7 cpe:/a:redhat:jboss_enterprise_application_platform:8 cpe:/a:redhat:jboss_fuse:7 cpe:/a:redhat:quarkus:3 cpe:/a:redhat:red_hat_single_sign_on:7 |
|
| Vendors & Products |
Redhat
Redhat amq Broker Redhat amq Clients Redhat apicurio Registry Redhat build Keycloak Redhat camel Quarkus Redhat camel Spring Boot Redhat debezium Redhat jboss Data Grid Redhat jboss Enterprise Application Platform Redhat jboss Fuse Redhat quarkus Redhat red Hat Single Sign On |
|
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: redhat
Published:
Updated: 2026-09-18T20:22:45.891Z
Reserved: 2026-09-18T09:59:50.676Z
Link: CVE-2026-93565
Vulnrichment
No data.
NVD
Status : Awaiting Analysis
Published: 2026-09-18T15:17:20.093
Modified: 2026-09-18T21:18:47.380
Link: CVE-2026-93565
Redhat
OpenCVE Enrichment
No data.
Weaknesses