RTSP security

What RTSP guarantees, what it does not, and why the version that fixed the problem never reached the wire.

Grep RFC 2326 for "TLS", "SSL" or "rtsps" and nothing comes back but two hits on "CTLs" in the ABNF, out of 5,155 lines. That document — April 1998 — is what essentially every camera on your network implements, and its whole provision for control-channel confidentiality is one sentence in §16: "In environments requiring tighter security for the control messages, the RTSP control stream may be encrypted." It names no mechanism and no cipher. A camera offering rtsps:// on 322 is implementing something RFC 2326 never described. The same section blesses HTTP Basic, so the 1998 baseline permits camera credentials in the clear on TCP/554.

Which version is actually on the wire#

RTSP 2.0 fixed this on paper. RFC 7826, December 2016, obsoletes RFC 2326 and is "not backwards compatible other than in the basic version negotiation mechanism". §19.2: "RTSP agents MUST implement RTSP over TLS", signalled by rtsps on TCP/322, and a policy-secure server must answer an rtsp: request with a 301 to the rtsps: Location. §21.2.2: "RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and, thus, SAVP." Basic becomes legal only inside TLS with confidentiality enabled. RECORD and ANNOUNCE — the 1.0 methods that let a client push media into a server — are gone, along with RTSP message transport over UDP, dropped "due to missing interest and to broken specification".

None of it reached the estate. Three checks:

• ONVIF Streaming Spec v26.06 (June 2026) §5.2.2.1: "All devices and clients shall support RTSP ([RFC 2326])". RFC 7826 is in the reference list, cited once in the body, for timeout handling.
• FFmpeg, a common RTSP client under VMS and analytics ingest paths, formats every request as "%s %s RTSP/1.0\r\n" — zero occurrences of RTSP/2.0 in libavformat/rtsp.c (read 5 September 2026).
• live555, in the widely mirrored rgaufman distribution, hard-codes RTSP/1.0 into every status line RTSPServer.cpp emits. We could not reach live555.com to confirm the same of the upstream tarball — both published changelog URLs returned 404 on 5 September 2026 — and the fork is not identical to upstream: CVE-2026-1200, an increaseBufferTo segfault, is specific to it.

We could not find or test a shipping device, NVR or VMS that negotiates RTSP/2.0 — no evidence of deployment rather than proof of absence.

RTSP controls, RTP carries#

DESCRIBE returns an SDP body — codecs, payload types, per-track control URIs — so a device that does not authenticate it hands over its media topology before checking a credential. ONVIF's normative reference for that SDP is RFC 4566, obsoleted by RFC 8866 in January 2021; the June 2026 spec cites the dead one.

The pictures travel over RTP, which has no security of its own. RFC 3550 §9 defers confidentiality to lower layers, and §11 fixes the convention that makes passive capture easy: RTP on an even port, RTCP on the next odd one. A SPAN port between camera and recorder yields the H.264 or H.265 stream straight out of the payloads. Digest on 554 protected the control channel and nothing else.

The destination field#

RFC 2326 documented its own reflection primitive in 1998 and left it open. §16, "Concentrated denial-of-service attack": the SETUP request names where the media goes, so an attacker "may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests". The mitigation is a SHOULD — "an RTSP server SHOULD only allow client-specified destinations for RTSP-initiated traffic flows if the server has verified the client's identity." No published measurement says how many shipping cameras honour it. One SETUP naming an off-box destination, plus a capture on that host, settles it per model.

Transport modes#

ONVIF's transport ladder, §5.1.1 of the Streaming Specification:

Neither unconditionally mandatory transport is encrypted. A device that never signals SecureRTSPStreaming streams plaintext RTP forever and stays conformant. Where one does signal it, ONVIF couples the two channels: "TLS shall be used for RTSP when SRTP is used. The device shall never return RTP/SAVP or the MIKEY in the SDP if the RTSP channel is not secure." How many conformant devices signal it is not published; we found no dataset that records it.

Interleaved media rides the control connection, framed by a dollar sign (0x24), a one-byte channel identifier and a two-byte big-endian length (RFC 2326 §10.12), capped at 65535 octets per PDU (RFC 7826 §14). A monitor then sees one port-554 conversation and cannot separate media from control by port.

HTTP tunnelling should worry a firewall team. ONVIF makes RTP/RTSP/HTTP/TCP a "shall", the POST data base64-encoded, so RTSP passes egress filtering that permits only web traffic: closing 554 is not containment. ONVIF adds that in this mode "the device shall not authenticate on the HTTP level", so the credential check stays inside the tunnel, invisible to a proxy enforcing HTTP auth. The normative reference is an Apple QuickTime paper at an opensource.apple.com URL that 404s (checked 5 September 2026). live555's CVE-2019-6256 is a crash in that path, in handleHTTPCmd_TunnelingPOST.

