A flaw in Netty’s RtspDecoder causes the RtspMethods.valueOf() function to strip trailing control bytes from RTSP method tokens. An attacker can send a specially crafted RTSP request whose method ends with such a byte—for example, PLAY\\x00—so that the decoder normalizes it to a legitimate PLAY request. The application receives a fully valid request object and cannot distinguish it from a clean token, allowing the attacker to bypass method-based access controls or to launder malicious requests through Netty‑based RTSP proxies, making them appear legitimate to backend systems.

All Red Hat products that ship Netty and expose an RTSP service are affected, including Red Hat AMQ Broker 7, Red Hat AMQ Clients, Red Hat Build of Keycloak, Red Hat Data Grid 8, Red Hat Fuse 7, Red Hat JBoss Enterprise Application Platform 7 and 8, Red Hat Single Sign‑On 7, Red Hat builds of Apache Camel 4 for Quarkus 3, Camel for Spring Boot 4, Apicurio Registry 3, Debezium 3, and Quarkus 3. Any deployment containing a vulnerable Netty library—regardless of specific Netty version—may be impacted unless it has been upgraded to a patched release.

The CVSS score of 7.5 indicates a serious potential impact. EPSS data is not available, so the current exploitation probability cannot be quantified. The likelihood of exploitation is driven by remote access to an RTSP service, as the vulnerability is triggered by sending a crafted RTSP request over the network. No publicly known exploits are documented, but an adversary with network reach to the RTSP port could craft a trailing‑control‑byte request to trick the server into treating it as a legitimate command.