Your comment got me looking through the jellyfin github issues. Are the bugs listed for unauthenticated endpoints what you’re referencing? It looks like the 7 open mention being able to view information about the jellyfin instance or view the media itself. But this is just what was commented as possible, there could be more possibilities especially if combined with other vulnerabilities.

Now realizing there are parts of Jellyfin that are known to be accessible without authentication, I’m thinking Fail2ban is going to do less but unless there are ways to do injection with the known bugs/a new 0day they will still need to brute force a password to be able to make changes. I’m curious if there is anything I’m overlooking.

It feels like everything is a tradeoff and I think a setup like this reduces the complexity for people you share with.

If you added fail2ban along with alert email/notifications you could have a chance to react if you were ever targeted for a brute force attempt. Jellyfin docs talk about setting this up for anyone interested.

Blocking IP segments based on geography of countries you don’t expect connections from adds the cost of a VPN for malicious actors in those areas.

Giving Jellyfin its own VLAN on your network could help limit exposure to your other services and devices if you experience a 0day or are otherwise compromised.