The vulnerability arises because RtspMethods.valueOf() silently removes trailing control bytes (characters with code point <= 0x20) from RTSP method tokens before performing a cache lookup against pre-populated method constants. As a result, a wire-delivered RTSP request with a method token ending in a trailing control byte (e.g., PLAY\x00 or PLAY\r) is decoded as a successful PLAY request with the cached singleton method object. This prevents the application from distinguishing between a clean method token and one with trailing control bytes. The root cause is similar to previous issues (#16723 and #16971) fixed in sibling components, but the fix for HttpMethod.valueOf() did not apply to RtspMethods.valueOf(), which has its own check that allows the malformed token to hit the cache before the hardened constructor is invoked.

An attacker can send RTSP requests with method tokens containing trailing control bytes that are accepted as valid by the server, potentially bypassing validation checks that rely on exact method token matching. The CVSS score of 7.5 (high) with an impact vector indicating no confidentiality or availability impact but high integrity impact suggests that the vulnerability could allow unauthorized modification or injection of RTSP requests that appear valid to the application layer. There is no indication of direct confidentiality or availability compromise.

Patch status is not yet confirmed — check the vendor advisory at https://access.redhat.com/security/cve/CVE-2026-93565 for current remediation guidance. No official fix or patch links are provided in the input data. Until a fix is available, consider additional input validation or filtering at the application or network level to detect and block RTSP method tokens with trailing control bytes.