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.
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.
well, at least you are not depending on the application to do TLS properly, and you may be able to set up some access restrictions that your clients may support
Reverse proxy will let anyone connect to it. VPN, you can create keys/logins for your intended users only. Having said that, from what I could see, nothing in the security fixes were to do with authentication. I think (just from a cursory look), they could only be exploited, if at all from an authenticated user session.
But personally, something like jellyfin where the number of people I want to be able to access it is very limited, stays behind a VPN. Better to limit your potential attack surface as much as you can.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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
yeah. it did. took a bit. i used headscale initramfs with dropbear for my servers. Didnt find anything for netbird so i copied the headscale initram script and changed it for netbird. But all works now. I like it.
The thing is, if you have non-technical users, you have to set up the VPN connection on the client site yourself, maybe on multiple machines and more than once, if they decide to upgrade or even just reset their devices.
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.
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.
I'm not arrogant, just don't assume that people are dumb and inept. If they can't or don't want to give a bit of time to setup it, well how can someone be forced to use free service that causes momentarily inconvenience once to use. 😔
Users cause issues. Programs cause issues. Connecting it to the internet causes issues. Having a computer causes issues. Better turn your laptop off and throw it on the garbage.
idk man, I wont keep my front gate unlocked just so my friends can come in without keys. either they accept having to carry an additional key, or they won't have access without me, but I'm not going to compromise on reasonable security. oh the burden I know.
I'll help them set it up if they want it, they are not on their own. but zero effort won't work.
So use a reverse proxy with authentiacation before access to Jellyfin is allowed. I use Caddy forward_auth with Authelia for this. Unless you also want to use the apps without VPN, this works great.
No. As I said, apps don't work. I cobbled together an API key service that let's you have an API key (password) in the server URL in Rust for myself. This works with Apps, but it is a bit too messy and single purpose for me to open source it right now. Maybe one day.
...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
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
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
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.
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.
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.
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.
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.
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
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 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.
Ahh bummer. Not sure exactly then. Might have to hop in the terminal and try an --update or find an equivalent with--help. The documentation in the git repo should tell you if nothing else.
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
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
It's probably database performance related. There's a massive PR undergoing round after round of reviews that, when merged, will be a change to 10.12 and will resolve all of the new database performance issues experienced in certain edge cases (book libraries, large music libraries, large collections, etc)
I don’t have books, moved music to navidrome, and have a relatively small library and it just will not play nice. Library scans lasting for days kind of nasty. RAM and CPU domination.
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.
I'm talking average enough to see an article, or hear about it from a friend/coworker, then follow the insanely easy setup directions for Windows. I know plenty of people who aren't really "computer people" but know enough to open a port because they had to to get a game working at some point or another. Those people probably wouldnt notice "hey this thing is going to http maybe i should rethink this...."
These are going to be the people who think it's smart to just open up RDP and SSH to the wide web though...they shouldn't be forwarding ports...they should use a VPN.
I had to explain to one of them why RDP is a bad idea lol. Thats kind of my point - average people tend to only know enough to be dangerous, not to do things safely. Or as Shakespeare said - "The fool doth think he is wise, but the wise man knows himself to be a fool.”
I think you're missing the point - that's neither simple nor easy for most people. I'm a network engineer and I don't wanna deal with setting up and (being responsible for troubleshooting) a bunch of VPNs! Nevermind the additional power/CPU usage from the tunnels. My parents just got fiber and they don't even have a public address (ipv4 or v6) which just adds another layer of headache. thanks west virginia...
I'd much rather deal with setting up a few VPN gateways which is trivial at most...than securing a public web service. I deal with that crap enough at work.
There are a lot less variables to contend with with a single VPN endpoint which undergoes considerably more security auditing than N public web services. Many of which I don't have the time to review myself and mitigate if they decide to suck at coding.
Edit: I share my services with less than 5 households though.
Edit2: I'm not sure what public ipv4 or ipv6 has to do with this. My remote sites use starlink ipv4. I haven't setup ipv6 on those internally at all. They all tunnel via wireguard to my homesite.
At my remote site it has little value. At my home I have IPv6 setup on Starlink as my secondary backup internet. I use Fiber as the primary that has a public IPv4 and IPv6.
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.
Exactly. And that’s honestly why I doubt it will ever truly contend with Plex. It’s fine for sharing with friends who can figure out how to connect via VPN, but it’ll never be robust enough to share with your tech-illiterate grandparents on the open internet. Plex wins handily in that regard, because their sign in process is basically the same as Netflix, HBO, Hulu, etc…
Plex has problems of its own, but (at least as of me writing this) it doesn’t have any major known security vulnerabilities. They had some level 10.0 vulnerability last year, but they followed standard CVE protocols and patched it before the vulnerability was actually released.
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.
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.
But I think more than copium it's them understanding their users. It's advice for people that will figure out how to run Jellyfin but won't stay on top of updates, setup a waf, use a firewall/reverseproxy to limit access, etc. There are surely a lot of those that just one clicked an installer etc and for them it's good advice.
None really, just wondering what the issue with opening it up is if it has TLS? In 10+ years I've never had my Plex server compromised and it just uses TLS. I do change the default port but that's it.
That's kinda my perspective on it to. I mean, how do they think websites work? Gotta expose ports to make all the internet things happen. Sure commercial stuff will have more devices to protect it, but there are things you can do to mitigate issues at home too.
There is a new story every week in Steve Gibson's "Security Now" podcast about why you should virtually never open ports. And if you do, you'd better IP restrict. Even, or especially, in commercial products. Cisco has a new CVSS 10.0 every other week just about
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.
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 😛
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 😛
Use NFS for your sanity. Linux samba/CIFS is annoying to deal with.
Honestly, I'm not a big fan if Microsoft generally, but I found NFS to be surprisingly not great for non-permanent infrastructure, whereas SMB took a few minutes and works great, at least in my use cases. Maybe I'm just a loser, though.
257 Comments
esc@piefed.social · 172 pts · 126d
Don't expose jellyfin to the internet is a golden rule.
Damarus@feddit.org · 116 pts · 126d
Kinda defeats the purpose of a media server built to be used by multiple people
InnerScientist@lemmy.world · 60 pts · 126d
Use a VPN, it's not ideal but it's secure.
faercol@lemmy.blahaj.zone · 44 pts · 126d
Somehow difficult to install on a TV though.
ramble81@lemmy.zip · 24 pts · 126d
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
faercol@lemmy.blahaj.zone · 46 pts · 126d
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.
douglasg14b@lemmy.world · 11 pts · 125d
Oh yes, the routers and gateways that most people have that are isp provided that may not actually have open VPN or wireguard support.
Those ones?
Also putting a VPN in someone else's house so that all their Network traffic goes through your gateway is pretty damn extreme.
ramble81@lemmy.zip · -2 pts · 125d
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.
tiz@lemmy.ml · 9 pts · 126d
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.
radar@programming.dev · 31 pts · 126d
Reverse proxy doesn't really get you much security. If there is an application level issue a reverse proxy will not help
whimsy@lemmy.zip · 4 pts · 126d
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?
radar@programming.dev · 2 pts · 126d
You can, that would actually give you security. Not sure how many people do that. I assumed a straight reverse proxy without any auth
PeriodicallyPedantic@lemmy.ca · 2 pts · 124d
I think that's one of the major reasons to use pangolin over something like nginx - built in auth and support for oidc.
Of course, the native jellyfin apps don't like the auth layer so idk if it helps if you're trying to install it on your dad's tv
tiz@lemmy.ml · 4 pts · 126d
I see thanks. I’ll think about it more.
WhyJiffie@sh.itjust.works · 1 pts · 125d
well, at least you are not depending on the application to do TLS properly, and you may be able to set up some access restrictions that your clients may support
r00ty@kbin.life · 13 pts · 126d
Reverse proxy will let anyone connect to it. VPN, you can create keys/logins for your intended users only. Having said that, from what I could see, nothing in the security fixes were to do with authentication. I think (just from a cursory look), they could only be exploited, if at all from an authenticated user session.
But personally, something like jellyfin where the number of people I want to be able to access it is very limited, stays behind a VPN. Better to limit your potential attack surface as much as you can.
PeriodicallyPedantic@lemmy.ca · 1 pts · 124d
Reverse proxies like the one specifically mentioned, pangolin, have auth and user access rules.
ohshit604@sh.itjust.works · 3 pts · 126d
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.
VeganCheesecake@lemmy.blahaj.zone · 4 pts · 126d
If the people you want to have access have static, exclusive ip addresses. Which is pretty unusual, these days.
ohshit604@sh.itjust.works · 1 pts · 126d
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.
Auli@lemmy.ca · 1 pts · 126d
Yahnlets see a roku use a VPN.
ugo@feddit.it · 9 pts · 126d
EncryptKeeper@lemmy.world · 24 pts · 126d
This attitude is why Plex remains popular.
keyez@lemmy.world · 18 pts · 126d
Easy for me but not my aunts, cousins or father in law to setup and use.
douglasg14b@lemmy.world · 8 pts · 125d
Nor will the VPN work on things like their TV or Roku or game console. You know the things that people typically sit down and watch media on....
Dultas@lemmy.world · -1 pts · 125d
Wireguard and possibly openvpn work on Android TVs. I set it up for my mom. Not sure about other OSs.
ugo@feddit.it · 1 pts · 126d
WhyJiffie@sh.itjust.works · 0 pts · 125d
they are not setting up the Jellyfin server either, why would they need to bother with the VPN?
vaionko@sopuli.xyz · 2 pts · 125d
They're connecting to it.
WhyJiffie@sh.itjust.works · 1 pts · 125d
yeah, it's the operator's job to help setting that up
Damarus@feddit.org · 14 pts · 126d
I'd rather just not use it at that point
ugo@feddit.it · 7 pts · 126d
Damarus@feddit.org · 12 pts · 126d
The difference is that my friends get a lot of value out of my server, as they don't need to use any technology they're unfamiliar with.
WhyJiffie@sh.itjust.works · -2 pts · 125d
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
Damarus@feddit.org · 4 pts · 125d
lol the whole internet better shut down right? Too vulnerable
WhyJiffie@sh.itjust.works · -5 pts · 125d
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.
Damarus@feddit.org · 4 pts · 125d
I mean I do this stuff for a living but okay go off king
douglasg14b@lemmy.world · 6 pts · 125d
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.
WhyJiffie@sh.itjust.works · 0 pts · 125d
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
CompactFlax@discuss.tchncs.de · 73 pts · 126d
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
AHemlocksLie@lemmy.zip · 39 pts · 126d
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.
IratePirate@feddit.org · 27 pts · 126d
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.
quick_snail@feddit.nl · 1 pts · 125d
Lol you shouldn't make such assumptions when they so obviously place sefiroty last
WhyJiffie@sh.itjust.works · 5 pts · 125d
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.
teawrecks@sopuli.xyz · 5 pts · 125d
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.
CompactFlax@discuss.tchncs.de · 7 pts · 125d
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.
teawrecks@sopuli.xyz · 2 pts · 125d
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.
Auli@lemmy.ca · 0 pts · 125d
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.
rumba@lemmy.zip · 2 pts · 125d
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...
Hammersamatom@lemmy.dbzer0.com · 1 pts · 126d
Unfortunately, not everyone is tech-literate enough nowadays to understand how a VPN works, nor do they want to
FauxLiving@lemmy.world · 5 pts · 126d
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.
Hammersamatom@lemmy.dbzer0.com · 3 pts · 126d
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
FauxLiving@lemmy.world · 1 pts · 126d
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.
WhyJiffie@sh.itjust.works · 1 pts · 125d
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.
FauxLiving@lemmy.world · 1 pts · 125d
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:
That's a true statement about 'everyone' i.e. the entire population of the planet... but true about everyone here in this community.
Infernal_pizza@lemmy.dbzer0.com · 3 pts · 126d
Isn't it easier to set up a VPN than expose it to the internet?
sanzky@lemmy.world · 6 pts · 126d
and then you are giving access to your lan to people whose computer you don’t control and might be full of malware.
Infernal_pizza@lemmy.dbzer0.com · 5 pts · 126d
Tbh I forgot about giving access to others, my homelab is for me only lol
FauxLiving@lemmy.world · 2 pts · 126d
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.
WhyJiffie@sh.itjust.works · 2 pts · 125d
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.
sanzky@lemmy.world · 1 pts · 125d
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
Hammersamatom@lemmy.dbzer0.com · 3 pts · 126d
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
WhyJiffie@sh.itjust.works · 1 pts · 125d
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.
WhyJiffie@sh.itjust.works · 1 pts · 125d
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.
douglasg14b@lemmy.world · 1 pts · 125d
mic_check_one_two@lemmy.dbzer0.com · 0 pts · 125d
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.
Auli@lemmy.ca · 6 pts · 125d
They didn't start the project from Kodi. It is a fork of Emby.
atzanteol@sh.itjust.works · 18 pts · 126d
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.
WhyJiffie@sh.itjust.works · 4 pts · 125d
to be fair, Jellyfin had multiple unauthenticated vulnerabilities in the past so it makes sense to talk about it
possiblylinux127@lemmy.zip · 1 pts · 125d
The design of Jellyfin is really insecure
possiblylinux127@lemmy.zip · 0 pts · 125d
It isn't a supply chain attack. If it was they would've disclosed it mmediately instead of waiting.
LycaKnight@infosec.pub · 14 pts · 126d
Yeah, i have my 30 docker containers behind Headscale (Tailscale).
pfr@piefed.social · 9 pts · 126d
NetBird is coming for you
antrosapien@lemmy.ml · 3 pts · 126d
I have been planning to check out Netbird for couple of days. Is it a good alternative for headscale and pangolin?
pfr@piefed.social · 2 pts · 126d
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.
antrosapien@lemmy.ml · 1 pts · 125d
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
LycaKnight@infosec.pub · 1 pts · 102d
yeah. it did. took a bit. i used headscale initramfs with dropbear for my servers. Didnt find anything for netbird so i copied the headscale initram script and changed it for netbird. But all works now. I like it.
Lemmchen@feddit.org · 8 pts · 126d
The thing is, if you have non-technical users, you have to set up the VPN connection on the client site yourself, maybe on multiple machines and more than once, if they decide to upgrade or even just reset their devices.
esc@piefed.social · 20 pts · 126d
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.
Lemmchen@feddit.org · 8 pts · 126d
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
esc@piefed.social · 5 pts · 126d
I'm not arrogant, just don't assume that people are dumb and inept. If they can't or don't want to give a bit of time to setup it, well how can someone be forced to use free service that causes momentarily inconvenience once to use. 😔
irmadlad@lemmy.world · 3 pts · 126d
Pass. Users cause complexities. Complexities cause issues.
BladeFederation@piefed.social · 4 pts · 126d
Users cause issues. Programs cause issues. Connecting it to the internet causes issues. Having a computer causes issues. Better turn your laptop off and throw it on the garbage.
irmadlad@lemmy.world · 1 pts · 125d
The difference being, I can control computers, laptops, servers, etc. I cannot control users.
WhyJiffie@sh.itjust.works · 1 pts · 125d
idk man, I wont keep my front gate unlocked just so my friends can come in without keys. either they accept having to carry an additional key, or they won't have access without me, but I'm not going to compromise on reasonable security. oh the burden I know.
I'll help them set it up if they want it, they are not on their own. but zero effort won't work.
IratePirate@feddit.org · 6 pts · 126d
This. And for everyone you just can't figure it out on their own, there's RustDesk for remote assistance. It, too, can be self-hosted.
DreamlandLividity@lemmy.world · 8 pts · 126d
So use a reverse proxy with authentiacation before access to Jellyfin is allowed. I use Caddy forward_auth with Authelia for this. Unless you also want to use the apps without VPN, this works great.
Lemmchen@feddit.org · 4 pts · 126d
Does that work for the Android and Android TV apps?
DreamlandLividity@lemmy.world · 3 pts · 126d
No. As I said, apps don't work. I cobbled together an API key service that let's you have an API key (password) in the server URL in Rust for myself. This works with Apps, but it is a bit too messy and single purpose for me to open source it right now. Maybe one day.
inclementimmigrant@lemmy.world · 1 pts · 126d
Got instructions or a site to point to on setting something like that up?
DreamlandLividity@lemmy.world · 1 pts · 126d
Honestly, I may have to write one at some point. I just used the documentation of those two tools to set it up.
maplesaga@lemmy.world · 3 pts · 126d
Utilize authelia perhaps?
yabbadabaddon@lemmy.zip · 7 pts · 126d
Doesn't work with TVs
AllHailTheSheep@sh.itjust.works · 2 pts · 126d
ldap auth will work on tvs
exu@feditown.com · 3 pts · 126d
But that's basically using the same built-in auth. If there's an auth bypass I don't think it makes a difference.
AllHailTheSheep@sh.itjust.works · 2 pts · 125d
not really. you can disable the default jellyfin login and force it to use ONLY ldap.
possiblylinux127@lemmy.zip · 0 pts · 125d
...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
quick_snail@feddit.nl · 3 pts · 125d
If only they would fix the htaccess bug
yannic@lemmy.ca · 1 pts · 119d
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.
quick_snail@feddit.nl · 1 pts · 119d
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
yannic@lemmy.ca · 1 pts · 117d
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?
quick_snail@feddit.nl · 1 pts · 117d
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.
yannic@lemmy.ca · 1 pts · 116d
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.
ligma_centauri@lemmy.world · 1 pts · 124d
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.
mriormro@lemmy.zip · 1 pts · 125d
Don’t ever shit in your own house, either.
Just in case they’re watching.
possiblylinux127@lemmy.zip · 1 pts · 125d
I shit in my toilet
kbobabob@lemmy.dbzer0.com · 0 pts · 126d
So don't use it outside your house? Pass
esc@piefed.social · -4 pts · 126d
Nothing stops you from using it outside of your house.
bonenode@piefed.social · 16 pts · 126d
traxex@lemmy.dbzer0.com · 1 pts · 126d
Tailscale is a super easy vpn that gives you access to your home network from anywhere. And it’s free.
esc@piefed.social · 1 pts · 126d
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.
Luminous5481@anarchist.nexus · 0 pts · 125d
Auli@lemmy.ca · 1 pts · 126d
It kind of does. Whatever and yes I'm aware of the list people keep posting and I've looked at it.
AllHailTheSheep@sh.itjust.works · 0 pts · 126d
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.
possiblylinux127@lemmy.zip · 0 pts · 125d
I still wouldn't do it personally
ohshit604@sh.itjust.works · -1 pts · 126d
AllHailTheSheep@sh.itjust.works · 3 pts · 126d
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.
Luminous5481@anarchist.nexus · 0 pts · 125d
clif@lemmy.world · 122 pts · 126d
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
mrbutterscotch@feddit.org · 4 pts · 125d
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.
def@aussie.zone · 9 pts · 125d
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
clif@lemmy.world · 4 pts · 125d
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:latestmrbutterscotch@feddit.org · 4 pts · 125d
It worked! Thanks so much!
I suppose I'll start looking into docker/containers/quadlets etc, so I actually understand what I am using lol
JigglySackles@lemmy.world · 2 pts · 125d
Poke around through the dash. I imagine it's in the GUI there. Probably under a menu like 'system' or 'about'.
mrbutterscotch@feddit.org · 3 pts · 125d
Thanks for the reply!
Sadly I can't find anything, unless I am super blind.
JigglySackles@lemmy.world · 2 pts · 125d
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.mrbutterscotch@feddit.org · 2 pts · 124d
This suggestion from another commenter worked! Apparently quadlets work with Podman in the background.
JigglySackles@lemmy.world · 1 pts · 124d
Ahh baller man. Glad you got it sorted! And thanks for sharing the fix
catlover@sh.itjust.works · 56 pts · 126d
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
Burghler@sh.itjust.works · 39 pts · 126d
Wonder if it's the Axios one. Sounds like it isn't from their description though hmm
doeknius_gloek@discuss.tchncs.de · 24 pts · 126d
I don't think so, the previous release 10.11.6 is a few months old and the axios supply chain attack happened yesterday.
Strit@lemmy.linuxuserspace.show · 13 pts · 126d
So lets hope this 10.11.7 is not subject to the axios one. :)
rollerbang@lemmy.world · 13 pts · 126d
Diff agrees, not likely. Might be permisson related, elevation of privileges.
r00ty@kbin.life · 14 pts · 126d
From a cursory look at just the security commits. Looks like the following:
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.
chuso@fedia.io · 7 pts · 126d
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.
r00ty@kbin.life · 5 pts · 126d
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.
atzanteol@sh.itjust.works · 2 pts · 126d
sudoMakeUser@sh.itjust.works · 0 pts · 126d
Axios is a Javascript library and Jellyfin is written in C#.
dvlsg@lemmy.world · 8 pts · 126d
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.
sudoMakeUser@sh.itjust.works · -3 pts · 126d
The web server is in C#. It's open source lol, I'm looking at the code and there's no JavaScript.
Mubelotix@jlai.lu · 10 pts · 126d
Look better https://github.com/jellyfin/jellyfin-web
sudoMakeUser@sh.itjust.works · 2 pts · 126d
That's awkward. I didn't know that was in a separate repo.
Mubelotix@jlai.lu · 1 pts · 126d
webkitten@piefed.social · 29 pts · 126d
Scrollone@feddit.it · 1 pts · 125d
Yeah, I think what went wrong and now everything is installed through Docker.
Docker feels like a huge security problem to me.
possiblylinux127@lemmy.zip · 2 pts · 125d
Why?
Docker makes everything so much easier
Scrollone@feddit.it · 1 pts · 124d
I know, but your security then depends on the package maintainer to keep the image up to date
phobiac@lemmy.world · 1 pts · 122d
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.
psoul@lemmy.world · 28 pts · 126d
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.
ShortN0te@lemmy.ml · 27 pts · 126d
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.
Cyber@feddit.uk · 5 pts · 126d
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)
psoul@lemmy.world · 4 pts · 126d
I indeed use a container. Wasn’t familiar with the update process for containers but now know how to do it.
ButtDrugs@lemmy.zip · 5 pts · 125d
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.
hellequin67@piefed.social · 1 pts · 120d
Can highly recommend dockhand happily runs my full docker stack with updates and great overviews of what's happening under the hood.
communism@lemmy.ml · 2 pts · 125d
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.
psoul@lemmy.world · 1 pts · 125d
Thank you. Will look into it.
quick_snail@feddit.nl · -7 pts · 125d
Lol it's already insecure then. Don't bother.
mic_check_one_two@lemmy.dbzer0.com · 4 pts · 125d
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.
quick_snail@feddit.nl · -1 pts · 125d
Docker is known insecure. It doesn't verify any layers it pulls cryptography. The devs are aware. The tickets remain open.
psoul@lemmy.world · 1 pts · 125d
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.
quick_snail@feddit.nl · 1 pts · 123d
Jellyfin has a Debian repo. Worked fine on Debian 12 and 13.
def@aussie.zone · 1 pts · 125d
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.
quick_snail@feddit.nl · 1 pts · 123d
No, it's also vulnerable to a targeted mitm attack. Github can be unaffected and you can get a malicious version on your server.
mpramann@discuss.tchncs.de · 3 pts · 125d
Insane way of thinking.
quick_snail@feddit.nl · 3 pts · 125d
Unattended upgrades set to security only and never worry
Cyber@feddit.uk · 6 pts · 125d
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.quick_snail@feddit.nl · 1 pts · 125d
Why does unattended upgrades with security only setting not fix this?
This is literally why Debian has distinct repos for security updates.
Cyber@feddit.uk · 1 pts · 124d
Let me know which repo this update appears in.
quick_snail@feddit.nl · 1 pts · 123d
The jellyfin repo
Appoxo@lemmy.dbzer0.com · 2 pts · 124d
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.
irmadlad@lemmy.world · 2 pts · 126d
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.
psoul@lemmy.world · 1 pts · 124d
Wait a minute, best security practice is to use the latest version -1?
varnia@lemmy.blahaj.zone · 28 pts · 126d
There is a good reason I only have Jellyfin and other services accessible via valid Client Certificate.
daniskarma@lemmy.dbzer0.com · 8 pts · 126d
Does it work with android and TV apps?
I tried long ago and failed.
varnia@lemmy.blahaj.zone · 14 pts · 126d
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
greyscale@lemmy.grey.ooo · 4 pts · 126d
> No, we only use Jellyfin via browser.
sudoMakeUser@sh.itjust.works · 2 pts · 126d
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.
daniskarma@lemmy.dbzer0.com · 2 pts · 126d
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.
sturmblast@lemmy.world · 15 pts · 125d
You can always tell who does real IT work in these threads lol
cholesterol@lemmy.world · 10 pts · 126d
In the raspian repos, just updated, thanks.
Strit@lemmy.linuxuserspace.show · 8 pts · 126d
also in the docker repository.
sefra1@lemmy.zip · 9 pts · 124d
Good thing my Jellyfin is behind Wireguard.
Consider doing the same if your usecase permits.
Decronym@lemmy.decronym.xyz · 8 pts · 126d
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
12 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.
[Thread #203 for this comm, first seen 1st Apr 2026, 09:50] [FAQ] [Full list] [Contact] [Source code]
Wispy2891@lemmy.world · 8 pts · 126d
Thanks for this post, i would have updated mine next semester...
lmr0x61@lemmy.ml · 5 pts · 126d
The update rolled out perfectly for my Kubernetes setup (using the Docker image). 👍
roserose56@lemmy.zip · 5 pts · 126d
Im on fedora and I have installed through dnf, no updates with the dnf update..... should I wait?
gigachad@piefed.social · 7 pts · 126d
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...
somehacker@lemmy.world · 12 pts · 126d
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.
possiblylinux127@lemmy.zip · 1 pts · 125d
I don't believe it a supply chain compromise
somehacker@lemmy.world · 1 pts · 125d
Same. I was pointing out that if it was related to Axios then it’s already too late.
roserose56@lemmy.zip · 2 pts · 126d
It's on my home, which is not 24/7 open. Will see check later.
AllHailTheSheep@sh.itjust.works · 3 pts · 126d
thanks for posting this!
Diurnambule@jlai.lu · 2 pts · 126d
Just updated, thanks for the info <3
aliser@lemmy.world · 2 pts · 124d
please tell me it doesn't expose itself onto public web by default
ohulancutash@feddit.uk · 1 pts · 126d
If only 10.11 were usable for me at all.
Lemmchen@feddit.org · 4 pts · 126d
What's the issue?
Ruthalas@infosec.pub · 3 pts · 126d
In addition to the other comment, it currently has some pretty rough performance issues with big libraries.
Mubelotix@jlai.lu · 2 pts · 126d
There was a regression that caused Jellyfin to be a LOT more restrictive regarding the structured filesystem format. But this could be something else
Edit: Maintainers told me they were gonna fix it
entropicdrift@lemmy.sdf.org · 2 pts · 126d
It's probably database performance related. There's a massive PR undergoing round after round of reviews that, when merged, will be a change to 10.12 and will resolve all of the new database performance issues experienced in certain edge cases (book libraries, large music libraries, large collections, etc)
ohulancutash@feddit.uk · 1 pts · 125d
I don’t have books, moved music to navidrome, and have a relatively small library and it just will not play nice. Library scans lasting for days kind of nasty. RAM and CPU domination.
zeitverschreib@freundica.de · 1 pts · 125d
@ohulancutash You may want to have a look at #Lyrion.
@entropicdrift
HereIAm@lemmy.world · 2 pts · 126d
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.
possiblylinux127@lemmy.zip · -6 pts · 125d
Just a reminder that you should never expose Jellyfin to the internet
kieron115@startrek.website · 21 pts · 125d
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!
possiblylinux127@lemmy.zip · 1 pts · 125d
There are plenty of ways around this
A cheap thin client minipc is only like 20-40 USD and would solve the problem overnight
kieron115@startrek.website · 3 pts · 125d
I can set it up, and you can set it up, but for the average user?
possiblylinux127@lemmy.zip · 6 pts · 125d
The average user isn't using Jellyfin
All you need is a little Linux knowledge in order to setup Netbird with Caddy
kieron115@startrek.website · 1 pts · 125d
I'm talking average enough to see an article, or hear about it from a friend/coworker, then follow the insanely easy setup directions for Windows. I know plenty of people who aren't really "computer people" but know enough to open a port because they had to to get a game working at some point or another. Those people probably wouldnt notice "hey this thing is going to http maybe i should rethink this...."
Shnog@lemmy.world · 2 pts · 125d
These are going to be the people who think it's smart to just open up RDP and SSH to the wide web though...they shouldn't be forwarding ports...they should use a VPN.
kieron115@startrek.website · 1 pts · 125d
I had to explain to one of them why RDP is a bad idea lol. Thats kind of my point - average people tend to only know enough to be dangerous, not to do things safely. Or as Shakespeare said - "The fool doth think he is wise, but the wise man knows himself to be a fool.”
Shnog@lemmy.world · -1 pts · 125d
Setup a VPN gateway at Grandma's house. Works fine for me.
kieron115@startrek.website · 5 pts · 125d
I think you're missing the point - that's neither simple nor easy for most people. I'm a network engineer and I don't wanna deal with setting up and (being responsible for troubleshooting) a bunch of VPNs! Nevermind the additional power/CPU usage from the tunnels. My parents just got fiber and they don't even have a public address (ipv4 or v6) which just adds another layer of headache. thanks west virginia...
Shnog@lemmy.world · 2 pts · 125d
I'd much rather deal with setting up a few VPN gateways which is trivial at most...than securing a public web service. I deal with that crap enough at work.
There are a lot less variables to contend with with a single VPN endpoint which undergoes considerably more security auditing than N public web services. Many of which I don't have the time to review myself and mitigate if they decide to suck at coding.
Edit: I share my services with less than 5 households though.
Edit2: I'm not sure what public ipv4 or ipv6 has to do with this. My remote sites use starlink ipv4. I haven't setup ipv6 on those internally at all. They all tunnel via wireguard to my homesite.
kieron115@startrek.website · 4 pts · 125d
When I set up wireguard it was just more complicated when one side didn't have a public IP. Whyyyy can't we adopt ipv6 already.
kieron115@startrek.website · 2 pts · 125d
also fyi starlink has public ipv6 available if you DO wan't to set it up. been hosting a minecraft server off a starlink connection lol.
Shnog@lemmy.world · 1 pts · 125d
At my remote site it has little value. At my home I have IPv6 setup on Starlink as my secondary backup internet. I use Fiber as the primary that has a public IPv4 and IPv6.
Could just use a VPS though I guess if you want.
sefra1@lemmy.zip · 1 pts · 124d
If you have the skills to setup a Jellyfin server you also have the skills to setup wireguard.
That's a very specific use case.
kieron115@startrek.website · 1 pts · 124d
They appear to offer a guided installation for windows users.
magguzu@lemmy.pt · 13 pts · 125d
The worst part of enthusiast threads are the "I am very smart" takes like this
possiblylinux127@lemmy.zip · 8 pts · 125d
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
kieron115@startrek.website · 3 pts · 125d
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?
mic_check_one_two@lemmy.dbzer0.com · 7 pts · 124d
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.
kieron115@startrek.website · 3 pts · 124d
Jeez, so it's meant to be a literal home media server. Able, but not designed, to be used for sharing.
mic_check_one_two@lemmy.dbzer0.com · 5 pts · 124d
Exactly. And that’s honestly why I doubt it will ever truly contend with Plex. It’s fine for sharing with friends who can figure out how to connect via VPN, but it’ll never be robust enough to share with your tech-illiterate grandparents on the open internet. Plex wins handily in that regard, because their sign in process is basically the same as Netflix, HBO, Hulu, etc…
Plex has problems of its own, but (at least as of me writing this) it doesn’t have any major known security vulnerabilities. They had some level 10.0 vulnerability last year, but they followed standard CVE protocols and patched it before the vulnerability was actually released.
grrgyle@slrpnk.net · 2 pts · 124d
Ahh bummer. It works so well as a home media server... kind of calls out for sharing.
possiblylinux127@lemmy.zip · 5 pts · 125d
Plex has its own set of problems
kieron115@startrek.website · 1 pts · 125d
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.
JigglySackles@lemmy.world · 8 pts · 125d
Are you singling out Jellyfin for a particular reason? Or are also going to advise just never opening ports in general?
kieron115@startrek.website · 13 pts · 125d
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.
neclimdul@lemmy.world · 5 pts · 125d
Definitely.
But I think more than copium it's them understanding their users. It's advice for people that will figure out how to run Jellyfin but won't stay on top of updates, setup a waf, use a firewall/reverseproxy to limit access, etc. There are surely a lot of those that just one clicked an installer etc and for them it's good advice.
kieron115@startrek.website · 1 pts · 125d
that's fair, does it not have any kind of encryption by default?
HK65@sopuli.xyz · 2 pts · 125d
Standard TLS, I think, but what else would you need?
kieron115@startrek.website · 1 pts · 125d
None really, just wondering what the issue with opening it up is if it has TLS? In 10+ years I've never had my Plex server compromised and it just uses TLS. I do change the default port but that's it.
neclimdul@lemmy.world · 2 pts · 125d
Plex logins go through their login server so you'll also have login throttling and probably other bot protections.
JigglySackles@lemmy.world · 4 pts · 125d
That's kinda my perspective on it to. I mean, how do they think websites work? Gotta expose ports to make all the internet things happen. Sure commercial stuff will have more devices to protect it, but there are things you can do to mitigate issues at home too.
Bazoogle@lemmy.world · 1 pts · 124d
There is a new story every week in Steve Gibson's "Security Now" podcast about why you should virtually never open ports. And if you do, you'd better IP restrict. Even, or especially, in commercial products. Cisco has a new CVSS 10.0 every other week just about
kieron115@startrek.website · 1 pts · 124d
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.
Bazoogle@lemmy.world · 1 pts · 124d
Why NPMplus and not the default NPM?
kieron115@startrek.website · 2 pts · 124d
Primarily for the CrowdSec integration (one less thing to set up manually)
https://www.virtualizationhowto.com/2025/09/nginx-proxy-manager-vs-npmplus-which-one-is-better-for-your-home-lab/
Bazoogle@lemmy.world · 1 pts · 124d
Why link the fork of a fork in your original response?
Shnog@lemmy.world · 1 pts · 125d
For the vast majority of users? Yes. They shouldn't forward ports.
Setup a VPN gateway at Grandma's house.
possiblylinux127@lemmy.zip · 0 pts · 125d
Jellyfin is particularly bad compared to other things. You still should avoid exposing stuff to the internet
Jaybird@lemmy.world · 1 pts · 124d
Evotech@lemmy.world · -15 pts · 126d
That changelog just screams AI lol. All the emojis
greyscale@lemmy.grey.ooo · 27 pts · 126d
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.
https://github.com/jellyfin/jellyfin/releases
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.
irmadlad@lemmy.world · 7 pts · 126d
No worries. We've been communicating with pictures since ancient cave men scrawled pictographs on cave walls with a piece of burnt firewood.
Electricd@lemmybefree.net · 4 pts · 126d
It isn’t, not that I would care anyways
GatekeeperOnTurdMountain@programming.dev · -23 pts · 126d
psycotica0@lemmy.ca · 20 pts · 126d
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 😛
FauxLiving@lemmy.world · 5 pts · 126d
Use NFS for your sanity. Linux samba/CIFS is annoying to deal with.
Also, mpv
psycotica0@lemmy.ca · 4 pts · 125d
Honestly, I'm not a big fan if Microsoft generally, but I found NFS to be surprisingly not great for non-permanent infrastructure, whereas SMB took a few minutes and works great, at least in my use cases. Maybe I'm just a loser, though.
FauxLiving@lemmy.world · 2 pts · 125d
Nah, if it works for you then use it. There are no rules here!
roserose56@lemmy.zip · 10 pts · 126d
Nope? how about fancy stuff GUI and plot?
IMDB on your phone I guess....
frongt@lemmy.zip · 5 pts · 126d
Am I having a stroke?
Railcar8095@lemmy.world · 4 pts · 126d
At the time off writing you made a few more comments, so either "no" or "yes but your life is Lemmy".
possiblylinux127@lemmy.zip · 0 pts · 125d
Do you smell burning fish?