Jellyfin critical security update - This is not a joke


Als Antwort auf ElectricVocalist

There is a good reason I only have Jellyfin and other services accessible via valid Client Certificate.
Als Antwort auf daniskarma

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 features.jellyfin.org/posts/14…

Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf tiz

Pangolin is based off of Traefik if I’m not mistaken, should be able to use Traefiks IPAllowlist middleware to blacklist all IP addresses and only whitelisting the known few, that way you can expose your application to the internet knowing you have that restriction in place for those who connect to your service.
Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf VeganCheesecake

Oh yeah I’m aware, if people don’t want to use a VPN then I suggest this but give them the advisory warning.

Actually, recently I’ve been using a fork of IPAllowList which accepts DDNS addresses, but that usually is for more technical folk who would probably rather use a VPN then purchase a domain and associate it with their network.

Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf douglasg14b

What? No, you can do a tiny reverse proxy/vpn on a stick with something like a RPi. Configure it and give it to them. Then they point their Jellyfin client on their device to the IP of the RPi instance on their network and that creates the tunnel back to your VPN endpoint and server.

And for VPNs at a router level you can inject routes and leave th default route going out through your ISP, you don’t need to, nor want to, have all traffic going through it.

Als Antwort auf Damarus

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.
Als Antwort auf Damarus

Talking about security... Have you heard of intrusion detection, process isolation, or principle of least privilege?


are you aware that the very popular official docker image for jellyfin still runs the jellyfin process as root? or that most people just mount their media libraries as a read-write volume because they don't know better?

I would also be very interested about statistics on how many jellyfin admins run intrusion detection software on their system, if you have any.

Als Antwort auf Damarus

"if I don't have to". and, is your jellyfin running as root? or are you running it a different way, e.g. from apt package (where I believe it's sensible by default)? I smell doubt.

but in either case it does not matter how do you run jellyfin. what I care is how many other people are running jellyfin exposed to the internet because they think its safe, because people on forums told them so, with the popular docker image where it is being ran as root.

I'm not moving goalposts. I'm still firmly besides my point that for the general jellyfin admin exposing jellyfin to the wide internet is unsafe and irresponsible. and seeing all the downvotes but no one else telling their opinion, it seems no one knows better either and they are just angry I pointed this out.
again, I don't care how are you running Jellyfin. I don't want to convince you on that, you do whats best for you, it seems you might have done some precautions. what I care is to not recommend these practices to others (without the full picture), because they are unsafe, especially without further precautions like running a(n unofficial) rootless jellyfin docker image and an intrusion detection system, which I guarantee most people won't have.

Als Antwort auf ugo

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.

Als Antwort auf douglasg14b

Tvs game consoles rokus so on so forth typically don't support VPN clients.


and that's why you set up a VPN client box on the location, set it up as a regular VPN client, and install a reverse proxy on it that the dumb clients can connect to.

the VPN box could be as simple as an old android phone no one uses, and termux

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf esc

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 github.com/jellyfin/jellyfin/i…

Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf CompactFlax

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.
Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf sanzky

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.

Als Antwort auf FauxLiving

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

Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf WhyJiffie

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.

Als Antwort auf CompactFlax

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.

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf CompactFlax

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.
Als Antwort auf Lemmchen

The problem here - it's not me who requires access to my library, if someone isn't willing or able to do it, I'm sorry but that's just how it is. People should stop infantilize non-technical people, absolute majority of them is capable of navigating our world without much problems and I'm willing to help them if help is asked.

If my 60 y.o. mother with close to zero technical skills can do it with limited help (due to distance and other constraints) I'm pretty sure that majority of people with sound mind can.

Dieser Beitrag wurde bearbeitet. (3 Wochen her)
Als Antwort auf esc

Or you can not be arrogant towards your friends and family who have probably helped you on lots of occasions and will probably keep being there for you in the future.
Idk man, unconditional sharing feels pretty good, tbh. Making them jump through hoops isn't really my jam. To me this kinda all plays into making a stronger bond with people that are close to me, so maybe we have different reasons for why we are sharing our stuff.

Inb4 "we are not the same" meme

Als Antwort auf ohshit604

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.

Als Antwort auf quick_snail

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?

Als Antwort auf GatekeeperOnTurdMountain

I know you're gatekeeping from Turd Mountain, but just for completeness, the reason I use Jellyfin besides the "pretty for my wife" reason is that it keeps track of her progress between clients. She sometimes watches things on her laptop, sometimes her phone, sometimes her tablet, and sometimes the TV, and no matter which one she uses it'll remember which episode of her show is the next episode. It also highlights when a new episode of something has been added and cues her to watch the new episode that just came out.

But yeah, if I was alone and only had a pile of anime I'd already seen before, which I only watched from my Linux devices, Samba and VLC would do me fine 😛

Als Antwort auf ElectricVocalist

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer LettersMore Letters
GitPopular version control system, primarily for code
HTTPHypertext Transfer Protocol, the Web
IPInternet Protocol
NFSNetwork File System, a Unix-based file-sharing protocol known for performance and efficiency
PlexBrand of media server package
RPiRaspberry Pi brand of SBC
SBCSingle-Board Computer
SMBServer Message Block protocol for file and printer sharing; Windows-native
SSHSecure Shell for remote terminal access
SSLSecure Sockets Layer, for transparent encryption
TLSTransport Layer Security, supersedes SSL
VPNVirtual Private Network
VPSVirtual Private Server (opposed to shared hosting)
nginxPopular 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]

