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 am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.
Is this ok? No. But to fix this, every Client would be broken.
The current API dies not follow modern security practices since some are not or partially autheticated.
Thats basically inherited by Emby.
That is the current main issue and needs to be dealt with.
I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.
Also overseer is also not saying “pls host on the public internet”. If you do so, you are on your own.
Why jellyfin gets treaded different? I do not know.
EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. “But it is insecure… so i can not set it up”
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don’t think breaking clients is an excuse not to at least get started putting forward a date, even if it’s a year in the future, where clients need to be updated by. Sure Overseeer isn’t begging people to put it on the internet, but there aren’t any known vulnerabilities to my knowledge, same with vaultwarden. Imo it’s a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there’s Plex drama, it seems like the list of reasons people don’t want to spend time to migrate isn’t getting whittled down much. I’ve donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There’s nothing that jellyfin can’t technically do that I find missing, but it feels like a death by a thousand cuts.
Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.
The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.
As I said, the issue is not that big, and mainly an excuse for most ppl.
The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.
But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.
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?
I am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.
Is this ok? No. But to fix this, every Client would be broken.
The current API dies not follow modern security practices since some are not or partially autheticated. Thats basically inherited by Emby.
That is the current main issue and needs to be dealt with.
I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.
Also overseer is also not saying “pls host on the public internet”. If you do so, you are on your own. Why jellyfin gets treaded different? I do not know.
EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. “But it is insecure… so i can not set it up”
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don’t think breaking clients is an excuse not to at least get started putting forward a date, even if it’s a year in the future, where clients need to be updated by. Sure Overseeer isn’t begging people to put it on the internet, but there aren’t any known vulnerabilities to my knowledge, same with vaultwarden. Imo it’s a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there’s Plex drama, it seems like the list of reasons people don’t want to spend time to migrate isn’t getting whittled down much. I’ve donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There’s nothing that jellyfin can’t technically do that I find missing, but it feels like a death by a thousand cuts.
Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.
The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.
As I said, the issue is not that big, and mainly an excuse for most ppl. The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.
But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.