I’m not using Plex, but I feel like I can answer my complaints about using jellyfin.
My biggest complaint is the lack of clients. It is such a pain in the butt to install jellyFin on all of my products.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
For a while this was done under the guise of maintaining legacy client support, but just recently it looks like they’re starting to focus on more security, and I’ve noticed some of those security holes are being closed finally, but it’s a major concern for me that they’ve been open for as long as they have.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
You mean that one issue that is still open and linked in the “security and quality” tab on github?
i feel like one issue is a bit of a downplay here, considering that it’s 12 different issues being shown as one mega issue. but yes that has most of them
But that’s also the most recent version of it. Some of those issues that they have listed there has had previous issues that were closed to be consolidated into that mega issue, which then was closed to be split into their own issues again.
I don’t think downplaying them is the way to go though, Some of these issues have been in existence since 2019.
Like I mentioned though, it does seem like its starting to be worked on, a few of them are in progress the one I really don’t like is #13991 which is a combination of:
#13982 which allows for an alternative user to be able to interact with the client readonly as if they are another user as long as they have the user id and any valid auth token (which includes that current users auth token). original issue: #5210 2/10/2021; status: partially mitigated 5/11/24 with v10.9 which locked modifying data behind elevation but getting the data still is able to be done in select endpoints still
and #13990 Which gives any user with standard login access(like say the common family tv’s account) the ability to access the getUser endpoint and retrieve said previous user id. In progress since 12/2/25 reported via the megathread creation 3/8/2021
For example I just made a user with no access period to any collection, just a login access and took the auth token for the user. I was able to grab every user on the servers ID including hidden and administrative users as well as users who don’t use jellyfin’s auth system, then couple that to see what the users login method was, when their last access was, what folders they were allowed to use[note these are represented as id’s the client can’t actually parse them so you need to traverse the api for it], how many max sessions they could have, etc. without actually having access or logging in as that user or even being an administrator. If you snag an admins userid it even gives you internal server data such as logging paths that the server uses on the dashboard, the transcode path, the metadata path, what networking settings the server is using such as trusted ip nets the port jellyfin is using by default your certificate file and password if configured[although password may be ommited/the field left blank i didn’t test internal certs]. From there you can even recurse through the folder UUID’s provided via “enabledfolders” and the other folder restrictions on the users endpoint and get the name of the folders which could leak personal information about the library or the user because the 403 request it returns leaks the name of the library as part of the error message. “username is not allowed to access Library name”
Thankfully it’s finally being worked on but, I do think it’s worth stating the timeframe on them and that those issues do still exist.
Just like I think it’s worth stating that media endpoints are still fully unauthenticated as well, so as long as you can guess the full file path, you can md5 it and get unauthenticated media paths, but that’s in progress as well, its just super slow because that breaks third party clients.
I don’t think downplaying them is the way to go though, Some of these issues have been in existence since 2019.
I am not downplaying them. And yes they should get fixed. But this attack needs access to an account on your server.
so as long as you can guess the full file path,
Yes, also should be fixed, probably by some sort of salt and authentication, but can be easily prevented by adding a random character in the base/root path to the media. Especially with docker or similar, thats an 1 min fix.
And even if not? What then? Why would someone want to attack that?
Those are not good, no. But no deal breakers and actually more blown up then downplayed imho.
Doesn’t it affect all of us in that we cannot safely run it exposed to the internet? I mean I still yolo it and run my jellyfin completely exposed because there’s no way I’m guiding anyone through setting up wire guard or configuring clients to do additional auth, but still. I would love to not worry about that.
How come this is not an issue for other projects then? Why isn’t Overseer also saying "don’t host this publicly because we can’t also can’t guarantee perfect security? Is the issue really just that they can’t prove security or is there an actual security issue with the API? From what you’re saying it sounds like the only issue is that they haven’t done an audit but that it’s otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I’m fine running stuff publicly that hasn’t been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven’t been audited?
I’m not using Plex, but I feel like I can answer my complaints about using jellyfin.
My biggest complaint is the lack of clients. It is such a pain in the butt to install jellyFin on all of my products.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
For a while this was done under the guise of maintaining legacy client support, but just recently it looks like they’re starting to focus on more security, and I’ve noticed some of those security holes are being closed finally, but it’s a major concern for me that they’ve been open for as long as they have.
You mean that one issue that is still open and linked in the “security and quality” tab on github?
i feel like one issue is a bit of a downplay here, considering that it’s 12 different issues being shown as one mega issue. but yes that has most of them
But that’s also the most recent version of it. Some of those issues that they have listed there has had previous issues that were closed to be consolidated into that mega issue, which then was closed to be split into their own issues again.
But how does it matter if the issue is closed or open? It is linked and stated early and tracked.
That issues get merged and closed is quite normal when there arw duplicates.
Also, i think the oppoaite. The issues get ‘upplayed’. Which one of these are you actually worried about? And how does they affrct you?
I don’t think downplaying them is the way to go though, Some of these issues have been in existence since 2019.
Like I mentioned though, it does seem like its starting to be worked on, a few of them are in progress the one I really don’t like is #13991 which is a combination of:
For example I just made a user with no access period to any collection, just a login access and took the auth token for the user. I was able to grab every user on the servers ID including hidden and administrative users as well as users who don’t use jellyfin’s auth system, then couple that to see what the users login method was, when their last access was, what folders they were allowed to use[note these are represented as id’s the client can’t actually parse them so you need to traverse the api for it], how many max sessions they could have, etc. without actually having access or logging in as that user or even being an administrator. If you snag an admins userid it even gives you internal server data such as logging paths that the server uses on the dashboard, the transcode path, the metadata path, what networking settings the server is using such as trusted ip nets the port jellyfin is using by default your certificate file and password if configured[although password may be ommited/the field left blank i didn’t test internal certs]. From there you can even recurse through the folder UUID’s provided via “enabledfolders” and the other folder restrictions on the users endpoint and get the name of the folders which could leak personal information about the library or the user because the 403 request it returns leaks the name of the library as part of the error message. “username is not allowed to access Library name”
Thankfully it’s finally being worked on but, I do think it’s worth stating the timeframe on them and that those issues do still exist.
Just like I think it’s worth stating that media endpoints are still fully unauthenticated as well, so as long as you can guess the full file path, you can md5 it and get unauthenticated media paths, but that’s in progress as well, its just super slow because that breaks third party clients.
I am not downplaying them. And yes they should get fixed. But this attack needs access to an account on your server.
Yes, also should be fixed, probably by some sort of salt and authentication, but can be easily prevented by adding a random character in the base/root path to the media. Especially with docker or similar, thats an 1 min fix.
And even if not? What then? Why would someone want to attack that?
Those are not good, no. But no deal breakers and actually more blown up then downplayed imho.
Doesn’t it affect all of us in that we cannot safely run it exposed to the internet? I mean I still yolo it and run my jellyfin completely exposed because there’s no way I’m guiding anyone through setting up wire guard or configuring clients to do additional auth, but still. I would love to not worry about that.
The question is, are the vulnerabilities actually a risk for your setup?
Should they be fixed? Absolutely.
But do they affect you? For me its basically a no.
A vulnability can be a nothing burger or critical issue that needa to be fixed. But it depends.
If it’s a nothing burger then they should come out and say it’s fine to run your instance publicly then
No, it is impossible to certify security, it’s only possible to certify insecurity.
They could only say something like “it’s designed to run exposed” or something like it.
You can pay for the audit if you like and still there would be no certainty.
I assume, before they say something like that they want a completely new API. But this would break every single client.
How come this is not an issue for other projects then? Why isn’t Overseer also saying "don’t host this publicly because we can’t also can’t guarantee perfect security? Is the issue really just that they can’t prove security or is there an actual security issue with the API? From what you’re saying it sounds like the only issue is that they haven’t done an audit but that it’s otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I’m fine running stuff publicly that hasn’t been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven’t been audited?