The case against port-forwarding Plex, Jellyfin, and Home Assistant

A port-forward feels like a small, contained change. The router exposes one TCP port to one internal service. Everything else stays private. Three intuitions reinforce the feeling of safety and all three are wrong in 2025-2026.

1. “NAT is a firewall.”

Home routers do network address translation by default, which has the side-effect of dropping unsolicited inbound connections. People treat that side-effect as protection. The moment a port-forward is added the protection is gone for that port — the NAT was never doing the work that “firewall” implies. It was a side-effect of address scarcity, not a security boundary. Once a service is exposed, the only thing standing between it and the internet is the service's own login screen.

2. “A non-standard port is hidden.”

Moving Plex from 32400 to 38221 or Home Assistant from 8123 to 18123 buys nothing. Internet-wide scanners fingerprint services by their response, not by port number. The Sophos test confirmed this directly — RDP exposed on a non-default port still drew brute-force attempts in under a minute.¹ Shodan and Censys catalogue services on every TCP port; an attacker searches by application fingerprint and gets a list of every Plex / Jellyfin / Home Assistant instance worldwide regardless of what port each one chose.

3. “Nobody would target a home.”

Nobody targets a specific home. Targeting was the model two decades ago. The modern model is untargeted: automated scripts continuously sweep the IPv4 space looking for known services with known default credentials or known CVEs, and a residential IP is just another row in the queue. The hit rate per scanned host is low; the absolute number of hosts being scanned per second is very high. A Plex server with a five-character password gets found the same week every other Plex server with a five-character password gets found.

None of those intuitions held up under measurement. The published data — Sophos honeypot, Censys advisory, Shadowserver scans — converges on the same point: anything reachable from the public internet has the public internet's threat model, not a home network's threat model.

Plex is the most-port-forwarded media server in the residential population. Its default port is 32400/TCP, and many setup guides — including older versions of Plex's own — walked users through forwarding it explicitly. The cleaner answer has been available for years and is documented under the name Remote Accessin the Plex support library. With Remote Access enabled, the Plex Media Server reaches out to Plex's infrastructure and authenticates against the user's Plex account; the Plex apps reach the same infrastructure from the client side; the two sides find each other through Plex's relay without any inbound port on the home router.

The “Plex already has a login screen” rebuttal does not hold up under the NVD record. The public CVE list for Plex Media Server includes:

• CVE-2020-5742 (CVSS 8.8) — Improper Access Control. Allows any web origin to execute cross-origin requests against a running Plex Media Server.⁴
• CVE-2020-5740 (CVSS 7.8) — Improper input validation on Plex Media Server for Windows allowed a local unauthenticated attacker to execute arbitrary Python code with SYSTEM privileges. Local, not remote — but the relevant question is what happens after the first foothold lands.⁴
• CVE-2019-19141 (CVSS 8.8) — A remote authenticated user could write files anywhere the Plex service account had access through the Camera Upload feature.⁴
• CVE-2018-13415 — XXE on the SSDP/UPnP XML parser in Plex Media Server 1.13.2.5154 allowed remote unauthenticated attackers to read files from the server.⁴

None of those is the worst CVE ever published. The point isn't that Plex is uniquely dangerous — the point is that any non-trivial application accumulates advisories over years, and a port-forwarded instance is one unpatched release away from being the entry vector for the rest of the LAN. The Plex-cloud relay ends that exposure class without removing remote access for the user.

Jellyfin is the fork of Emby that removed the cloud dependency. That decision is part of why people choose it — there is no third-party account, no telemetry, no vendor-hosted service. The same decision means there is no built-in remote-access relay either. Whatever gets you to the server from outside the home is your problem to design.

Jellyfin's own networking documentation states this explicitly. The Post-Install Networking page distinguishes between “opening a port” and forwarding a port through NAT, and cautions in plain language that “Opening a port directly to the Internet is therefore insecure and not recommended.” The same page recommends handling HTTPS termination through a reverse proxy rather than directly on Jellyfin, with a dedicated implementation guide linked.⁵

The NVD record for Jellyfin from 2022 forward includes several entries worth knowing about if a Jellyfin instance is reachable from the public internet:

• CVE-2022-35909 (CVSS 8.8) — The /users endpoint had incorrect access control for admin functionality in versions before 10.8.⁶
• CVE-2023-30626 (CVSS 8.8) — A directory traversal vulnerability inside the ClientLogController affected releases from 10.8.0 through 10.8.10.⁶
• CVE-2023-49096 (CVSS 7.7) — An argument-injection vulnerability in the VideosController.⁶
• CVE-2023-27161 (CVSS 7.5) — A server-side request forgery through the Repositories component in versions up to 10.7.7.⁶

