Collection of potential security issues in Jellyfin This is a non exhaustive list of potential security issues found in Jellyfin. Some of these might cause controversy. Some of these are design fla…
PluginsController only requires user privileges for potentially sensitive actions
- Includes, but is not limited to: Listing all plugins on the server without being admin, changing plugin settings, listing plugin settings without being admin. This includes the possibility of retrieving LDAP access credentials without admin privileges.
Outch
For those unaware, it’s a good idea to be using a service like tailscale (self hosted=headscale if you don’t want to make your login credentials tied to apple, google, or Microsoft). It’s a VPN but a lot simpler to use.
I remember when they were arguing that you don’t need a VPN or proxy basic authentication in front of it because their team knows how to write secure code…
I’m not sure who needs to hear this, but unless you work as a security engineer or in another security-focused tech field, you really shouldn’t be exposing your homelab to the open internet anyway
Most people access their homelabs via VPN - i don’t see anything here that’s a problem for that use-case.
I need to run a VPN already. Fine for desktop, but this isn’t a solution for mobile (where you can’t run two VPNs simultaneously)
Many people host websites ;)
And I would hope those websites are extremely low-risk and not anywhere near essential infrastructure or data ;)
If my server is already open to everyone, what kind of potential attacks do i need to be worried a about? I dont keep personal files on my streaming server, its just videos, music and isos/roms. I dont restrict sign ups, so the idea of an unauthorized user doing something like download a video is a non issue for me really.
I do see where there could be problems for folks running jfin on the same server they keep private photos or for people who charge users for acess, but thats not me.
Am i missing something or is the main result of most of these that a “malicious” actor could dowload files jellyfin has access to without authentication?
I guess the worst thing is that your server starts attacking the US military servers because you’ve become part of a botnet.
That happened to my friend one time when I installed Linux on his computer. He made the username and password the same 4-character word. Got a letter from the DoD.
I dont think they would be so forgiving these days. Especially if you’re brown.
With unrestricted signups, they can obtain their own account easily. With their own account they can enumerate all your other users.
If they have their own account they can just find your instance, make a login, collect all the proof they need that you’re hosting content you don’t own (illegally own) then serve you a court summons and ruin your life.
I wouldn’t worry about the vulnerability in the link since your already wide open. But I wouldn’t leave Jellyfin wide open either. Movie and TV studios are quite litigious.
I hope you’re at least gatekeeping behind a vpn or something.
Edit: typo
Well it’s hosted in The Netherlands and I did take some steps to protect my own identity in regards to registration info, but if the studios did take an interest i’d probably have some fun with it by decaliring bankrupcy and dragging out the appeals.
Can someone ELI5 this for me? I have a jellyfin docker stack set up through dockstarter and managed through portainer. I also own a domain that uses cloudflare to access my Jellyfin server. Since everything is set up through docker, the containers volumes are globally set to only have access to my media storage. Assuming that my setup is insecure, wouldn’t that just mean that “hackers” would only be able to stream free media from my server?
Or you become part of a bonnet and attack your own government’s military. Then you get some very angry knocks on your door and a black back over your face.
And, if you’re brown, probably some electrodes on your genitals until you confess.
If you use normalized paths/file names (through *Arr stacks or docker mounts or otherwise common tools), then the hash that jellyfin sets up when it imports that media can be guessable. If someone was to go and precompile a list of hashes for content that they’re looking for at common paths that people store their files at, they can ask your server for those hashes, and if their list is sufficiently large enough to include the path that you used, your jellyfin instance WILL RESPOND WITHOUT AUTHENTICATION.
I’ve been using this example because it shows how silly this is.
In the context of Sony’s top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child’s play level abuse-able. Risking that something easy like this isn’t being abused by Sony and others (you know… willing to install a rootkit on your computer types…) is a very silly stance to take.
The answer to some of this is that you can just hide the content on a more complicated and less likely to guess path. That will sufficiently change the MD5 hashes enough that you should be more or less unguessable… Instead of using
/mnt/media/movies(or /media/movies, or /movies/, etc…) make the path/mnt/k9RKiQvUwLVCjSqhb2gWTwstgKuDJx59S3J35eFzW2dgSSp84EG7PPAhf2MwCySt/media/movies. (obviously don’t use this one… use a random generator. Make your own.)The real answer should be that Jellyfin requires that all those endpoint need authorization/login. But their answer is “We don’t want to break backwards compatibility. So we won’t.” Which is a bit silly of an answer. Those who use the default installation and organize their content with *arr suites (or with default docker settings/guide settings), are most likely to have guessable MD5 hashes and are most at risk.
Edit: Oh and the other point… if the “response” against this is “well that would take too long, or be too hard. You’d need a lot of money to find all these instances and test them…”. We’re talking about the likes of Sony… The ones that installed rootkits on peoples computers for daring to put a CD into a CD-ROM drive. They’re litigious folk, and will bury you in paper and sue you to oblivion. It’s not a lot of machine time to test a single server. Setting up a couple dozen scanners and just letting it go to find content on it’s own isn’t that bad from a computational standpoint.
And another argument I’ve seen here… “Well if they hack your server then that’s illegal too, can’t make a lawsuit out of that”… Except this is normal web operations. Bots and site scanners aren’t illegal. Nor do they break any authentication mechanism (which is illegal) to do this. Specifically putting this behind authentication would make you correct. But Jellyfin didn’t do that (yet). So guess what. It’s perfectly possible for them to setup a few scanners across a few servers and do this 100% legally.
Security through obscurity isn’t security.
Edit2: Clarification on not using the path I just gave… make up your own random gibberish.
Huh, I can’t check the link right now… But if exposing Jellyfin to the Internet is not an option, then it is not ready to be shipped as the Plex replacement I have heard a lot here and on Reddit.
Put the instance behind another authentication point like a VPN or reverse proxy with SSO. That will prevent the wider Internet from accessing it without legitimate users being cut off. You should be doing this with any server you operate (like Plex), but definitely one that may have legal implications.
I am sorry, I don’t think I follow, I am CGNATED anyway, so I need to use VPNs to access my server (if IPv6 is not available, for IPv4 I am experimenting with Tailscale funnels as of now).
Do we even know that Plex is better? It’s closed source and hasn’t been audited afaik
Agreed. I’m a bit disappointed that it’s being touted as such. If you need a local LAN option, use VLC Player.
It’s a list from 2021 and as a cybersec researcher and Jellyfin user I didn’t see anything that would make me say “do not expose Jellyfin to the Internet”.
That’s not to say there might be something not listed, or some exploit chain using parts of this list, but at least it’s not something that has been abused over the last four years if so.
Agreed, this is a valid list of minor concerns but this is just a fearmongering post. It’s not good that some metadata can leak but if you take normal precautions (i.e. don’t run this next to your classified information storage) it’s fine to open this so your friends can watch media.
Source: me and my Masters degree in cybersecurity (but apparently OP just learned about Kerckhoff’s principle and rainbow tables in a completely incorrect context so I know how to do my job or smth lmao)
Edit: lol don’t look at OPs post history, now I know where the fearmongering came from
It’s nice to read something sane in these threads.
So I have a NAS running Ubuntu I only keep my movies, my Jellyfin, and torrent software on in an isolated VLAN I stream from. I would think this would make any security issue with Jellyfin a dead end. I stream all content from Jellyfin domain I made and never use it locally. I stream off it at home from my VPN. This seems a safe way to stream where it can be used away from home unless I am missing something?
The last set of comments is from 2024. These have not been addressed. The fact that it is possible to stream without auth is just bonkers.
The entirity of jellyfin security is security via obscurity which is zero security at all.
“As a cybersec researcher”, the limp wristed, hand wavy approach to security should be sending up alarm bells. The fact that it doesn’t, means that likely either, you don’t take your research very seriously, or you aren’t a “cybersecurity researcher”.
“Thank you for this list. We are aware of quite a few, but for reasons of backwards compatibility they’ve never been fixed. We’d definitely like to but doing so in a non-disruptive way is the hard part.”
Is truly one of the statements of all time.
How is someone meant to guess what seems to be a randomly generated id? If they try to brute force it then you could probably set up something like fail2ban to block them after a few failed attempts.
I’m not saying video ids shouldn’t require authentication, they should but the risk of someone getting the video id seems fairly low.
It isn’t randomly generated. If you read through you would have known that.
Also, Rainbow tables.
tldr, Rainbow tables are precomputed lists of hashed values used to crack password hashes quickly. Instead of hashing each password guess on the fly, attackers use these tables to reverse hashes and find the original passwords faster, especially for weak or common ones. They’re less effective against hashes protected by a unique salt.
If the ID is the MD5 of the path, rainbow tables are completely useless. You don’t have the hash. You need to derive the hash by guessing the path to an existing file, for each file.
How unique do you suppose file system paths are?
How many hashes would one need to gather to quickly determine the root path for all files? Paths are not random so guessing the path is just a rainbow table.
The scanning for known releases becomes trivial once the file system pattern is known.
If the server is using a standard path prefix and a standard file layout and is using standard file names it isn’t that difficult to find the location of a media file and then from there it would be easier to find bore files, assuming the paths are consistent.
But even for low entropy strings, long strings are difficult to brute force, and rainbow tables are useless for this use case.
I’ve not looked but if the video id is based on its path, then surely the path includes the filename no? You can’t split a hash into its separate original parts, you either guess the entire thing or not. So in that case, the hash is going to challenging to brute force.
It’s not that challenging if you are looking for specific media files, but if you wanted to enumerate the files on a server it’s basically impossible.
You can’t say that a solution is no security at all when it requires time and intelligence to bypass.
It is at least 0.01 security.
Effort or no, if an attacker can reasonably bypass it, it’s not secure. That’s why software gets security patches all the time, why encryption/hashing algorithms can fall out of favor, and why quantum computing can be pretty fucking scary.
I didn’t say it’s secure, I just said it’s security.
You’re hiding behind literal definitions to avoid addressing the functional issue/implications.
This is like when somebody says “no one believes that“ and the other person finds a tweet by one person that believes the thing. The claim isn’t that literally not one person does, it’s that it’s so unusual you may as well act as if nobody does.
Surely you understand how people talk and basic vernacular?
Surely you understand how a stupid response to a silly statement like it is one of the sayings of all time can be appropriate in humorous situations, right?
I understand that you did not find it funny, but I hope that you can understand that it was my intention to be funny, and therefore a serious response is disproportionate.
I thought you were being serious as well. I’ve dealt with enough people who would genuinely make that argument so I assume nothing.
The humorous intent was not obvious.
How about 0.001 security?
Fully agreed. There’s some stuff in the list that could leak server info or metadata about available content to the public, but the rest seems to require some knowledge before being able to exploit it, such as user IDs.
That doesn’t mean these aren’t issues, but they’re not “take your jellyfin down now” type issues either.
Who has the technical wherewithal to run Jellyfin but leaves access on the open web? I get that sharing is part of the point, but no one’s putting their media collection on an open FTP server.
The level of convenience people expect without consequences is astounding. Going to be away for home for a few days? Load stuff onto an external SSD or SD card. Phoning home remotely makes no sense.
Friends, family using Jellyfin is the reason many have it directly available (and not behind VPN for example).
I know people are going to crucify me for this but just fucking use Plex at that point
They jacked their prices, or are about to anyway. If you don’t have a lifetime Plex pass then Plex might not be a viable option. My seedbox provider has been pushing people to Jellyfin for anyone without a Plex pass.
So what’s the alternative? VPNs are unreliable
I think you can IP whitelist who can access it no? That should solve any problems
There is zero (0) chance of an attacker to know and then spoof address of your friend unless you have even bigger problems. Good filter should simply not respond to any packets making very existence of exploitable site undetectable.
Does your friend have a static IP? Unlikely considering that you have to pay extra for a static IP.
Wrong use case, the expected one is friends and family watching stuff on your Jellyfin server from different homes, potentially through mobile, all with dynamic IPs
Then MAC address
@Scary_le_Poo I wouldn’t say never, but in most cases, you’re best served by sticking it behind wireguard- but this is also true of any service or tool you don’t intend to make available to the greater internet
I’m not smart, can you tell me if having it behind a reverse proxy with certs and everything fixes any of these flaws?
Many of the issues are related to unauthenticated requests. Even though your reverse proxy provides SSL, Jellyfin still won’t know the difference between you and a random internet user. So, no, your setup doesn’t mitigate the security risks much at all.
short answer: no, not really
long answer, here’s an analogy that might help:
you go to
https://yourbank.com/and log in with your username and password. you click the button to go to Online Bill Pay, and tell it to send ACME Plumbing $150 because they just fixed a leak under your sink.when you press “Send”, your browser does something like send a POST request to
https://yourbank.com/send-bill-paymentwith a JSON blob like{"account_id": 1234567890, "recipient": "ACME Plumbing", "amount": 150.0}(this is heavily oversimplified, no actual online bank would work like this, but it’s close enough for the analogy)and all that happens over TLS. which means it’s “secure”. but security is not an absolute, things can only be secure with a particular threat model in mind. in the case of TLS, it means that if you were doing this at a coffee shop with an open wifi connection, no one else on the coffeeshop’s wifi would be able to eavesdrop and learn your password.
(if your threat model is instead “someone at the coffeeshop looking over your shoulder while you type in your password”, no amount of TLS will save you from that)
but with the type of vulnerability Jellyfin has, someone else can simply send their own POST request to
https://yourbank.com/send-bill-paymentwith{"account_id": 1234567890, "recipient": "Bob's Shady Plumbing", "amount": 10000.0}. and your bank account will process that as you sending $10k to Bob’s Shady Plumbing.that request is also over TLS, but that doesn’t matter, because that’s security for a different level of the stack. the vulnerability is that you are logged in as account 1234567890, so you should be allowed to send those bill payment requests. random people who aren’t logged in as you should not be able to send bill payments on behalf of account 1234567890.
Not really, no. These are application flaws. Caddy will happily do its job and just let bad actors abuse them. (Unless you mean mTLS certs, then Caddy would only respond to those having a client certificate, which hopefully reduces the number of bad actors to your users😉)
Not unless the reverse proxy adds some layer of authentication as well. Something like HTTP basic auth, or mTLS (AKA 2-way TLS AKA client certificates)
For nginx: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
so if I add a user ”john” with password “mypassword” to video.example.com, you can try adding the login as: “https://john:mypassword@video.example.com”/
Most HTTP clients (e.g. browsers) support adding login like that. I don’t know what other jellyfin clients do that.
The other option is to set up a VPN (I recommend wireguard)
Not unless the reverse proxy adds some layer of authentication as well.
This is correct. However I’d want to add, that this will break EVERY app-based access of jellyfin which defeats the purpose for a lot of people. Adding auth in front of jellyfin will work and allow you to use the web client only.
You kind of touched on it… I wanted to make it clear.
VPN would be a better more interoperable answer for most cases, you’ll still be stuck on devices like WebOS on LG tvs, or roku devices, or others that don’t have the ability to install vpn clients.
This is misinformation. It breaks the web app too.
You can’t use basic auth with jellyfin at all. Its a bug. Jellyfin closed the bug as won’t fix because, it seems, they dont care about security.
