Port 554 – RTSP (Real-Time Streaming Protocol)

Port 554 is the default port for RTSP (Real-Time Streaming Protocol), the protocol that controls streaming media sessions — think of it as the remote control for a video or audio feed. An RTSP client sends verbs like OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, and TEARDOWN to start, seek, and stop a stream, while the actual media travels on a separate transport — normally RTP, either over UDP or interleaved back through the RTSP TCP connection. RTSP is defined in RFC 2326 (RTSP 1.0) and RFC 7826 (RTSP 2.0), and it listens on TCP and UDP 554 by default. In the real world an open port 554 almost always means one thing: an IP camera, NVR/DVR, or media server exposing a live video feed. That’s why it’s one of the first ports worth chasing on any host — if the stream isn’t locked down, anyone who can reach 554 can watch it.

Why It’s Open

RTSP is the standard control channel for surveillance and streaming gear, so port 554 turns up on IP cameras (Hikvision, Dahua, Reolink, Foscam, Uniview, Amcrest, Tapo, and hundreds of white-label clones), on NVRs and DVRs, on video doorbells and baby monitors, and on media/streaming servers built on the live555 or GStreamer stacks. Vendors ship it enabled by default so the camera can be pulled into VLC, a video-management system, or a phone app.

The same device almost always exposes more than just 554. There’s usually a web UI on port 80 or port 443, an ONVIF endpoint, and sometimes an alternate RTSP listener on 8554 or an RTMP feed on 1935. Where 554 answers, those neighbours are one scan away — and they often hold the credentials that unlock the stream. Port 554 is also frequently port-forwarded straight to the internet because someone wanted “remote viewing,” usually without realising the protocol has no encryption and, on many devices, no meaningful authentication.

Common Risks

• Unauthenticated or default-credential stream access. Enormous numbers of cameras expose RTSP with no authentication at all, or with vendor defaults like admin:admin, admin:12345, or a blank password. Anyone who guesses the stream path — rtsp://<ip>:554/live.sdp, /h264/ch1/main/av_stream, /Streaming/Channels/101, and so on — can open the live feed in VLC or ffmpeg. This is the headline RTSP finding.
• Sensitive surveillance exposure. An open feed leaks live video of homes, lobbies, offices, server rooms, factory floors, or critical infrastructure. That’s a direct privacy and physical-security breach, and a reconnaissance goldmine for whatever comes next.
• Cleartext protocol. Plain RTSP is unencrypted, and RTSP Basic authentication sends credentials as trivially reversible base64 that anyone on the path can sniff and replay. The RTP media stream itself is unencrypted too.
• Fingerprintable device info. OPTIONS and DESCRIBE responses, plus the Server: header, routinely disclose the RTSP server (frequently live555), the camera model, and the firmware version — a straight line to a matching firmware CVE.
• Vulnerable RTSP server code. The dominant embedded RTSP library, live555 / liblivemedia, has a run of memory-corruption bugs in its request parser (see the CVEs below), and the DVR/camera web stacks fronting the feed carry their own auth-bypass and RCE flaws.
• IoT-botnet exposure. An internet-facing camera is a prime botnet target. RTSP itself is rarely the infection vector — that’s usually the Telnet or web side — but an open 554 is a reliable signal that a soft, rarely-patched camera is sitting there, and its feed is readable in the meantime.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 554 <target>
nmap -sU -sV -p 554 <target>

List RTSP methods and brute-force stream URLs (NSE)

nmap -p 554 --script rtsp-methods,rtsp-url-brute <target>

rtsp-methods reports which verbs the server supports (via OPTIONS); rtsp-url-brute tries a dictionary of common camera stream paths and validates them with DESCRIBE.

Send a raw OPTIONS request with netcat

printf 'OPTIONS rtsp://<target>:554/ RTSP/1.0\r\nCSeq: 1\r\n\r\n' | nc <target> 554

Discover routes and brute credentials with Cameradar

cameradar -t <target>

Cameradar (Ullaakut/cameradar) is the go-to RTSP tool: it scans RTSP endpoints, then runs dictionary attacks to brute-force both the stream routes and the credentials.

Brute-force credentials with Hydra

hydra -L users.txt -P passwords.txt rtsp://<target>

Open the stream once you have a URL

ffprobe "rtsp://<user>:<pass>@<target>:554/<path>"
ffmpeg -i "rtsp://<user>:<pass>@<target>:554/<path>" -frames:v 1 grab.jpg
vlc "rtsp://<user>:<pass>@<target>:554/<path>"

Grabbing a single frame with ffmpeg (or a snapshot in VLC) is the clean, non-disruptive way to prove an exposed feed. Log every open port 554, every working stream path, and every credential you confirm so the evidence lands in the pentest report instead of a scratch terminal you’ll lose. Wireshark’s rtsp display filter is handy for confirming cleartext Basic auth on the wire.

What to Look For

Known CVEs and Exploits

RTSP’s biggest real-world exposure isn’t a single patchable bug — it’s the configuration: unauthenticated and default-credential camera feeds that need no exploit at all. The memory-corruption CVEs that do exist cluster in the live555 / liblivemedia RTSP server library, which is embedded in a huge range of cameras, NVRs, and streaming servers, and in DVR/camera firmware fronting the feed.