Dieser Beitrag wurde bearbeitet. (1 Woche her)
Als Antwort auf rose56

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...
Als Antwort auf ohulancutash

Yeah this is unfortunate news for me as well. I have a primary container I use for videos, and then a 10.10 server for music. 10.11 is borderline unusable for music for me, and I've tried everything for rescanning to completely redoing the server set up (rip accidentally deleting all my music playlists).

But i shall kill off the 10.10 container and hope a performance fix is in the works.

Als Antwort auf clif

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.

Als Antwort auf JigglySackles

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.

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf mrbutterscotch

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:
major.io/p/podman-quadlet-auto…

Caveat: I am a docker compose user, I may have missed something due to lack of familiarity with quadlets/podman

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf

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 image setting besides latest. That is, if the quadlet file specified something like Image=docker.io/jellyfin/jellyfin:a_old_version. I usually stick with latest on mine.

EG:
Image=docker.io/jellyfin/jellyfin:latest

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf Evotech

Three. Three emojis, used in headings as a bullet point.

It is perfectly plausable for someone whos job is to write technical documentation and promotional material would punch it up with a couple 'mojis.

github.com/jellyfin/jellyfin/r…

Every single release uses the same format with the same 3 emojis. You'd know that if you'd clicked "releases" and had even a modicum of curiosity.

Unbekannter Ursprungsbeitrag

lemmy - Link zum Originalbeitrag

SayCyberOnceMore

Not really.

Depending on how you install things, the package maintainers usually deal with this, so your next apt update / pacman -Syuv or ... 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)

Unbekannter Ursprungsbeitrag

lemmy - Link zum Originalbeitrag

ShortN0te

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.

Unbekannter Ursprungsbeitrag

lemmy - Link zum Originalbeitrag

irmadlad

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.

Als Antwort auf quick_snail

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 .pacnew files) and then kick Ansible into action for the rest.

Als Antwort auf quick_snail

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.
Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf Bazoogle

I run pretty much all my stuff through NPMplus. Then I have a firewall between my public and private networks in case something does get compromised. But I've had Plex exposed (on a non-default port) for literally years and nothing ever happens.
Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf Bazoogle

Primarily for the CrowdSec integration (one less thing to set up manually)

virtualizationhowto.com/2025/0…

Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf Possibly linux

Sure, but being mostly secure by default isn't one of them. One advantage of running a service that offers optional subscription services is that they can offer security features like built-in SSL and AAA that just work. Any average user can install it and have a reasonably secure service running. Hell, until a few months ago you didn't even need to open a port to have remote access to your content, whether you paid or not. Now they've made that a paid feature though.
Dieser Beitrag wurde bearbeitet. (2 Wochen her)
Als Antwort auf

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.

Unbekannter Ursprungsbeitrag

lemmy - Link zum Originalbeitrag

communism

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.