🚀 Jellyfin Server 10.11.7
We are pleased to announce the latest stable release of Jellyfin, version 10.11.7! This minor release brings several bugfixes to improve your Jellyfin experience. As alway...
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.
Wonder if it’s the Axios one. Sounds like it isn’t from their description though hmm
Axios is a Javascript library and Jellyfin is written in C#.
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.
The web server is in C#. It’s open source lol, I’m looking at the code and there’s no JavaScript.
Look better https://github.com/jellyfin/jellyfin-web
That’s awkward. I didn’t know that was in a separate repo.
deleted by creator
I don’t think so, the previous release 10.11.6 is a few months old and the axios supply chain attack happened yesterday.
So lets hope this 10.11.7 is not subject to the axios one. :)
Diff agrees, not likely. Might be permisson related, elevation of privileges.
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.
deleted by creator
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.
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.