I don't know who needs to hear this, but DO NOT EVER expose Jellyfin to the internet
Collection of potential security issues in Jellyfin This is a non exhaustive list of potential security issues found in Jellyfin. Some of these might cause controversy. Some of these are design fla...
like this
walden
in reply to Scary le Poo • • •like this
TVA likes this.
Mark
in reply to walden • •like this
TVA likes this.
Technology reshared this.
Mora
in reply to walden • • •like this
TVA likes this.
beek
in reply to walden • • •like this
TVA likes this.
Zozano
in reply to walden • • •I'm also an absolute dumbfuck. And I can confidently tell you, as a matter of fact, that I don't know.
I'm running SWAG reverse proxy, my DNS is not tunneled, I share my Jellyfin with others outside my network.
My primary concern is my server gets hacked, or I get charged with distributing 'public domain movies'
like this
TVA and SaltySalamander like this.
HM King Charles III DG FD
in reply to Zozano • • •Hacking, even on an insecure system, would be illegal. Any copyright troll trying to sue a single user for having a private jellyfin instance which they hacked to find out about would probably have a hard time actually making a case.
"Yeah, this one guy was distributing films to himself and a few friends. I know because I hacked him" doesn't seem like a good case.
https://links.rocks/u/paperemail
in reply to walden • • •Not unless the reverse proxy adds some layer of authentication as well. Something like HTTP basic auth, or mTLS (AKA 2-way TLS AKA client certificates)
For nginx: docs.nginx.com/nginx/admin-gui…
so if I add a user ”john” with password “mypassword” to video.example.com, you can try adding the login as: “https://john:mypassword@video.example.com”
Most HTTP clients (e.g. browsers) support adding login like that. I don’t know what other jellyfin clients do that.
The other option is to set up a VPN (I recommend wireguard)
Restricting Access with HTTP Basic Authentication
docs.nginx.comlike this
TVA likes this.
jagged_circle
in reply to • • •You can't do that with jellyfin.
Basic auth doesn't work with jellyfin. Its a bug. Enable it on your reverse proxy, and jellyfin breaks. Devs closed it as wontfix
spit_evil_olive_tips
in reply to walden • • •short answer: no, not really
long answer, here's an analogy that might help:
you go to
https://yourbank.comand log in with your username and password. you click the button to go to Online Bill Pay, and tell it to send ACME Plumbing $150 because they just fixed a leak under your sink.when you press "Send", your browser does something like send a POST request to
https://yourbank.com/send-bill-paymentwith a JSON blob like{"account_id": 1234567890, "recipient": "ACME Plumbing", "amount": 150.0}(this is heavily oversimplified, no actual online bank would work like this, but it's close enough for the analogy)and all that happens over TLS. which means it's "secure". but security is not an absolute, things can only be secure with a particular threat model in mind. in the case of TLS, it means that if you were doing this at a coffee shop with an open wifi connection, no one else on the coffeeshop's wifi would be able to eavesdrop and learn your password.
(if your threat model is instead "someone at
... Show more...short answer: no, not really
long answer, here's an analogy that might help:
you go to
https://yourbank.comand log in with your username and password. you click the button to go to Online Bill Pay, and tell it to send ACME Plumbing $150 because they just fixed a leak under your sink.when you press "Send", your browser does something like send a POST request to
https://yourbank.com/send-bill-paymentwith a JSON blob like{"account_id": 1234567890, "recipient": "ACME Plumbing", "amount": 150.0}(this is heavily oversimplified, no actual online bank would work like this, but it's close enough for the analogy)and all that happens over TLS. which means it's "secure". but security is not an absolute, things can only be secure with a particular threat model in mind. in the case of TLS, it means that if you were doing this at a coffee shop with an open wifi connection, no one else on the coffeeshop's wifi would be able to eavesdrop and learn your password.
(if your threat model is instead "someone at the coffeeshop looking over your shoulder while you type in your password", no amount of TLS will save you from that)
but with the type of vulnerability Jellyfin has, someone else can simply send their own POST request to
https://yourbank.com/send-bill-paymentwith{"account_id": 1234567890, "recipient": "Bob's Shady Plumbing", "amount": 10000.0}. and your bank account will process that as you sending $10k to Bob's Shady Plumbing.that request is also over TLS, but that doesn't matter, because that's security for a different level of the stack. the vulnerability is that you are logged in as account 1234567890, so you should be allowed to send those bill payment requests. random people who aren't logged in as you should not be able to send bill payments on behalf of account 1234567890.
troed
in reply to Scary le Poo • • •It's a list from 2021 and as a cybersec researcher and Jellyfin user I didn't see anything that would make me say "do not expose Jellyfin to the Internet".
That's not to say there might be something not listed, or some exploit chain using parts of this list, but at least it's not something that has been abused over the last four years if so.
like this
SaltySalamander and bizarroland like this.
Scary le Poo
in reply to troed • • •The last set of comments is from 2024. These have not been addressed. The fact that it is possible to stream without auth is just bonkers.
The entirity of jellyfin security is security via obscurity which is zero security at all.
"As a cybersec researcher", the limp wristed, hand wavy approach to security should be sending up alarm bells. The fact that it doesn't, means that likely either, you don't take your research very seriously, or you aren't a "cybersecurity researcher".
"Thank you for this list. We are aware of quite a few, but for reasons of backwards compatibility they've never been fixed. We'd definitely like to but doing so in a non-disruptive way is the hard part."
Is truly one of the statements of all time.
like this
TVA and bizarroland like this.
bizarroland
in reply to Scary le Poo • • •You can't say that a solution is no security at all when it requires time and intelligence to bypass.
It is at least 0.01 security.
whats_all_this_then
in reply to bizarroland • • •like this
bizarroland and TVA like this.
bizarroland
in reply to whats_all_this_then • • •LandedGentry
in reply to bizarroland • • •asdfsadfsadf
:::
like this
TVA likes this.
bizarroland
in reply to LandedGentry • • •Surely you understand how a stupid response to a silly statement like it is one of the sayings of all time can be appropriate in humorous situations, right?
I understand that you did not find it funny, but I hope that you can understand that it was my intention to be funny, and therefore a serious response is disproportionate.
LandedGentry
in reply to bizarroland • • •asdfsadfsadf
:::
bizarroland
in reply to LandedGentry • • •Kusimulkku
in reply to LandedGentry • • •like this
bizarroland likes this.
LandedGentry
in reply to Kusimulkku • • •asdfsadfsadf
:::
whats_all_this_then
in reply to bizarroland • • •B0rax
in reply to whats_all_this_then • • •like this
bizarroland likes this.
Scary le Poo
in reply to B0rax • • •TVA likes this.
B0rax
in reply to Scary le Poo • • •Link
in reply to Scary le Poo • • •How is someone meant to guess what seems to be a randomly generated id? If they try to brute force it then you could probably set up something like fail2ban to block them after a few failed attempts.
I’m not saying video ids shouldn’t require authentication, they should but the risk of someone getting the video id seems fairly low.
Scary le Poo
in reply to Link • • •It isn't randomly generated. If you read through you would have known that.
Also, Rainbow tables.
tldr, Rainbow tables are precomputed lists of hashed values used to crack password hashes quickly. Instead of hashing each password guess on the fly, attackers use these tables to reverse hashes and find the original passwords faster, especially for weak or common ones. They're less effective against hashes protected by a unique salt.
like this
TVA likes this.
i_am_not_a_robot
in reply to Scary le Poo • • •like this
bizarroland likes this.
Clent
in reply to i_am_not_a_robot • • •How unique do you suppose file system paths are?
How many hashes would one need to gather to quickly determine the root path for all files? Paths are not random so guessing the path is just a rainbow table.
The scanning for known releases becomes trivial once the file system pattern is known.
TVA likes this.
lazynooblet
in reply to Clent • • •like this
bizarroland likes this.
i_am_not_a_robot
in reply to lazynooblet • • •like this
bizarroland likes this.
i_am_not_a_robot
in reply to Clent • • •If the server is using a standard path prefix and a standard file layout and is using standard file names it isn't that difficult to find the location of a media file and then from there it would be easier to find bore files, assuming the paths are consistent.
But even for low entropy strings, long strings are difficult to brute force, and rainbow tables are useless for this use case.
deadcade
in reply to troed • • •Fully agreed. There's some stuff in the list that could leak server info or metadata about available content to the public, but the rest seems to require some knowledge before being able to exploit it, such as user IDs.
That doesn't mean these aren't issues, but they're not "take your jellyfin down now" type issues either.
ilega_dh
in reply to troed • • •Agreed, this is a valid list of minor concerns but this is just a fearmongering post. It’s not good that some metadata can leak but if you take normal precautions (i.e. don’t run this next to your classified information storage) it’s fine to open this so your friends can watch media.
Source: me and my Masters degree in cybersecurity (but apparently OP just learned about Kerckhoff’s principle and rainbow tables in a completely incorrect context so I know how to do my job or smth lmao)
Edit: lol don’t look at OPs post history, now I know where the fearmongering came from
like this
troed likes this.
Domi
in reply to ilega_dh • • •https://lemmy.saik0.com/u/Saik0Shinigami
in reply to ilega_dh • • •Source: R1 masters professor. Literally the person you would have needed to take the class from on the topic at my institution.
This is a problem simply because most paths and names will be similar due to *arr suites and docker mounts normalizing them to a standard that jellyfin wants to see. In the context of Sony's top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child's play level abuse-able. Risking that something easy like this isn't being abused by Sony and others (you know... willing to install a rootkit on your computer types...) is a very silly stance to take.
The hash that's used t
... Show more...Source: R1 masters professor. Literally the person you would have needed to take the class from on the topic at my institution.
This is a problem simply because most paths and names will be similar due to *arr suites and docker mounts normalizing them to a standard that jellyfin wants to see. In the context of Sony's top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child's play level abuse-able. Risking that something easy like this isn't being abused by Sony and others (you know... willing to install a rootkit on your computer types...) is a very silly stance to take.
The hash that's used to represent the path isn't salted or otherwise unique.
Edit: mobile typos.
Dempf
in reply to • • •ReversalHatchery
in reply to ilega_dh • • •oh yeah I'm pretty sure the majority of users bought a dedicated machine for Jellyfin
Appoxo
in reply to ReversalHatchery • • •ReversalHatchery
in reply to Appoxo • • •fmstrat
in reply to troed • • •KairuByte
in reply to fmstrat • • •LandedGentry
in reply to Scary le Poo • • •Powderhorn
in reply to Scary le Poo • • •Who has the technical wherewithal to run Jellyfin but leaves access on the open web? I get that sharing is part of the point, but no one's putting their media collection on an open FTP server.
The level of convenience people expect without consequences is astounding. Going to be away for home for a few days? Load stuff onto an external SSD or SD card. Phoning home remotely makes no sense.
LandedGentry
in reply to Powderhorn • • •asdfsadfsadf
:::
like this
TVA likes this.
PolarisFx
in reply to LandedGentry • • •LandedGentry
in reply to PolarisFx • • •asdfsadfsadf
:::
like this
TVA likes this.
PolarisFx
in reply to LandedGentry • • •like this
TVA likes this.
LandedGentry
in reply to PolarisFx • • •asdfsadfsadf
:::
like this
TVA likes this.
HM King Charles III DG FD
in reply to LandedGentry • • •LandedGentry
in reply to HM King Charles III DG FD • • •asdfsadfsadf
:::
TVA likes this.
ReversalHatchery
in reply to LandedGentry • • •LandedGentry
in reply to ReversalHatchery • • •asdfsadfsadf
:::
ReversalHatchery
in reply to LandedGentry • • •I'm not exposing jellyfin, but for sure I wouldn't let my plex server even see the internet (I bet iy wouldn't even work that way).
jellyfin is perfectly accessible everywhere it needs to be. been using a VPN on my phone for ages for all traffic.
Kusimulkku
in reply to Powderhorn • • •Waryle
in reply to Powderhorn • • •My Jellyfin server is behind Cloudflare with IP outside of my country banned.
I got Crowdsec set up on Cloudflare, Traefik and Debian directly.
I got Jellyfin up in a docker container behind Traefik, my router opens only 80 and 443 ports and direct them to Traefik.
Jellyfin has only access to my media files which are just downloaded movies and shows hardlinked by Sonarr/Radarr from my download folder.
It is publicly exposed to be able to watch it from anywhere, and share it to family and friends.
So what? They might access the movies, even delete them, I don't care, I'll just hardlink them back or re-download them. What harm can they do that would justify locking everything down?
Omgboom
in reply to Powderhorn • • •You would be very wrong about that. You can even search open FTP servers using Google
palined.com/search/
google.com/search?q=%2B%28.mkv…)%20+Superman%20+intitle:%22index%20of%22%20-inurl:(jsp|pl|php|html|aspx|htm|cf|shtml)%20-inurl:(hypem|unknownsecret|sirens|writeups|trimediacentral|articlescentral|listen77|mp3raid|mp3toss|mp3drug|theindexof|index_of|wallywashis|indexofmp3)
Google Open Directory Search
palined.comlike this
TVA likes this.
Powderhorn
in reply to Omgboom • • •jarfil
in reply to Powderhorn • • •The typical guides for installing Jellyfin and friends, stop at the point where you can access the service, expecting you to secure it further.
Turns out, the default configuration for many (most) routers, is to allow external access to anything a local service will request it to allow, expecting you to secure it further.
Leaving it like that, is an explosive combo, which many users never intended to set up, but have nonetheless.
kratoz29
in reply to Scary le Poo • • •like this
TVA likes this.
P03 Locke
in reply to kratoz29 • • •like this
TVA likes this.
Chastity2323
in reply to kratoz29 • • •https://lemmy.saik0.com/u/Saik0Shinigami
in reply to Chastity2323 • • •Yes... because you can take the raw request your browser makes... remove your auth cookie and replay the same request and it fails.
Closed source doesn't mean that it can't be tested for problems. Just means that you can't go to the code to understand why it's a problem. You can still see that the problem exists (or doesn't in this case).
Edit: I haven't tested every api endpoint myself... but for video files it doesn't work. It's not vulnerable to the same thing that JF is in that specific case.
like this
TVA likes this.
kratoz29
in reply to Chastity2323 • • •It is if you have compared them together.
I haven't recently thought and I am a lifetime Plex pass user (we will see what lifetime truly means sooner or later) and I have still been unaffected by most of the changes Plex has done (watch together is the 1st valuable feature that I have lost), so if you can't expose Jellyfin then it is not better than Plex for me.
like this
TVA likes this.
t3rmit3
in reply to kratoz29 • • •ReversalHatchery
in reply to t3rmit3 • • •aaaand now you smart tv can't connect. none of them. the clients dont even support http basic auth creds put into the URL for some crazy reason.
for advanced HTTP-level authentication you would need to run a reverse proxy on the TV's network that would add the authentication info.
for the VPN idea you would need to tunnel the TV's network's internet connection at the router. or set up a gateway address in the TVs network settings that would do that. or use a reverse proxy here too so that it repeats the request to the real server.
but honestly, this is the real and only secure way anyway. I wouldn't be comfortable to expose jellyfin even if the devs are real experts. I mean vulns get discovered, in dotnet, jellyfin dependencies, linux filesystem, and reverse proxy, and honestly who has time to always tightly keep up to date with all that.
that's not to discount the seriousness of the issue though, it's a real shame that jellyfin is so much against security
like this
TVA likes this.
t3rmit3
in reply to ReversalHatchery • • •ReversalHatchery
in reply to t3rmit3 • • •often, but not always. sometimes the TV is at a different house, when you are a guest or at a second property
t3rmit3
in reply to ReversalHatchery • • •kratoz29
in reply to t3rmit3 • • •t3rmit3
in reply to kratoz29 • • •fmstrat
in reply to kratoz29 • • •tensei
in reply to Scary le Poo • • •𝓔𝓶𝓶𝓲𝓮
in reply to Scary le Poo • • •I think you can IP whitelist who can access it no? That should solve any problems
There is zero (0) chance of an attacker to know and then spoof address of your friend unless you have even bigger problems. Good filter should simply not respond to any packets making very existence of exploitable site undetectable.
Scary le Poo
in reply to 𝓔𝓶𝓶𝓲𝓮 • • •Mark doesn't like this.
Mark
in reply to Scary le Poo • •Technology reshared this.
BCsven
in reply to Scary le Poo • • •You can pay for true static, but I have probably had the same IP for 5 years, and same with the modem/routerbeforre this one.
like this
Mark likes this.
jherazob
in reply to 𝓔𝓶𝓶𝓲𝓮 • • •like this
TVA likes this.
𝓔𝓶𝓶𝓲𝓮
in reply to jherazob • • •unbuckled
in reply to jherazob • • •ReversalHatchery
in reply to unbuckled • • •TVA likes this.
unbuckled
in reply to ReversalHatchery • • •ReversalHatchery
in reply to unbuckled • • •HM King Charles III DG FD
in reply to Scary le Poo • • •unbuckled
in reply to HM King Charles III DG FD • • •HM King Charles III DG FD
in reply to unbuckled • • •natch
in reply to HM King Charles III DG FD • • •You can always funnel all your VPN traffic through a more typical port, like 80, and there's very little anyone can do to distinguish between your traffic and typical web traffic.
If your ISP causes issues with inbound traffic to your home network, just add another link to the chain to include a cloud-hosted server, or host it all entirely in the cloud (if you find a trustworthy one with a reasonable cost).
ReversalHatchery
in reply to HM King Charles III DG FD • • •LandedGentry
Unknown parent • • •asdfsadfsadf
:::
LandedGentry
Unknown parent • • •asdfsadfsadf
:::
anarchiddy
in reply to Scary le Poo • • •I'm not sure who needs to hear this, but unless you work as a security engineer or in another security-focused tech field, you really shouldn't be exposing your homelab to the open internet anyway
Most people access their homelabs via VPN - i don't see anything here that's a problem for that use-case.
like this
TVA likes this.
ocean
in reply to anarchiddy • • •like this
TVA likes this.
anarchiddy
in reply to ocean • • •jagged_circle
in reply to anarchiddy • • •Hareen
in reply to jagged_circle • • •jagged_circle
in reply to Hareen • • •Can you order the wireguard connections?
Eg I want my connections to my home server VPN to first go through my mullvad VPN. Because I dont want any connections coming out of my device that don't go through a shared VPN or Tor.
mic_check_one_two
in reply to jagged_circle • • •LandedGentry
Unknown parent • • •asdfsadfsadf
:::
LandedGentry
Unknown parent • • •asdfsadfsadf
:::
GiuseppeAndTheYeti
in reply to Scary le Poo • • •https://lemmy.saik0.com/u/Saik0Shinigami
in reply to GiuseppeAndTheYeti • • •If you use normalized paths/file names (through *Arr stacks or docker mounts or otherwise common tools), then the hash that jellyfin sets up when it imports that media can be guessable. If someone was to go and precompile a list of hashes for content that they're looking for at common paths that people store their files at, they can ask your server for those hashes, and if their list is sufficiently large enough to include the path that you used, your jellyfin instance WILL RESPOND WITHOUT AUTHENTICATION.
I've been using this example because it shows how silly this is.
In the context of Sony’s top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albei
... Show more...If you use normalized paths/file names (through *Arr stacks or docker mounts or otherwise common tools), then the hash that jellyfin sets up when it imports that media can be guessable. If someone was to go and precompile a list of hashes for content that they're looking for at common paths that people store their files at, they can ask your server for those hashes, and if their list is sufficiently large enough to include the path that you used, your jellyfin instance WILL RESPOND WITHOUT AUTHENTICATION.
I've been using this example because it shows how silly this is.
In the context of Sony’s top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child’s play level abuse-able. Risking that something easy like this isn’t being abused by Sony and others (you know… willing to install a rootkit on your computer types…) is a very silly stance to take.
The answer to some of this is that you can just hide the content on a more complicated and less likely to guess path. That will sufficiently change the MD5 hashes enough that you should be more or less unguessable... Instead of using
/mnt/media/movies(or /media/movies, or /movies/, etc...) make the path/mnt/k9RKiQvUwLVCjSqhb2gWTwstgKuDJx59S3J35eFzW2dgSSp84EG7PPAhf2MwCySt/media/movies. (obviously don't use this one... use a random generator. Make your own.)The real answer should be that Jellyfin requires that all those endpoint need authorization/login. But their answer is "We don't want to break backwards compatibility. So we won't." Which is a bit silly of an answer. Those who use the default installation and organize their content with *arr suites (or with default docker settings/guide settings), are most likely to have guessable MD5 hashes and are most at risk.
Edit: Oh and the other point... if the "response" against this is "well that would take too long, or be too hard. You'd need a lot of money to find all these instances and test them...". We're talking about the likes of Sony... The ones that installed rootkits on peoples computers for daring to put a CD into a CD-ROM drive. They're litigious folk, and will bury you in paper and sue you to oblivion. It's not a lot of machine time to test a single server. Setting up a couple dozen scanners and just letting it go to find content on it's own isn't that bad from a computational standpoint.
And another argument I've seen here...
"Well if they hack your server then that's illegal too, can't make a lawsuit out of that"... Except this is normal web operations. Bots and site scanners aren't illegal. Nor do they break any authentication mechanism (which is illegal) to do this. Specifically putting this behind authentication would make you correct. But Jellyfin didn't do that (yet). So guess what. It's perfectly possible for them to setup a few scanners across a few servers and do this 100% legally.
Security through obscurity isn't security.
Edit2: Clarification on not using the path I just gave... make up your own random gibberish.
GiuseppeAndTheYeti
in reply to • • •I think I understand now. Thank you! I will be changing my paths then. It's kind of a moot point since I'll change my paths anyway, but for the sake of my own curiosity, i have a follow up question. Feel free to disregard it if you don't feel like taking the time to answer.
Hypothetically, my docker setup only allows jellyfin to see /mnt/user as /storage. So jellyfin would report the path to Morbius as being:
/storage/hdd1/media/movies/Morbius_all_morbed_up.mkv
when in all actuality it would be:
/mnt/user/hdd1/media/movies/Morbius_all_morbed_up.mkv
My intuition tells me that the file path that jellyfin "sees" would be the security risk. So "/storage/hdd1/...." Is that correct?
jagged_circle
in reply to GiuseppeAndTheYeti • • •Or you become part of a bonnet and attack your own government's military. Then you get some very angry knocks on your door and a black back over your face.
And, if you're brown, probably some electrodes on your genitals until you sign a written confession.
KairuByte
in reply to jagged_circle • • •This isn’t happening. The government understand what a botnet is, and if tens or hundreds of thousands of compromised machines are involved, they aren’t coming after you for being part of the attack.
They might send you mail telling you to take care of your shit though.
jagged_circle
in reply to KairuByte • • •Some countries have recently been snatching brown people off the streets for any reason. And firing all the smart folks who might know what a bonnet is
Be reasonable, we're talking about States here.
kingthrillgore
in reply to Scary le Poo • • •HappyTimeHarry
in reply to Scary le Poo • • •If my server is already open to everyone, what kind of potential attacks do i need to be worried a about? I dont keep personal files on my streaming server, its just videos, music and isos/roms. I dont restrict sign ups, so the idea of an unauthorized user doing something like download a video is a non issue for me really.
I do see where there could be problems for folks running jfin on the same server they keep private photos or for people who charge users for acess, but thats not me.
Am i missing something or is the main result of most of these that a "malicious" actor could dowload files jellyfin has access to without authentication?
https://lemmy.saik0.com/u/Saik0Shinigami
in reply to HappyTimeHarry • • •With unrestricted signups, they can obtain their own account easily. With their own account they can enumerate all your other users.
If they have their own account they can just find your instance, make a login, collect all the proof they need that you're hosting content you don't own (illegally own) then serve you a court summons and ruin your life.
I wouldn't worry about the vulnerability in the link since your already wide open. But I wouldn't leave Jellyfin wide open either. Movie and TV studios are quite litigious.
I hope you're at least gatekeeping behind a vpn or something.
Edit: typo
like this
TVA likes this.
jagged_circle
in reply to HappyTimeHarry • • •I guess the worst thing is that your server starts attacking the US military servers because you've become part of a botnet.
That happened to my friend one time when I installed Linux on his computer. He made the username and password the same 4-character word. Got a letter from the DoD.
I dont think they would be so forgiving these days. Especially if you're brown.
like this
TVA likes this.
ReversalHatchery
in reply to Scary le Poo • • •like this
TVA likes this.
jagged_circle
in reply to ReversalHatchery • • •like this
TVA likes this.
jagged_circle
Unknown parent • • •I dont know what that means.
Can I use that in addition to another VPN on mobile?
like this
TVA likes this.
jagged_circle
in reply to Scary le Poo • • •Outch
like this
TVA likes this.
ipkpjersi
in reply to Scary le Poo • • •https://lemmy.saik0.com/u/Saik0Shinigami
in reply to ipkpjersi • • •No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".
Edit: The biggest issue of unauthenticated streaming of content...
github.com/jellyfin/jellyfin/i…
Last opened last week. closed as duplicate. it's unaddressed completely.
Streaming API respond with content even the provided API key is invalid · Issue #13777 · jellyfin/jellyfin
GitHublike this
TVA likes this.
ipkpjersi
in reply to • • •Laristal
Unknown parent • • •You can, its an option if you use tailscale. tailscale.com/mullvad
Also look into using tailscale lock to secure things more if you do decide to use it
Surf the Web Privately with Mullvad's Global Network + Tailscale
tailscale.comHurlingDurling
in reply to Scary le Poo • • •https://lemmy.saik0.com/u/Saik0Shinigami
in reply to HurlingDurling • • •While I'm sure that some of the answer is in not having dev time to fix it... Their response makes it seem like they're not fully interested in fixing it for other reasons... In the case of this response, "Backwards compatibility".
HurlingDurling
in reply to • • •ipkpjersi
Unknown parent • • •