🚀 Jellyfin Server 10.11.7
We are pleased to announce the latest stable release of Jellyfin, version 10.11.7! This minor release brings several bugfixes to improve your Jellyfin experience. As alway...
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.
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.
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.
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.
Agreed, was more so referring to others. I apologize if it seemed like I was referring to myself
I’m already well and truly deep into this, myself. Two Proxmox nodes running the *Arr stack and Jellyfin in LXC containers. Bare metal TrueNAS, with scheduled LTO backups every two weeks. A few other bits and bobs, like some game servers and home automation for family.
Will need to re-map everything eventually, it’s kind of grown out of hand
You only have to give them access to a specific port on a specific machine, not your entire LAN.
My VPN has a ‘media’ usergroup who can only access the, read-only, NFS exports of my media library.
If you’re just installing Wireguard and enabling IP forwarding, yeah it would not be secure. But using a mesh VPN, like Tailscale/Headscale, gives you A LOT more tools to control access.
Oh absolutely, difference being that you only need to expose the service once, versus helping however many people set up VPNs to access the service on your LAN
I know way too many people who won’t remember to toggle it on, or just won’t deal with it
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.
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
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.
deleted by creator
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.
Unfortunately, not everyone is tech-literate enough nowadays to understand how a VPN works, nor do they want to
Yes, not everyone. My grandmother would struggle setting up a VPN, for example.
However, a community member of the selfhosted community is perfectly capable of reading a manual and learning the software.
That’s how you become tech literate in the first place, and you’re already on that path if you’re commenting/reading here.
Agreed, was more so referring to others. I apologize if it seemed like I was referring to myself
I’m already well and truly deep into this, myself. Two Proxmox nodes running the *Arr stack and Jellyfin in LXC containers. Bare metal TrueNAS, with scheduled LTO backups every two weeks. A few other bits and bobs, like some game servers and home automation for family.
Will need to re-map everything eventually, it’s kind of grown out of hand
Look at Tailscale (or self-host headscale)
It’s a bit of learning (like all of these other things) but it’s a very powerful tool.
I do agree with the general point that Jellyfin shouldn’t require a VPN.
Isn’t it easier to set up a VPN than expose it to the internet?
and then you are giving access to your lan to people whose computer you don’t control and might be full of malware.
Tbh I forgot about giving access to others, my homelab is for me only lol
You only have to give them access to a specific port on a specific machine, not your entire LAN.
My VPN has a ‘media’ usergroup who can only access the, read-only, NFS exports of my media library.
If you’re just installing Wireguard and enabling IP forwarding, yeah it would not be secure. But using a mesh VPN, like Tailscale/Headscale, gives you A LOT more tools to control access.
Oh absolutely, difference being that you only need to expose the service once, versus helping however many people set up VPNs to access the service on your LAN
I know way too many people who won’t remember to toggle it on, or just won’t deal with it
It’s just not convenient enough
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.