- 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.
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
Hi!
So I installed jellyfin on Bazzite as per this video.
But he didn’t explain how to update the server. Could you maybe tell me how you did it with your server? Maybe it could help me figure out how to update mine as well.
The video uses quadlets, which afaik, is just using systemd units to run containers via podman. Therefore, you can just run
podman stop jellyfin (podman ps to get the actual name of the jellyfin container)
podman rm jellyfin
podman pull docker.io/jellyfin/jellyfin:latest
systemctl restart jellyfin.container (or whatever you called your unit when you set it up)
Quick google says you can setup auto updates if you want: https://major.io/p/podman-quadlet-automatic-updates/
Caveat: I am a docker compose user, I may have missed something due to lack of familiarity with quadlets/podman
You’re correct.
The only time I can think of that this approach wouldn’t work is if the quadlet config file specified a tag/version on the
imagesetting besideslatest. That is, if the quadlet file specified something likeImage=docker.io/jellyfin/jellyfin:a_old_version. I usually stick withlateston mine.EG:
Image=docker.io/jellyfin/jellyfin:latestIt worked! Thanks so much!
I suppose I’ll start looking into docker/containers/quadlets etc, so I actually understand what I am using lol
Poke around through the dash. I imagine it’s in the GUI there. Probably under a menu like ‘system’ or ‘about’.
Thanks for the reply!
Sadly I can’t find anything, unless I am super blind.
Ahh bummer. Not sure exactly then. Might have to hop in the terminal and try an
--updateor find an equivalent with--help. The documentation in the git repo should tell you if nothing else.podman stop jellyfin (podman ps to get the actual name of the jellyfin container)
podman rm jellyfin
podman pull docker.io/jellyfin/jellyfin:latest
systemctl restart jellyfin.container (or whatever you called your unit when you set it up)
This suggestion from another commenter worked! Apparently quadlets work with Podman in the background.
Ahh baller man. Glad you got it sorted! And thanks for sharing the fix
You can always tell who does real IT work in these threads lol
Don’t expose jellyfin to the internet is a golden rule.
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.
Don’t reverse proxies like pangolin just do the job? Does it have to be VPN in this particular concept? VPN isn’t like immune to vulnerabilities.
Reverse proxy doesn’t really get you much security. If there is an application level issue a reverse proxy will not help
Hmmm, I’m a bit rusty on this but can’t one put an auth gate in front of the application, handled by the reverse proxy?
deleted by creator
I’d rather just not use it at that point
you are better just closing up shop then, because it’s not like the other services you are hosting are much better. vulnerabilities being discovered don’t mean they don’t exist, it just means the software is not popular enough or too complex for someone to look into it
lol the whole internet better shut down right? Too vulnerable
much of the internet is run on simpler software or by full time employees tasked to deal with all this. but sure, ignorance is bliss, what you don’t see does not exist, etc etc, keep running your Jellyfin exposed to the internet. you wouldnt even get to know when your system is compromised. but you know what? you could even remove your password for extra convenience. who would want to log in to a random jellyfin account anyway! surely no one! just don’t recommend these practices to anyone, because you are putting them at risk.
I mean I do this stuff for a living but okay go off king
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.
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.
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.
Unfortunately, not everyone is tech-literate enough nowadays to understand how a VPN works, nor do they want to
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.
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
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
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.
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]
Wonder if it’s the Axios one. Sounds like it isn’t from their description though hmm
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.
please tell me it doesn’t expose itself onto public web by default
Good thing my Jellyfin is behind Wireguard.
Consider doing the same if your usecase permits.
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.
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.
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.
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.
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.
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
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.
Just a reminder that you should never expose Jellyfin to the internet
The worst part of enthusiast threads are the “I am very smart” takes like this
You objectively shouldn’t expose Jellyfin to the internet. It has a rather large attack surface and isn’t designed with security in mind.
Pretending everything is fine won’t solve the problem
Sounds like a great reason to use Plex instead!
edit: to add something constructive to my snarky comment, what kind of attack surface are we talkin here? Multiple ports? Lots of separate services running? No authentication?
There has been a known “anyone can access your media without authentication” vulnerability for seven years and counting, and the Jellyfin devs have openly stated that they have no intentions of fixing it. Because fixing it would require completely divesting from the Enby branch that the entire program is built upon. And they never plan on refactoring that entire thing, so they never plan on fixing the vulnerabilities.
The “don’t expose it to the internet” people aren’t just screaming at clouds. Jellyfin is objectively insecure, and shouldn’t be exposed.
yeah okay let me just connect grandma’s tv to a vpn.
edit: gas is $5/gal ya’ll, I’m not driving to a different state each time a new family member wants to watch something from my server!
Are you singling out Jellyfin for a particular reason? Or are also going to advise just never opening ports in general?
jellyfin people just always spout this advice as some sort of copium and i dont even know why. ALL software will have security issues at some point or another. just update and move on with your life.
That changelog just screams AI lol. All the emojis
