Good thing my Jellyfin is behind Wireguard.
Consider doing the same if your usecase permits.
please tell me it doesn’t expose itself onto public web by default
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.
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.
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.
Young.
The original ticket is 2019. That’s 7 years ago.
Technically there’s no real problem here.
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…
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.
deleted by creator
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.
Yes, not everyone. My grandmother would struggle setting up a VPN, for example.
that’s a weird take. your grandmother doesn’t need to set up a VPN. It’s not like this is where they would get stuck, they would have problems much sooner with running their own Jellyfin. that’s why you are hosting it for them, and why you go there and set the VPN up yourself.
I was not actually presenting a scenario where my grandmother would use a VPN.
I was pointing out that this community is full of people who are perfectly capable of learning to use a VPN. In response to this comment:
Unfortunately, not everyone is tech-literate enough nowadays to understand how a VPN works, nor do they want to
That’s a true statement about ‘everyone’ i.e. the entire population of the planet… but true about everyone here in this community.
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.
yeah but even with plain wireguard the peers can be limited. you just have to figure out the firewall rules, or use opnsense as your wireguard server because it figures the harder part out for you.
it’s not that it cannot be done. the issue is that something as simple as acceding a service should not require to configure wire guard and routing rules. plenty of FOSS projects are safe to expose through a simple reverse proxy
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
I know way too many people who won’t remember to toggle it on, or just won’t deal with it
they need a VPN app that toggles automatically. turn off when they happen to connect to your network, otherwise on, and only forward jellyfin and such apps through it.
I know way too many people who won’t remember to toggle it on, or just won’t deal with it
they need a VPN app that toggles automatically. turn off when they happen to connect to your network, otherwise on, and only forward jellyfin and such apps through it.
They’ve stated that they have no intention of ever fixing some of the biggest “anyone can access your media without a login” vulnerabilities, because it would require completely divesting from the Kodi branch that they initially used to start the entire project. And they never plan on rebuilding that from scratch, so those vulnerabilities will never be fixed.
They didn’t start the project from Kodi. It is a fork of Emby.
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
The design of Jellyfin is really insecure
It isn’t a supply chain attack. If it was they would’ve disclosed it mmediately instead of waiting.
Yeah, i have my 30 docker containers behind Headscale (Tailscale).
NetBird is coming for you
I have been planning to check out Netbird for couple of days. Is it a good alternative for headscale and pangolin?
It depends if you’re using Pangolin for private access or public exposure.
NetBird is a clean replacement for headscale/tailscale, but if your using pangolin specifically for its public tunnel feature then you’d need to keep pangolin.
Mainly use pangolin for public access, I’m looking for something/somehow add authentication for pangolin while trying to access endpoint in apps where it’s not exactly possible to directly authenticate in pangolin
If only they would fix the htaccess bug
You’ve piqued my interest. Where can I read about it?
I did a quick search on their github and came up empty. Maybe no one mentioned “htaccess” in the issue.
Search for “basic auth”
Its the only software project I know of that you can’t put behind http basic auth. They mark this bug as “wontfix” every time someone points it out to them
Utilize authelia perhaps?
Doesn’t work with TVs
ldap auth will work on tvs
But that’s basically using the same built-in auth. If there’s an auth bypass I don’t think it makes a difference.
not really. you can disable the default jellyfin login and force it to use ONLY ldap.
…which still uses Jellyfin for authentication. The only difference is that instead of checking your password locally it is sent over the network via LDAP
Don’t ever shit in your own house, either.
Just in case they’re watching.
I shit in my toilet
or use the ldap auth plugin with your source of truth, put it behind a reverse proxy, protect it with fail2ban and anubis. there are ways of exposing it safely.
I still wouldn’t do it personally
deleted by creator
you totally can use ldap or oidc it just requires more setup. you just ensure jellyfin and your source of truth talk on their own subnet, docker can manage it all for you. ldap can be setup to be ldaps with ssl and never even leave the docker subnet anyways.
and yes I suppose you could rely on whitelists, but you’d have to manually add to the whitelist for every user, and god forbid if someone is traveling.
that’s nonsense. I do it myself and it works flawlessly, including on TVs.
So don’t use it outside your house? Pass
Nothing stops you from using it outside of your house.
I just love it when people post one sentence rebuttals without actually including any usable information what they are talking about.
The solution is mentioned already - use vpn, it will solve 90% of the problems that you can encounter. Also you can serve multiple other services this way without exposing them.
Tailscale is a super easy vpn that gives you access to your home network from anywhere. And it’s free.
the usable information is information that’s so widely talked about in this community that they probably expected anyone who is reading this to know what they’re talking about.
clearly there are still people who have no experience self-hosting whatsoever that we should be considerate of.
It kind of does. Whatever and yes I’m aware of the list people keep posting and I’ve looked at it.
Thank you for posting this. I tend to get a lot of my opensource project info from Lemmy so people who take the time to post it are awesome.
Just updated my home instance. Can confirm that 10.11.7 is available in the Debian repos and the update went perfect. I got a new kernel in the same update : D
I forgot that it’s April first, and was wondering what catasthropic event had happend in order that it had to be stated in the title that its not a joke
Wonder if it’s the Axios one. Sounds like it isn’t from their description though hmm
I don’t think so, the previous release 10.11.6 is a few months old and the axios supply chain attack happened yesterday.
So lets hope this 10.11.7 is not subject to the axios one. :)
Diff agrees, not likely. Might be permisson related, elevation of privileges.
From a cursory look at just the security commits. Looks like the following:
- GHSA-j2hf-x4q5-47j3: Checks if a media shortcut is empty, and checks if it is remote and stores the remote protocol if so. Also prevent strm files (these are meant to contain links to a stream) from referencing local files. Indeed this might have been used to reference files jellyfin couldn’t usually see?
- GHSA-8fw7-f233-ffr8: Seems to be similar, except for M3U file link validation and limiting allowed protocols. It also changes the default permissions for live TV management to false.
- GHSA-v2jv-54xj-h76w: When creating a structure there should be a limit of 200 characters for a string which was not enforced.
- GHSA-jh22-fw8w-2v9x: Not really completely sure here. They change regex to regexstr in a lot of places and it looks like some extra validation around choosing transcoding settings.
I’m not really sure how serious any of these are, or how they could be exploited however. Well aside from the local file in stream files one.
Yeah, the key seems to be in the comments from one of the changes: https://github.com/jellyfin/jellyfin/commit/0581cd661021752e5063e338c718f211c8929310#diff-bcc2125e56d5738b4778802ac650ca47719845aeee582f3b5c9b46af82ea9979R1176-R1180
It seems there was the potential risk that insufficient validation could allow reading arbitrary server files, which indeed poses a security risk.
However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that’s a risk to ignore, but it’s not like it could be exploited by anyone on the Internet.
However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that’s a risk to ignore, but it’s not like it could be exploited by anyone on the Internet.
I wonder if that’s the reason for setting the default live TV management permission to false. Since that permission might well the the route to adding your own malicious m3u link for that second change.
deleted by creator
Axios is a Javascript library and Jellyfin is written in C#.
True, but there is a web frontend. Possible it could be using npm and axios somewhere in there.
I still doubt it. But it could happen.
The web server is in C#. It’s open source lol, I’m looking at the code and there’s no JavaScript.
Look better https://github.com/jellyfin/jellyfin-web
That’s awkward. I didn’t know that was in a separate repo.
There is a good reason I only have Jellyfin and other services accessible via valid Client Certificate.
Does it work with android and TV apps?
I tried long ago and failed.
No, we only use Jellyfin via browser. Unfortunately even with imported Client Cert, Android apps won’t work.
Edit: Client Certs need to be implemented per App. There is a feature request from 2022 https://features.jellyfin.org/posts/1461/capability-to-specify-client-certificate-for-android-client
Also interested how this works for mobile apps. I self host a number of services through caddy as my reverse proxy but each application is just dependent on it’s own authentication. If I exposed all my services to the internet, that’s a huge attack vector. If anyone else has some ideas I’d be happy to listen.
If you are the only user and don’t need to use those apps in devices you don’t own a vpn is the way to go.
If not. Depending the number of users you could do some heavy ip geoblocking to at least reduce the exposed surface.
There are a few services I have just like 3 IPs allowed to get a response from caddy, any other ip gets 403 error.
Pretty flawless update from the apt repo on my end.
Server version 10.11.7Yeah, I think what went wrong and now everything is installed through Docker.
Docker feels like a huge security problem to me.
Why?
Docker makes everything so much easier
I know, but your security then depends on the package maintainer to keep the image up to date
Am officially maintained Docker image is no less a security concern than an officially maintained apt repo. Depending on how you set up a container stack it can even be more secure. An attacker gaining root access to a container that you’ve given extremely selective access to the host machine is far better than them gaining root access to your actual system.
Is it standard practice to release the security updates on GitHub?
I am a very amateur self hoster and wouldn’t go on the github of projects on my own unless I wanted to read the “read me” for install instructions. I am realizing that I got aware I needed to update my Jellyfin container ASAP only thanks to this post. I would have never checked the GitHub.
The Jellyfin has an official Telegram channel which I use as the newsletter.
Besides that, the selfh.st newsletter usually highlights the more popular projects if such an issue arises.Is it standard practice to release the security updates on GitHub?
Yes.
And then the maintainers of the package on the package repository you use will release the patch there. Completely standard operation.
I recommend younto read up on package repositories on Linux and package maintainers etc.
Not really.
Depending on how you install things, the package maintainers usually deal with this, so your next
apt update/pacman -Syuvor … whatever Fedora does… would capture it.If you’ve installed this as a container… dunno… whatever the container update process is (I don’t use them)
I indeed use a container. Wasn’t familiar with the update process for containers but now know how to do it.
There’s a lot of good container management solutions out there that are worth investigating. They do things like monitor availability, resource management, as well as altering on versioning.
Can highly recommend dockhand happily runs my full docker stack with updates and great overviews of what’s happening under the hood.
If you haven’t already, I recommend Watchtower (nickfedor fork—the original is unmaintained) which automatically pulls updates to Docker containers and restarts them. Make sure to track latest, although for security updates, these should be backported to any supported versions so it’s fine to track an older supported version too.
Thank you. Will look into it.
Lol it’s already insecure then. Don’t bother.
Implying you have access to some major Docker 0-day exploit, or just talking out of your ass? Because a container is no more or less secure than the machine it runs on. At least if a container gets compromised, it only has access to the volumes you have specifically given it access to. It can’t just run rampant on your entire system, because you haven’t (or at least shouldn’t have) given it access to your entire system.
Docker is known insecure. It doesn’t verify any layers it pulls cryptography. The devs are aware. The tickets remain open.
I don’t know if I remember correctly but I could not install Jellyfin on the latest Ubuntu server version. I had to use docker to get Jellyfin running.
Jellyfin has a Debian repo. Worked fine on Debian 12 and 13.
If that is indeed true it would only mean that the docker container is vulnerable to a supply chain attack. You are not any more vulnerable to a vulnerability in the codebase.
If you’re using the ghcr image, to post malicious code there, the attack would have already had to compromise their github infra … which would likely result in the attacker being able to push malicious code to git or publish malicious releases. Their linux distro packages are self published via a ppa/install script, which I would assume just pull from their github releases, so a bad github release would immediately be pulled as an update by users just as fast as a container.
No, it’s also vulnerable to a targeted mitm attack. Github can be unaffected and you can get a malicious version on your server.
Insane way of thinking.
Unattended upgrades set to security only and never worry
It’s difficult to do security-only updates when the fix is contained within a package update.
Even Microsoft’s security updates are a mix with secuirity updates containing feature changes and vice versa.
I usually do an update on 1 random device / VM and if that was ok (inc. watching for any
.pacnewfiles) and then kick Ansible into action for the rest.Why does unattended upgrades with security only setting not fix this?
This is literally why Debian has distinct repos for security updates.
Let me know which repo this update appears in.
The jellyfin repo
I am realizing that I got aware
I don’t run the arr stack, but this is key. You really should do your due diligence before you update anything. Personally, I wait unless it’s a security issue, and use all the early adopters as beta testers.
Wait a minute, best security practice is to use the latest version -1?
You can always tell who does real IT work in these threads lol
In the raspian repos, just updated, thanks.
also in the docker repository.
Thanks for this post, i would have updated mine next semester…
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency Plex Brand of media server package RPi Raspberry Pi brand of SBC SBC Single-Board Computer SMB Server Message Block protocol for file and printer sharing; Windows-native SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) nginx Popular HTTP server
12 acronyms in this thread; the most compressed thread commented on today has 5 acronyms.
[Thread #203 for this comm, first seen 1st Apr 2026, 09:50] [FAQ] [Full list] [Contact] [Source code]
Im on fedora and I have installed through dnf, no updates with the dnf update… should I wait?
I depends a bit on your threat model. If you have Jellyfin exposed to the internet I would shut it down immediately. If you are running locally and rely on it, let it run maybe? If behind a tailnet or some other VPN, I would deactivate it as well. If it is an Axios like vulnerability it may be possible your secrets are in danger, dependent on how well they are secured. Not a security expert, but I would handle this a little more conservative…
No need to shut it down if it’s not exposed to the internet. Tailnet/VPN is fine.
If it’s a supply chain compromise shutting it down wouldn’t matter. The damage is already done.
I don’t believe it a supply chain compromise
Same. I was pointing out that if it was related to Axios then it’s already too late.
It’s on my home, which is not 24/7 open. Will see check later.
The update rolled out perfectly for my Kubernetes setup (using the Docker image). 👍