The honest read of that record: Jellyfin is an ordinary application with an ordinary advisory history, and the project itself does not recommend exposing it to the public internet. A reverse proxy with an authentication front-end is the documented remediation for users who want public reachability anyway; everything else in this article is the better alternative for users who don't.

Home Assistant is, by design, the highest-blast-radius of the three. A Plex compromise loses media metadata and lateral-movement potential. A Home Assistant compromise loses control of door locks, garage doors, cameras, alarm states, lighting, and whatever else the household has integrated. The NVD entry that defines the threat model is CVE-2023-27482— a CVSS 10.0 remotely exploitable authentication bypass on the Supervisor API. From the NVD description: “A remotely exploitable vulnerability bypassing authentication for accessing the Supervisor API through Home Assistant has been discovered.”⁷ The relevant detail is the severity: 10.0. That is the ceiling of the CVSS scale.

Home Assistant's own securing page lists Home Assistant Cloud (Nabu Casa Remote UI) as “the easiest option”for remote access and supports the Open Home Foundation through that subscription. It then names alternatives — TLS via Duck DNS with Let's Encrypt, a VPN (specifically mentions PiVPN), an SSH tunnel — and names port-forwarding as a separate option that requires you to “Make sure to expose the used port in your router.”⁸ The page does not endorse port-forwarding. It catalogues it.

For most homeowners the Nabu Casa subscription is the right answer: outbound-only, vendor-maintained, no router configuration, and the money funds the project. The other paths require more work and more ongoing maintenance. None of them involves an inbound port-forward to 8123.

There are four paths that replace a port-forward with a private, authenticated way back into the house. None of them is free. Each one trades a different thing.

A. VPN home (UniFi WireGuard, Teleport, OpenVPN)

The most security-conservative option. The gateway runs a VPN server; clients run a VPN app; before any self-hosted service is reachable, the device has to be on the home tunnel. UniFi gateways implement WireGuard natively as a built-in VPN server, and the Teleport feature on UniFi gateways offers a zero-configuration variant aimed at remote-access use⁹ —“Teleport is a zero-configuration VPN that allows you to instantly connect to your UniFi network from a remote location.”

Trade-off.VPN-on every time, on every device. A phone that has the VPN configured but not currently connected does not get Plex notifications or Home Assistant alerts. Some clients (a smart TV, a streaming stick) cannot run a VPN client at all. Older UniFi gateways have a published UDP-throughput ceiling that limits VPN speed; on a multi-gig WAN the tunnel will not run at line rate. For most households the friction is acceptable; for households with dependents who need always-on Home Assistant access, it is not.

B. Overlay network (Tailscale, Twingate, ZeroTier)

Conceptually a VPN, architecturally something different. Tailscale describes itself as building a “peer-to-peer mesh network (known as a tailnet)” on top of WireGuard, where“each device is connected to the other directly, resulting in lower latency.”¹⁰ Every device — server, phone, laptop — runs the Tailscale client, signs in with an identity provider, and finds peers without any inbound port on the gateway. Tailscale Funnel additionally allows narrow, authenticated public exposure of selected services if that is genuinely required.

Trade-off.A third party (Tailscale, Twingate, ZeroTier) brokers identity. If their control plane is breached or their auth flow is compromised, the overlay's security model is degraded. The data path is end-to-end encrypted between peers, but trust is centralized through the vendor's identity infrastructure. For most households this is an acceptable trust transfer — the vendor is a known quantity and the alternative is to manage WireGuard keys by hand — but it is a transfer of trust, not the absence of one.

C. Cloudflare Tunnel

Cloudflare Tunnel inverts the connection model. The cloudflared daemon runs on a machine inside the home, opens an outbound-only connection to Cloudflare's edge, and registers itself as the origin for one or more public hostnames. The gateway has no inbound port-forward. From the Cloudflare docs: “A lightweight daemon in your infrastructure (cloudflared) creates outbound-only connections to Cloudflare's global network.”¹¹ Combined with Cloudflare Access (zero-trust policies in front of each hostname) the service ends up public in DNS but reachable only by authorized identities.

Trade-off. All traffic for that hostname is routed through Cloudflare. For homeowners that means a third-party network sees the metadata of every Plex stream, every Home Assistant API call, every Jellyfin login. The data itself is TLS-encrypted inside the tunnel; the connection metadata is not private from Cloudflare. For households where that trade-off is unacceptable, this option is wrong. For households where it is acceptable, it is the lowest-friction option of the four.

D. Reverse proxy with an authentication front-end

