this post was submitted on 23 May 2026
182 points (96.9% liked)

Selfhosted

56957 readers
1345 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. 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!

founded 3 years ago
MODERATORS
 

Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?

you are viewing a single comment's thread
view the rest of the comments
[–] Flatfire@lemmy.ca 4 points 1 day ago (1 children)

Jokes on them, my paths are a shitshow and I can't be bothered to organize them properly

[–] BakedCatboy@lemmy.ml 3 points 1 day ago* (last edited 1 day ago) (1 children)

Do you not do any renaming? That probably would make it even easier as you can just brute force with a database of filenames scraped from torrents. I already have a proof of concept that generates valid jellyfin IDs from any given file path, it only takes a few more steps before you can plug in a shodan scan of jellyfin instances and just shotgun a bunch of IDs generated from torrents.csv at them and find stuff you can stream without authentication.

People not bothering to rename, using the default radarr naming scheme, or everyone using the same naming pattern from trash guides just makes it easier.

Probably the only way to guarantee nobody can probe your media and stream it without authentication is to make sure to rename everything using a format that only you use or mount all your media under a path inside docker that contains a long randomly generated folder prefix.

[–] Flatfire@lemmy.ca 1 points 1 day ago (1 children)

I was mostly making the comment in jest. I do rename, but my folder structures, as someone who downloads everything manually based on what I want to watch rather than doing the automated *arr stuff leaves it in directories only I consider sensible.

I have Jellyfin behind a reverse proxy that lives in a DMZ and a WAF to go with it. I'm sure there's still room for watching an unauthenticated stream because I forgot to rename a folder somewhere, but it's not exactly an attack vector I care about. I'm more concerned about DDoS or impersonation attacks, which I also attempt to mitigate via an LDAP implementation behind the scenes.

It's not perfect, but it's the best effort I can make at the moment.

[–] BakedCatboy@lemmy.ml 1 points 19 hours ago

Yeah that's fair and I think that's a good move, my point is just that people are acting like this is not feasible to exploit. I'm at the point in my exploit testing excursion where I have a script that can generate a stream of potential IDs based on real torrent names being parsed and reformatted using radarr's default naming pattern as well as the commonly used trash guides ones permuted with some common library paths used in the default docker compose examples, and it's turning up actual ID matches with my jellyfin instance. All I have left to do is make it create API requests to test the IDs against the unauthenticated API instead of checking an exported list and there's a proof of concept. 5 years is a long time for someone to figure that out.