Ports do not bound the problem. Modat's March 2026 internet-wide scan found 973,819 active RTSP services; 545,947 of them — 56.06% — were on 554, and the other 43.9% answered elsewhere, led by 555 (24,515), 8554 (12,847) and 556 (12,352). 8,074 services, 0.83%, returned a live video frame with no credentials required; Modat tested no credentials and bypassed no authentication. Method and caveats are on how cameras become internet-exposed, registered numbers and vendor alternates on camera ports and protocols. What is left after that is placement — see segmenting a camera network.

Authentication, and what each mode gives away#

Basic authentication carries base64, an encoding. RFC 2617 §4.1: "The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password." One captured Authorization header is a working camera credential, and this is not a legacy path: Dahua's HTTP API document for its IP cameras says the RTSP GetStream URL "supplies basic authentication and digest authentication ways".

Digest hashes the password, and everything needed to attack the hash travels in the same two messages. ONVIF Core requires digest or JWT-based authorization and defaults the hash to MD5 — the mechanism and its consequences are on ONVIF security. What a capture yields is one 401 challenge and the response to it: realm, nonce, username, URI and the MD5 response value — an offline-crackable verifier, obtained without touching the device again. RFC 7616 §5.1 says digest with human-memorable passwords "is vulnerable to dictionary attacks" and SHOULD be used "only ... over a secure channel like HTTPS".

Then the session token, a bearer credential with no binding to the connection that earned it. RFC 2326 §16 admits it: "there is no relation between a transport layer connection and an RTSP session." CVE-2026-41470 (VulnCheck, 19 May 2026) is that realised in code: in live555 before 2026.04.22, an attacker holding a valid Session token issues PLAY or TEARDOWN from a second, unauthenticated connection and kills a victim's live stream.

Shipping cameras reproduce both classic digest errors, and some skip authentication altogether:

The Tattile and Zavio rows are thirteen years apart and are the same defect. CVE-2025-66049 (Vivotek IP7137) and CVE-2024-51362 (LSC Smart Connect Indoor) repeat it on 8554.

Stream paths, and what an inventory cannot infer#

RFC 2326 §3.2 is explicit that an RTSP URL's path components "are opaque to the client and do not imply any particular file system structure for the server", and RFC 7826 keeps the sentence. Each vendor invented a grammar:

Hikvision's dated technical bulletin on RTSP URLs no longer resolves; the format above comes from its ISAPI documentation and a 2022 support article. The Dahua grammar is documented in that vendor's HTTP API for IPC v1.40 §4.1.1, which we could not retrieve from a Dahua-hosted URL.

Discovery therefore runs on a path dictionary and brute force, which is why ONVIF §5.2.1 says the stream URI "is returned in response to the GetStreamUri command" rather than being constructible. A camera inventory that lists 554/open is not a stream inventory — you learn the stream set from GetStreamUri or from a path dictionary, and the two disagree.

The embedded servers#

Library CVEs propagate across brands, because one RTSP server sits inside firmware from vendors with no other relationship. live555 is the clearest case: NVD returns 25 records from 2007 to 2026, with a real cluster in the pre-authentication request path: parseRTSPRequestString (CVE-2007-6036, CVE-2013-6933/6934), the HTTP packet-parsing stack overflow in 0.92 that Talos scored 10.0 and NVD 9.8 (CVE-2018-4013), parseAuthorizationHeader (CVE-2019-9215), a 9.8 use-after-free on stream teardown (CVE-2019-7314). A second cluster, CVE-2025-65404 through -65408, needs the server to be serving crafted media, and NVD rates those 6.5 with user interaction required.

The Authorization header is a recurring parsing sink across codebases that share no code — though the four below are not equally reachable.

The GStreamer bug runs the other way: gst-plugins-base sits in ingest pipelines, so the malformed header is one a camera sends to its recorder, and a device an attacker already controls can drop the process that would have kept the evidence. The Ambarella entry earns its place differently — NVD carries the vendor's statement that "The RTSP library is used for DEMO only, using it in product is a customer's behavior", filed against a shipping retail dog camera. That is the argument you will have with a supplier, in one sentence.

What we cannot tell you is which RTSP server is inside Hikvision and Dahua firmware. No SBOM, GPL source release or firmware-analysis paper we could find identifies it, so do not assume live555 CVEs reach the two largest vendors by volume.