690
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Apr 2026
690 points (99.1% liked)
Selfhosted
58128 readers
804 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Don't expose jellyfin to the internet is a golden rule.
Just did a cursory read of the commits related to security for this release, and my assumpion based solely on the changes, is that it's not a remote-access vulnerability, but a supply-chain-esque vulnerability where a video you downloaded from a questionable source might trigger code embedded in the metadata to be run by jellyfin.
Kinda defeats the purpose of a media server built to be used by multiple people
Use a VPN, it's not ideal but it's secure.
Somehow difficult to install on a TV though.
That’s why you do it at your router or gateway and then set a route for the Jellyfin server through the VPN adapter. That way any device on your network will flow through the tunnel to the Jellyfin server including TVs
Which again implies that you have a router that allows you to do so. It's not always the case. For tech enthusiast people that's the case. But not for everyone.
I tried to do the same thing at first, but it was a pain, there were tons of issues.
Oh yes, the routers and gateways that most people have that are isp provided that may not actually have open VPN or wireguard support.
Those ones?
Also putting a VPN in someone else's house so that all their Network traffic goes through your gateway is pretty damn extreme.
No need to expose jellyfin to the internet if you selectively allow peers on your lan via wireguard.
This attitude is why Plex remains popular.
Easy for me but not my aunts, cousins or father in law to setup and use.
Nor will the VPN work on things like their TV or Roku or game console. You know the things that people typically sit down and watch media on....
I'd rather just not use it at that point
Fair, you do you, I get a lot of value out of it instead.
The difference is that my friends get a lot of value out of my server, as they don't need to use any technology they're unfamiliar with.
Which doesn't work for The grand majority of devices that would be used to watch said media.
Tvs game consoles rokus so on so forth typically don't support VPN clients.
The Jonathan clients for these devices also typically don't support alternative authentication methods which would allow you to put jellyfin behind a proxy and have the proxy exposed to the internet. Gating all access to jellyfin apis behind a primary authentication layer thus mitigating effectively all security vulnerabilities that are currently open.
That’s never made sense to me; why build an authn frontend instead of just clicking your user if the security is just an illusion anyways. “Use a VPN” is fine for a mainframe, but an active project in 2026 should aspire to be better.
Edit: or make note of that on their several pages with reverse proxy configuration.
Examples dating back over six years https://github.com/jellyfin/jellyfin/issues/5415
I mean I'm sure they'd like to just ship safe code in the first place. But if that's not their expertise and they demonstrate that repeatedly, we gotta take steps ourselves. Secure is obviously best, but I'd rather have insecure Jellyfin behind a VPN than no Jellyfin at all.
there is just too much place in the codebase for vulnerabilities, and also, most projects like this are maintained by volunteers in their free time for free.
I guess if you set up an IP whitelist in the reverse proxy, or a client TLS certificate requirement, it's fine to open it to the internet, but otherwise no.
It's not this or that. Security comes in layers. So while I would assume that the Jellyfin developers do their best to secure their application, I acknowledge the fact that bugs do exist and that Jellyfin is developed in and for hobbyist contexts, and thus not scrutinised and pentested for vulnerabilities in the way software meant for professional environments would be. Therefore I'll add an extra layer of security by putting it behind a VPN that only whitelisted clients can access. If a vulnerability is detected, I can be sure it hasn't already been exploited to compromise my server because we're all "among friends" there.
If I say I custom rolled my own crypto and it's designed to be deployed to the open web, and you inspect it and don't see anything wrong, should you do it?
Jellyfin is young and still in heavy development. As time goes on, more eyes have seen it, and it's been battle hardened, the security naturally gets stronger and the risk lower. I don't agree that no one should ever host a public jellyfin server for all time, but for right now, it should be clear that you're assuming obvious risk.
Technically there's no real problem here. Just like with any vulnerability in any service that's exposed in some way, as long as you update right now you're (probably) fine. I just don't want staying on top of it to be a full time job, so I limit my attack surface by using a VPN.
The original ticket is 2019. That’s 7 years ago.
It responds to and serves content to unauthenticated requests. That’s sorta table stakes if you’re creating an authenticated web service and providing guides to set it up with a reverse proxy.
Ok, I misread what you were linking to. Yeah, that's pretty bad to allow actual streaming of content to unauthed users. I agree they should not be encouraging anyone to set this up to be publicly accessible until those are fixed. Or at least add a warning.
I don't care if someone finds my instance and manages to guess a random number to stream some random movie. Good for them I guess it would be easier to just download it themselves.
Biggest worry is someone finding an uncaught RCE.
Of course plugins also have surface area.
We know they can anon pull video. You can sandbox it to limit exposure.
But if they modify the web client with an RCE, then you hit your own server as a trusted site and that delivers a payload...
If only they would fix the htaccess bug
Y'all are assuming the security issue is something exploitable without authentication or has something to do with auth.
But it it could be a supply chain issue which a VPN won't protect you from.
to be fair, Jellyfin had multiple unauthenticated vulnerabilities in the past so it makes sense to talk about it
Yeah, i have my 30 docker containers behind Headscale (Tailscale).