Port forwarding a security camera feels like the obvious shortcut — you log into your router, point external port 554 at your camera's LAN IP, and suddenly you can pull the RTSP stream from anywhere. Thousands of tutorials walk you through exactly this process. What they rarely explain is that you've just made your camera reachable by every scanner, bot, and attacker on the internet simultaneously.
The short answer: no, it is not safe to port forward security cameras for anything beyond a throwaway lab environment. This article explains exactly what happens when you do, covers the most significant real-world vulnerabilities in popular camera brands, and shows you what to do instead.
Contents
What Port Forwarding Actually Does to Your Camera
When you create a port forwarding rule on your router, you instruct it to pass all inbound TCP connections on a given external port directly to a device on your LAN. For a security camera, that typically means:
- Port 554 — RTSP video stream (main protocol for IP cameras)
- Port 80 / 8080 — HTTP web interface for camera configuration
- Port 443 — HTTPS interface (if supported by the firmware)
- Port 8000 — Hikvision SDK access port
- Port 37777 — Dahua private protocol port
Once that rule is in place, any machine on the internet that connects to your public IP on port 554 is talking directly to your camera's RTSP daemon. Your router is no longer filtering or inspecting that traffic in any meaningful way. The camera must defend itself — and most do this poorly.
This matters because RTSP was designed for use within trusted networks. The protocol itself has no transport-layer encryption — credentials and video travel in plaintext over the TCP connection. There is no concept of a session token, rate limiting, or connection source verification built into the protocol. Everything that stands between an attacker and your camera's video feed is the camera's own authentication implementation, which has a poor track record across the industry.
Even if your camera has a strong password, port forwarding still exposes the authentication interface itself to the internet. Vulnerabilities in the authentication handler — as seen in multiple CVEs below — can allow attackers to bypass credentials entirely.
Real CVEs: Hikvision, Dahua, and Others
The two largest IP camera manufacturers in the world — Hikvision and Dahua — have both shipped firmware with critical vulnerabilities that affect port-forwarded cameras directly. These are not theoretical risks; they were actively exploited in the wild.
A command injection vulnerability in the web server component of hundreds of Hikvision camera and NVR models. An unauthenticated attacker could send a specially crafted HTTP request and gain full root-level access to the device — without knowing the camera password. The vulnerability affected the HTTP interface (ports 80/443), but cameras with RTSP forwarded were often also running the web interface on the same device. Hikvision released patches in September 2021, but a large proportion of deployed cameras were never updated. CISA issued advisory ICSA-21-336-02 noting active exploitation in the wild.
A pair of authentication bypass vulnerabilities in Dahua IP cameras and NVRs. An unauthenticated remote attacker could bypass the login mechanism entirely by manipulating the authentication sequence, gaining access to the device as an administrator. Affected firmware spans a wide range of Dahua IPC, NVR, and DVR product lines released between 2017 and 2021. These vulnerabilities work over the Dahua private protocol (port 37777) as well as the HTTP interface — both commonly port-forwarded for remote access.
An improper authentication flaw in Hikvision cameras allowed unauthenticated access to the snapshot URI and other sensitive endpoints by appending specific parameters to HTTP requests. This affected a massive install base of Hikvision cameras manufactured through approximately 2016. The cameras remain in widespread use today, and many of them are still internet-accessible via port forwarding with unpatched firmware.
These are not isolated incidents. The IP camera sector has a systematic problem with security: hardware is sold on price, firmware updates are infrequent, and the majority of deployed cameras never receive patches after installation. When you port forward a camera that is two or three years old, you are almost certainly exposing a device that has not been patched against known critical vulnerabilities.
How Shodan Exposes Your Camera to the World
Shodan is a search engine for internet-connected devices. It continuously scans the entire public IPv4 address space, identifying services running on each IP and port combination. Unlike web search engines that index content, Shodan indexes services — including RTSP streams, HTTP camera interfaces, and raw TCP ports.
The moment your camera's RTSP port becomes reachable from the internet, Shodan's scanners will find it — typically within hours. A search for port:554 has_screenshot:true on Shodan returns tens of thousands of live camera feeds. The rtsp:// protocol tag in Shodan searches surfaces cameras that responded with an RTSP banner, including many that are streaming with no authentication at all.
Shodan is not the threat itself — it is a symptom of the threat. If Shodan can find your camera, so can every automated vulnerability scanner looking for exposed Hikvision interfaces, default Dahua credentials, or unpatched RTSP daemons. These scanners run continuously and probe known CVEs automatically within hours of a new exploit being published.
Default Credentials Still Widespread
A large proportion of port-forwarded cameras are still running on factory default credentials (admin/admin, admin/12345, admin/ with a blank password). Studies by security researchers and reports from CISA consistently show that default credential exposure is among the most common attack vectors for IP cameras. Once Shodan indexes your camera's IP and port, credential-stuffing tools will attempt every known default combination for your camera's brand and model within minutes.
The Specific Risks of RTSP Port Forwarding
No TLS on RTSP
Standard RTSP (Real Time Streaming Protocol) on port 554 has no transport-layer encryption. Credentials sent during the RTSP DESCRIBE handshake using RTSP Basic or Digest authentication travel in a form that can be captured by anyone with visibility into the network path. On a shared network or over an ISP that performs traffic inspection, this is a meaningful risk. Even RTSP Digest authentication is susceptible to offline dictionary attacks if the challenge-response exchange is captured.
Firmware Vulnerabilities Are Permanent
Unlike a web server or application where you can push a patch in minutes, camera firmware is updated infrequently and often never. If your camera has a known RCE vulnerability and the manufacturer has stopped releasing updates for that hardware generation — which is common for cameras more than 3-4 years old — the vulnerability is effectively permanent for the lifetime of that device. Port forwarding that camera means permanently maintaining an exposed attack surface with a known, unresolvable flaw.
Port Scanning Amplifies Exposure
Opening port 554 also signals to port scanners that an interesting service may be present. Scanners that identify an RTSP service will then probe additional ports on the same IP looking for the HTTP management interface, SDK ports, and telnet. A single port forward for RTSP access can inadvertently expose other services running on the same camera that you had no intention of making publicly accessible.
ISP-Level Complications
Many residential and business ISPs block inbound connections on port 554 entirely. Some block all non-standard inbound ports. In these cases port forwarding simply will not work, leading users to try alternate ports (554 forwarded to external 8554, etc.) — but this provides no additional security and adds management overhead.
Security Comparison: Port Forwarding vs. Cloud Relay
| Property | Port Forwarding (RTSP) | Cloud Relay (TheRelay) |
|---|---|---|
| Camera reachable from internet | Yes — directly | No — outbound only |
| Indexed by Shodan | Yes | No |
| CVE exploitation surface | Fully exposed | Zero (camera not reachable) |
| Transport encryption | None (plaintext RTSP) | Encrypted (SRT + AES) |
| Credential exposure risk | High (plaintext on wire) | None (stays on LAN) |
| Token-based access control | No | Yes |
| Works if ISP blocks port 554 | No | Yes |
| Works behind CGNAT | No | Yes |
| Requires router access | Yes | No |
| Stable endpoint (no dynamic IP) | No (needs DDNS) | Yes |
How TheRelay Eliminates the Exposure
TheRelay works fundamentally differently from port forwarding. Instead of opening an inbound path from the internet to your camera, a lightweight agent runs on a machine inside your LAN — a PC, a small server, a Raspberry Pi. That agent:
- Reads the RTSP stream from your camera locally, over your LAN (192.168.x.x to 192.168.x.x — never leaving the local network)
- Opens a single outbound encrypted connection to the TheRelay cloud servers (the same direction as any HTTPS request your browser makes)
- Tunnels the video through that outbound connection to a stable cloud endpoint
Your camera never receives a single inbound connection from the internet. There is no port forwarding rule. Your router's firewall remains completely unchanged. From your camera's perspective, only the agent on your LAN is pulling its stream — exactly as if you were watching it locally.
The cloud endpoint is protected by token-based access control. Consumers of the stream authenticate with a token; the camera's own credentials are never transmitted beyond your LAN. If a token is compromised, you revoke it in the dashboard — the camera itself is unaffected.
This architecture means that CVE-2021-36260, CVE-2021-33044, and any future vulnerabilities discovered in your camera's firmware are irrelevant for remote access security. An attacker cannot reach the vulnerable RTSP daemon or HTTP interface from the internet because there is no route to it.
Setup in Under 30 Seconds
Install the agent on any machine on your LAN, add your camera RTSP URL, and receive a cloud endpoint:
# Example: add a Hikvision camera main stream
rtsp://admin:yourpassword@192.168.1.64:554/Streaming/Channels/101
# TheRelay cloud endpoint (accessed with token)
rtsp://stream.therelay.net:554/live/your-camera-id?token=your-tokenThe agent machine needs outbound internet access on port 443 (standard HTTPS). No inbound ports, no firewall changes, no router configuration.
Access Your Cameras Without the Risk
Stop exposing your cameras to the internet. TheRelay gives you a secure cloud endpoint in under 30 seconds — no port forwarding, no CVE exposure, $2/stream/month.
Get Started Free →Frequently Asked Questions
Is port 554 safe to open on a router?
Port 554 is the standard RTSP port. Opening it on your router passes all inbound connections directly to your camera's RTSP daemon with no transport-layer encryption. Credentials and video travel in plaintext. Combined with the significant history of authentication bypass CVEs and RCE vulnerabilities in popular camera firmware, leaving port 554 open to the internet is considered high risk for production deployments. For home labs where the camera contains no sensitive footage, the risk may be acceptable, but it is never truly safe in the sense of being protected against known exploits.
What ports do IP cameras use?
IP cameras commonly use the following ports:
- 554 — RTSP video streaming (universal)
- 80 / 8080 — HTTP configuration interface
- 443 — HTTPS interface (where supported)
- 8000 — Hikvision SDK / client software port
- 37777 — Dahua private protocol
- 23 — Telnet (older/lower-end cameras; often enabled by default)
Port forwarding any of these exposes the corresponding service to the entire internet with no additional protection beyond whatever authentication is built into that service — which, as the CVEs above demonstrate, is often insufficient.
Can hackers see my camera if I port forward?
Yes — if your camera has a known vulnerability, default credentials, or weak firmware. Automated scanners like Shodan index open RTSP ports continuously. Once your camera's IP and port are known, credential-stuffing tools will attempt every known default username/password combination for your camera brand. If your firmware has an authentication bypass vulnerability such as CVE-2021-36260 or CVE-2021-33044, an attacker does not even need your credentials — they can bypass authentication entirely. Many documented cases exist of publicly accessible cameras being viewed and in some cases hijacked within hours of being port-forwarded.
Should I use DDNS with port forwarding for cameras?
DDNS (Dynamic DNS) solves the problem of your router's public IP address changing over time by giving it a stable hostname (e.g., myhome.ddns.net). It does not make port forwarding safer — it simply makes your exposed camera consistently reachable. All the risks of port forwarding remain identical. DDNS is worth using if you have decided to accept the risk of port forwarding, but it is not a security measure. A cloud relay is a meaningfully safer alternative that avoids exposing the camera to the internet at all.