{"id":"CVE-2026-93565","aliases":[],"url":"https://o3.security/vulnerability/CVE-2026-93565","summary":"### Summary\r\n`RtspMethods.valueOf()` silently strips trailing control bytes (any character with code point <= 0x20, the full range that `String.trim()` removes) before performing a…","details":"### Summary\r\n`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\r\n`PLAY` request.\r\n\r\nThis 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.\r\n\r\n### Reproduction\r\n\r\nMinimal wire-level reproduction\r\n\r\nSend the following raw bytes to any Netty-based RTSP server using R","published":"2026-09-18T15:17:20.093","modified":"2026-09-18T15:17:20.093","cvss":{"score":7.5,"severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N"},"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[],"fix":null,"references":[{"type":"WEB","url":"https://access.redhat.com/security/cve/CVE-2026-93565"},{"type":"WEB","url":"https://bugzilla.redhat.com/show_bug.cgi?id=2536952"}],"provenance":{"sources":["OSV.dev","NVD","FIRST.org (EPSS)"],"lastVerified":"2026-09-18T15:17:20.093"}}