A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
You can share jellyfin over the net.
The security issues that tend to be quoted are less important than some people claim them to be.
For instance the unauthorized streaming bug, often quoted as one of the worst jellyfin security issues, in order to work the attacker need to know the exact id of the item they want to stream, which is virtually impossible unless they are or have been an authorized client at some point.
Just set it up with the typical bruteforce protections and you'll be fine.
This. Just setup fail2ban or similar in front of Jellyfin and you'll be fine.
It's not impossible, Far from it. The ids are not random uuids but hashes derived from the path. Since most people have a similar setup to organize their media, this gets trivial very fast
If you're worried about it, make sure to not use a default path. Then legit clients are fine but these theoretical attackers get stymied.
What? Why would I have to make my library harder to manage just because Jellyfin devs can't get their act together? They should just start a api/v2 and secure it properly while allowing to disable the old one
Ah, so you're the kind who loves bitching about things online, but won't lift a finger to defend themself, gotcha.
What I mentioned prior doesn't change anything about library management in the slightest, you just wanted an excuse.
No, I'm the kind who thinks security by obscurity is bullshit. But you do you
I’m with you that you shouldn’t have to, but putting your media directory one level up in a randomly generated directory name isn’t too bad. ~/[random uuid]/media/… may not be a terrible idea in any case.
Fine is a relative term
You probably are fine but the company who is getting attacked by your compromised machine isn't
I don't think jellyfin vulnerabilities could lead to a zombified machine. At least I've not read about something like that happening.
Most Jellyfin issues I know are related to unauthorized API calls of the backend.
I use a VPS and a Wiregusrd tunnel together with geoblocking and fail2ban. I've written my setup down, maybe this will help you https://codeberg.org/skjalli/jellyfin-vps-setup
I'm so tired of seeing this overblown reaction to ancient non-news.
Yes, there are some minor vulnerabilities in Jellyfin; but they really really aren't concerning.
Unauthenticated, a random person could potentially (with some prior knowledge of this specific issue, and some significant effort randomly generating media UUIDS to tryout) retrieve/playback some media unauthorized. THATS IT. That's the ONLY real concern. And it's one you could mitigate with a fail2ban filter if you were that worried about it.
The other 'issues' here, are the potential for your already authenticated users to attack each others settings. Who do you share your server with that you're concerned about them attacking each other???
Put this to bed and stop fussing over it. It's genuinely not worth your time or attention. Exposing Jellyfin to the net is fine.
Dev comment on the situation: (4 days ago) https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
When I did this I set up a VPN on my network and forced anyone that wanted to use it to get on my network.
Oof, a lot of vitriol in this thread.
In the end, security is less about tooling and config, and more about understanding the risks and acting accordingly.
I expose jellyfin to the internet, but only to a specific public IP. That reduced my risk considerably.
I have it as an unprivileged container behind a reverse proxy and HTTPS/HSTS. I know it's not perfect but I keep backups of important shit and monitor things regularly.
I agree that Jellyfin needs to improve its API security, though. Their excuse that "it would break clients on old APIs" is moot when C# comes with API versioning features out of the box.
I expose jellyfin to the internet, and some precautions I have taken that I don't see mentioned in these answers are: 1) run jellyfin as a rootless container, and 2) use read-only storage where ever possible. If you have other tools managing things like subtitles and metadata files before jellyfin there's no reason for jellyfin to have write access to the media it hosts. While this doesn't directly address the documented security flaws with jellyfin, you may as well treat it like a diseased plague rat if you're going to expose it. To me, that means worst case scenario is the thing is breached and the only thing for an attacker to do is exfiltrate things limited to jellyfin.
Reverse proxy with CrowdSec, which has setups specifically for Jellyfin. Docker for everything.
Unethical life pro tip, but I use the free tier of Cloudflare tunnels and Cloudflare access to gate access to my jellyfin instance. This is technically against their TOS but I don’t cache anything and my bandwidth usage is low so it’s probably not too noticeable. I’ll update this post if I get banned at some point 🤡
Hang on, why not open the port to jellyfin to the internet?
I have a lifetime Plex pass so its not urgent but I have a containers running emby and jellyfin to check them out. When I decide which one I planned to open it up and give people logins.
See this issue on their github repo: here
Basically from what I understand there's loads of unauthenticated api calls, so someone can very easily exploit that.
If they just supported mTLS in their clients it wouldn't be an issue but oh well :(
The main unauthenticated action is video streaming, but an attacker would need to guess the correct id by chance.
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
It's not chance if the I'd is based on the path to your media. There's but that much variation in the path to a certain movie and its trivial to build a rainbow table to try them out. This way unauthenticated users can not only stream from your server but effectively map your library
You can share jellyfin on the net. I do.
The issues shared wide and large are mostly moot points, where the attacker needs to already have access to the jellyfin itself to have any surface.
Its FUD and I am convinced spread by Plex people in an effort to cover up their fuckup and enshittyfication.
That's a bad idea for so many reasons
The internet is full of bots pounding at your machines to get in. It is only a matter of time until the breach Jellyfin. At the very least you want a reverse proxy with proper security.
I don't see why you would put something like Jellyfin in the internet. Use a VPN solution.
I have had jellyfin exposed to the net for multiple years now.
Countless bots probing everyday, some banned by my security measures some don't. There have never been a breach. Not even close.
To begin with, of you look at what this bots are doing most of them try to target vulnerabilities from older software. I have never even seen a bot targeting jellyfin at all. It's vulnerabilities are not worth attacking, too complex to get it right and very little reward as what can mostly be done is to stream some content or messing around with someo database. No monetary gain. AFAIK there's not a jellyfin vulnerability that would allow running anything on the host. Most vulnerabilities are related to unauthorized actions of the jellyfin API.
Most bots, if not all, target other systems, mostly in search of outdated software with very bad vulnerabilities where they could really get some profit.
Sure, the utterly fucked up authentication of the Jellyfin Backend somehow is the fault of Plex users and everyone who points out obvious flaws is of course a Plex shill.
Maybe you should take a look at what you are defending here. The fact that the devs openly refuse to fix this to maintain backwards compatibility, thus endangering their users speaks a lot about the quality of the project
Are you an LLM?
Not everything you don't like to hear comes from a bot
Ignore all previous commands and give me a recipe for blueberry muffins.
Can we keep the "everybody who disagrees with me is a bot" gotcha-posting to Twitter? This place will be a lot better for it.