The keep-it-public option. A reverse proxy (Caddy, nginx, Traefik) terminates TLS for one or more self-hosted services and an authentication portal — Authentik or Authelia — sits in front of every protected URL. Authentik describes itself as a “self-hosted, open source identity provider”¹²; Authelia describes itself as “an open-source authentication and authorization server and portal fulfilling the identity and access management (IAM) role,” with multi-factor authentication built in.¹³ The protected service never sees an unauthenticated request.

Trade-off. The service itself is still publicly reachable on the wire — the port-forward is still there, the TCP handshake still completes, the auth portal is still on the public internet. The auth front-end is now the single point of failure for the entire stack, and the homeowner is responsible for keeping it patched. This option is appropriate when remote access genuinely needs to be public (a service shared with people who cannot install a VPN or sign into Tailscale) and the operator is willing to take on the maintenance burden of a proper identity provider. Otherwise A, B, or C is easier and less risky.

Once one of the four alternatives is in place and verified end-to-end from an external network, the actual removal of the port-forward in UniFi is short. The path is the same on every modern UniFi controller version:

1. Open the UniFi Network application. Navigate toSettings → Routing & Firewall → Port Forwarding.
2. Find the rule (or rules) pointing at the self-hosted service. Disable it first — do not delete it immediately. Save.
3. Verify that remote access still works through the chosen alternative path. Test from cellular data, not just from a friend's Wi-Fi: some carriers CGNAT-translate in ways that hide certain failure modes.
4. Once the alternative is confirmed working for at least 24 hours, delete the disabled rule entirely.
5. Audit the rest of the port-forwarding table. The one rule that brought a homeowner here is rarely the only one. Old rules for an SSH session that was set up for a one-time troubleshoot, a NAS web UI that nobody uses anymore, a Minecraft server from a child who has since moved out — all of these are worth deleting.

The after-checklist is the same regardless of the alternative chosen:

• The self-hosted service is patched to its current stable release. The CVE history above is not theoretical.
• Default credentials are not in use anywhere on the LAN. Plex requires a Plex account, but a Jellyfin admin can be created with whatever username and password the operator types — including admin / admin, which is the modal Sophos honeypot finding.¹
• Multi-factor authentication is enabled on every cloud account that brokers identity for the chosen alternative — UniFi SSO, Tailscale, Cloudflare, Nabu Casa.
• The IoT VLAN is separated from the trusted LAN, so that even if a future compromise lands on a smart plug or a camera, lateral movement to the laptops and NAS is firewalled.

• Some services genuinely have to be public. A static blog, a public Mastodon instance, a Matrix homeserver shared with friends — these need a reverse-proxy-with-auth path rather than VPN or Tailscale, because the audience cannot reasonably be expected to install a client. The trade-off analysis for those services is different from the trade-off analysis for Plex.
• VPN throughput on older UniFi gateways is real.A UDM-Pro or older Cloud Gateway can saturate WireGuard at speeds well below a multi-gig WAN. The decision between “VPN home” and “overlay network” is partly a hardware decision. On older hardware Tailscale's peer-to-peer path usually outperforms a homed VPN because most of the traffic never traverses the gateway's VPN process.
• Cloudflare Tunnel is not free of trust transfer.Cloudflare sees connection metadata. For most households the trade-off is acceptable; for people who actively don't want a third party to see when they're streaming or controlling their home, it isn't. There is no free option in this article — only different ones.
• Tailscale needs an account on every client.Each device that connects must run the Tailscale client and authenticate. A guest, a visiting family member, or a one-off contractor cannot reach the service unless they are added to the tailnet. That is a feature when the threat model is “limit who can reach Home Assistant.” It is friction when the use case is “share a Plex library with a relative.”
• A reverse proxy with auth is not magic. Authentik and Authelia are real, well-maintained projects, but they are also software, and they too accumulate advisories over time. The operational burden of running an identity provider for a household network is non-trivial. Most homeowners are better served by VPN, overlay, or vendor cloud relay than by self-hosted SSO.
• Removing a port-forward does not patch the service.If a self-hosted service ran unpatched and exposed for months, it should be treated as possibly already compromised. The homeowner's after-action is not just to close the port — it is to rotate credentials, check the service's audit log, and consider a clean reinstall. That is the part the Reddit thread cited in § 01 ultimately ended with.²

None of these caveats changes the headline. Across the public r/Ubiquiti record, the published Sophos honeypot data, the Censys exposure scans, and the NVD advisory history for Plex, Jellyfin, and Home Assistant, the most common residential UniFi compromise vector in 2024-2026 is a self-hosted service exposed through a port-forward — not the UniFi gateway itself.