[Live-devel] [Security Vulnerability Report] RTSP Session Hijacking via Session Token Reuse Without Re-Authentication - LIVE555 v2026.04.01
cui13969607249 at outlook.com
cui13969607249 at outlook.com
Wed Apr 22 08:02:50 PDT 2026
Dear LIVE555 Maintainers,
I am writing to report a potential security vulnerability I discovered in the
LIVE555 Streaming Media library.
Summary
A potential high-severity RTSP session hijacking issue exists in the RTSP
server session handling logic.
For in-session commands (e.g., PLAY, PAUSE, TEARDOWN, GET_PARAMETER,
SET_PARAMETER), the server appears to rely on the Session identifier as a
bearer token and does not enforce re-authentication (or session-binding
checks) on that path.
If an attacker obtains a valid Session ID, they may be able to control or
terminate another client’s RTSP session from a separate connection.
Affected Version
* Version: live.2026.04.01 (official release from download.live555.com)
* Component: liveMedia RTSP server session handling (RTSPServer.cpp)
* Discovery date: 2026-04-22
Vulnerability Details
Observed code path in liveMedia/RTSPServer.cpp (official source):
* Session lookup and reuse:
* RTSPServer.cpp:819
* RTSPServer.cpp:821
* In-session commands dispatched directly:
* RTSPServer.cpp:891
* RTSPServer.cpp:897
* In-session handler entry (no mandatory re-authentication observed on this
path):
* RTSPServer.cpp:1682
Potential root cause: Authentication is enforced during earlier phases (such
as DESCRIBE/SETUP), but in-session command handling does not appear to require
renewed authentication or strong binding of Session to the original
authenticated connection context.
Steps to Reproduce (locally verified)
1. Build and run testOnDemandRTSPServer with ACCESS_CONTROL enabled.
2. Use valid credentials (username1/password1) to complete Digest auth and
send SETUP.
3. Observe server accepts the request and the original client session is
invalidated.
Reproduction Evidence (excerpt)
* STEP3 status: RTSP/1.0 200 OK
* SESSION=70C812EF
* ATTACK status: RTSP/1.0 200 OK
* VERIFY status: RTSP/1.0 454 Session Not Found
Impact
* Integrity: Unauthorized session control commands can be issued.
* Availability: Attackers can disrupt service by forcing TEARDOWN/PAUSE.
* Prerequisite: Attacker needs a valid session ID (e.g., obtained via
plaintext RTSP sniffing, logs, proxy visibility, or other leakage vectors).
Potential Classification
* CWE candidates:
* CWE-306 (Missing Authentication for Critical Function)
* CWE-639 (Authorization Bypass Through User-Controlled Key)
* CVSS draft vector (for your review):
* AV:N / AC:L / PR:N / UI:N / S:U / C:L / I:H / A:H
*
Likely high severity range.
Suggested Fix
1. Enforce authentication (or equivalent authorization checks) for in-session
commands:
PLAY/PAUSE/TEARDOWN/GET_PARAMETER/SET_PARAMETER.
2. Bind session usage to original authenticated context (e.g., connection/
source/IP/token binding).
3.
Add regression tests:
After a legitimate session is established, unauthenticated TEARDOWN from
a second connection must fail (401/454) and must not terminate the original session.
Best regards,
CUI Jiyuan
cui13969607249 at outlook.com<mailto:cui13969607249 at outlook.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20260422/2469a7db/attachment.htm>
More information about the live-devel
mailing list