• CVE-2019-7314 — Use-after-free in live555 / liblivemedia before 2019.02.03. Mishandling the termination of an RTSP stream after RTP/RTCP-over-RTSP has been set up crashes the RTSP server (segmentation fault) with possible further impact. CVSS 3.0 base 9.8 Critical.
• CVE-2020-24027 — Buffer overflow in live555 / liblivemedia 20200625 in the server’s handling of the RTSP PLAY command when it specifies seeking by absolute time. CVSS 3.1 base 9.8 Critical.
• CVE-2013-6934 — Integer underflow in parseRTSPRequestString in live555, triggered by a leading space in an RTSP message, leading to an infinite loop and buffer overflow (DoS, possible code execution). It affects the library both as a server and as used in the VLC RTSP client, so it cuts both ways. CVSS 2.0 base 7.5 High.
• CVE-2018-9995 — Authentication bypass in TBK DVR4104 / DVR4216 devices and their many rebrands (QSee, Night OWL, CeNova, Novo, Securus, and more) via a crafted Cookie: uid=admin header. It lives in the DVR’s HTTP web interface, not the RTSP service itself — but it hands an attacker the admin credentials that gate every camera’s RTSP feed, which is why it belongs in any port-554 review. CVSS 3.x base 9.8 Critical, listed in CISA’s Known Exploited Vulnerabilities catalog.

A caution while you research: many “RTSP CVEs” cited online are actually camera web-interface bugs mislabelled as RTSP — for example the D-Link /config/getuser password disclosure (CVE-2020-25078) and the WIFICAM .ini credential leak (CVE-2017-8225) are both HTTP flaws, not RTSP. They still matter to an exposed camera, but they don’t live on port 554.

Mitigation

• Never expose port 554 to the internet. Keep cameras, NVRs, and DVRs behind the firewall and reach them over a VPN — not a port-forward. This single change removes the vast majority of RTSP risk.
• Require authentication and change every default credential. Turn off anonymous stream access, set strong per-device passwords, and prefer Digest over Basic authentication so credentials aren’t sniffable.
• Disable RTSP if you don’t use it. Plenty of deployments only ever view cameras through a vendor app or cloud and never need the raw stream open.
• Segment surveillance devices. Put cameras and recorders on their own VLAN, isolated from the corporate LAN and blocked from the internet.
• Patch firmware and the RTSP server. Update camera/NVR firmware and any live555-based service to close the parser and auth-bypass bugs above.
• Use RTSPS / TLS where supported. Where the device offers RTSP over TLS (RTSPS) or SRTP, prefer it so the control channel and credentials aren’t sent in the clear.

Real-World Example

Exposed RTSP is not a theoretical problem — sites like Insecam have for years indexed thousands of unsecured camera feeds worldwide, most of them nothing more than default-credential or wide-open RTSP streams anyone can open in a browser or VLC.

The DVR side shows how it turns into full compromise. TBK DVRs (and their many rebrands) ship the CVE-2018-9995 cookie auth bypass alongside an internet-facing RTSP feed on 554. An attacker scans for the DVR web UI, sends Cookie: uid=admin to dump the administrator password, then uses those credentials to open every attached camera’s RTSP stream — and conscripts the box into a DDoS botnet on the way out. Fortinet’s sensors logged more than 50,000 exploitation attempts against CVE-2018-9995 in April 2023 alone, and the FBI has warned of campaigns (HiatusRAT among them) scanning the internet specifically for vulnerable web cameras and DVRs. An open port 554 is often the first breadcrumb that leads an attacker to exactly that kind of device.

FAQ

What is port 554 used for?

Port 554 is the default port for RTSP (Real-Time Streaming Protocol), the control channel that starts, pauses, seeks, and stops streaming media sessions — most commonly the live video from IP cameras, NVRs, and DVRs. RTSP only controls the session; the actual audio and video ride a separate RTP transport. It listens on both TCP and UDP 554.

Is port 554 dangerous to leave open?

On the internet, yes. RTSP is unencrypted, cameras are frequently left with no authentication or default passwords, and an exposed 554 leaks a live video feed to anyone who finds it. Treat an internet-facing port 554 as something to firewall or put behind a VPN, not to harden in place.

What service runs on port 554?

RTSP. On real devices the RTSP server is usually embedded firmware — very often built on the live555 / liblivemedia library — inside an IP camera, NVR, DVR, or media server.

How do I access an RTSP stream on port 554?

With a URL of the form rtsp://<user>:<pass>@<ip>:554/<path>, opened in VLC, ffmpeg/ffprobe, or a viewer. The <path> is vendor-specific (for example /Streaming/Channels/101 on Hikvision or /h264/ch1/main/av_stream on Dahua); nmap --script rtsp-url-brute and Cameradar exist precisely to discover the correct path and credentials.

Does RTSP use TCP or UDP?

Both are registered on 554. The RTSP control connection is normally TCP; the RTP media can be delivered over UDP or interleaved back over the same TCP connection when UDP is blocked. When enumerating, scan both (nmap -sU -sV -p 554).

How do I close or secure port 554?

Firewall TCP/UDP 554 so it isn’t reachable from untrusted networks, reach cameras over a VPN instead of a port-forward, disable RTSP if it isn’t needed, change every default credential and require authentication, segment cameras onto their own VLAN, and patch firmware. Rescan with nmap -p 554 <target> to confirm the change.

TL;DR

• Service: RTSP (Real-Time Streaming Protocol) — the control channel for IP-camera, NVR, and DVR video
• Default port: 554/TCP and 554/UDP (media rides RTP; an alternate RTSP listener is often on 8554)
• Biggest risk: unauthenticated or default-credential live camera feeds, plus memory-corruption bugs in live555-based RTSP servers
• Mitigation: never expose 554 to the internet, require auth and change defaults, disable RTSP if unused, segment cameras, patch firmware, prefer RTSPS/TLS