230

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...

top 50 comments
sorted by: hot top controversial new old
[-] HurlingDurling@lemm.ee 4 points 1 day ago

Honestly, is the problem that they need extra hands to fix these issues?

[-] Saik0Shinigami@lemmy.saik0.com 1 points 22 hours ago* (last edited 22 hours ago)

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.

While I'm sure that some of the answer is in not having dev time to fix it... Their response makes it seem like they're not fully interested in fixing it for other reasons... In the case of this response, "Backwards compatibility".

[-] ipkpjersi@lemmy.ml 15 points 1 day ago* (last edited 1 day ago)

~~Many of these have already been fixed FWIW, it's not a collection of open issues.~~ Nevermind, they have only been closed, not fixed. Yikes.

[-] Saik0Shinigami@lemmy.saik0.com 15 points 1 day ago* (last edited 1 day ago)

No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".

Edit: The biggest issue of unauthenticated streaming of content... https://github.com/jellyfin/jellyfin/issues/13777

Last opened last week. closed as duplicate. it's unaddressed completely.

[-] ipkpjersi@lemmy.ml 1 points 1 day ago

That's really sad. Damn, how disappointing.

[-] easily3667@lemmus.org 2 points 1 day ago

I mean it was closed as a duplicate of the collection, not closed.

[-] ipkpjersi@lemmy.ml 1 points 17 hours ago

I meant it's disappointing that they haven't addressed any of the security issues.

[-] anarchiddy@lemmy.dbzer0.com 44 points 2 days ago

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.

[-] ocean@lemmy.selfhostcat.com 14 points 2 days ago

Many people host websites ;)

[-] anarchiddy@lemmy.dbzer0.com 14 points 2 days ago

And I would hope those websites are extremely low-risk and not anywhere near essential infrastructure or data ;)

load more comments (6 replies)
[-] jagged_circle@feddit.nl 12 points 1 day ago

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

[-] ReversalHatchery@beehaw.org 16 points 2 days ago* (last edited 2 days ago)

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...

[-] jagged_circle@feddit.nl 9 points 1 day ago

There's a bug (closed as won't fix) where proxy basic authentication breaks jellyfin. You can't use it.

[-] easily3667@lemmus.org 21 points 2 days ago

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.

load more comments (4 replies)
[-] troed@fedia.io 103 points 2 days ago

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.

[-] ilega_dh@feddit.nl 43 points 2 days ago* (last edited 2 days ago)

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

load more comments (7 replies)
load more comments (43 replies)
[-] HappyTimeHarry@lemm.ee 14 points 2 days ago

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?

[-] jagged_circle@feddit.nl 12 points 1 day ago* (last edited 1 day ago)

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.

[-] Saik0Shinigami@lemmy.saik0.com 18 points 2 days ago* (last edited 2 days ago)

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

load more comments (5 replies)
[-] kratoz29@lemm.ee 47 points 2 days ago

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.

[-] fmstrat@lemmy.nowsci.com 10 points 1 day ago

The linked post is from 2021. Many of the items were already closed. This looks like fear mongering.

[-] Saik0Shinigami@lemmy.saik0.com 9 points 1 day ago

No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".

[-] t3rmit3@beehaw.org 8 points 2 days ago* (last edited 2 days ago)

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.

load more comments (7 replies)
load more comments (4 replies)
[-] GiuseppeAndTheYeti@midwest.social 12 points 2 days ago

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?

[-] Saik0Shinigami@lemmy.saik0.com 20 points 2 days ago* (last edited 2 days ago)

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.

load more comments (2 replies)
load more comments (3 replies)
load more comments
view more: next ›
this post was submitted on 02 Apr 2025
230 points (100.0% liked)

Technology

38459 readers
654 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 3 years ago
MODERATORS