- cross-posted to:
- jellyfin@lemmy.ml
- jellyfin@lemmy.ml
- cross-posted to:
- jellyfin@lemmy.ml
- jellyfin@lemmy.ml
You must log in or # to comment.
Don’t expose jellyfin to the internet is a golden rule.
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
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
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
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
Basic auth? The insecure authentication method?
Ok, I’ll look it up anyway. Under the jellyfin repository, there were eight results, none of which seemed to describe what you meant, and under the jellyfin-web repository, there were none. Using a web crawler search, I was able to find Issue #123 for jellyfin-android
Is that it?
Basic auth is very secure.
Unlike custom implemented logins. So it’s common to use basic auth in front of custom auth implementations. So even when the app has a login vuln, you’re safe.
Yes that ticket is one of many.
Try searching the repo. Make sure to backspace out the prefix that ignores closed tickets.
That’s exactly how I searched. If you want security, it’s probably best to follow the Unix philosophy of do one thing and do it well. In other words, don’t trust someone building a media server to handle auth and instead use the OIDC or LDAP plugins.
Don’t ever shit in your own house, either.
Just in case they’re watching.
I shit in my toilet
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.
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.
11·20 days agothat’s nonsense. I do it myself and it works flawlessly, including on TVs.
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.
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.
deleted by creator
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.
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.
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?
There is a good reason I only have Jellyfin and other services accessible via valid Client Certificate.
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.
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.
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.
Good thing my Jellyfin is behind Wireguard.
Consider doing the same if your usecase permits.
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 17 acronyms.
[Thread #203 for this comm, first seen 1st Apr 2026, 09:50] [FAQ] [Full list] [Contact] [Source code]
Thanks for this post, i would have updated mine next semester…
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). 👍
Just updated, thanks for the info <3
