Use a VPN, it's not ideal but it's secure.

I mean I'm sure they'd like to just ship safe code in the first place. But if that's not their expertise and they demonstrate that repeatedly, we gotta take steps ourselves. Secure is obviously best, but I'd rather have insecure Jellyfin behind a VPN than no Jellyfin at all.

It's not this or that. Security comes in layers. So while I would assume that the Jellyfin developers do their best to secure their application, I acknowledge the fact that bugs do exist and that Jellyfin is developed in and for hobbyist contexts, and thus not scrutinised and pentested for vulnerabilities in the way software meant for professional environments would be. Therefore I'll add an extra layer of security by putting it behind a VPN that only whitelisted clients can access. If a vulnerability is detected, I can be sure it hasn't already been exploited to compromise my server because we're all "among friends" there.

The problem here - it's not me who requires access to my library, if someone isn't willing or able to do it, I'm sorry but that's just how it is. People should stop infantilize non-technical people, absolute majority of them is capable of navigating our world without much problems and I'm willing to help them if help is asked.

If my 60 y.o. mother with close to zero technical skills can do it with limited help (due to distance and other constraints) I'm pretty sure that majority of people with sound mind can.

So use a reverse proxy with authentiacation before access to Jellyfin is allowed. I use Caddy forward_auth with Authelia for this. Unless you also want to use the apps without VPN, this works great.

So lets hope this 10.11.7 is not subject to the axios one. :)

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.

You objectively shouldn't expose Jellyfin to the internet. It has a rather large attack surface and isn't designed with security in mind.

Pretending everything is fine won't solve the problem