- cross-posted to:
- selfhosted@lemmy.world
- plex@lemmy.ca
- cross-posted to:
- selfhosted@lemmy.world
- plex@lemmy.ca
We have recently experienced a security incident that may potentially involve your Plex account information. We believe the actual impact of this incident is limited; however, action is required from you to ensure your account remains secure.
What happened
An unauthorized third party accessed a limited subset of customer data from one of our databases. While we quickly contained the incident, information that was accessed included emails, usernames, securely hashed passwords and authentication data.
Any account passwords that may have been accessed were securely hashed, in accordance with best practices, meaning they cannot be read by a third party. Out of an abundance of caution, we recommend you take some additional steps to secure your account (see details below). Rest assured that we do not store credit card data on our servers, so this information was not compromised in this incident.
What we’re doing
We’ve already addressed the method that this third party used to gain access to the system, and we’re undergoing additional reviews to ensure that the security of all of our systems is further strengthened to prevent future attacks.
What you must do
If you use a password to sign into Plex: We kindly request that you reset your Plex account password immediately by visiting https://plex.tv/reset. When doing so, there’s a checkbox to “Sign out connected devices after password change,” which we recommend you enable. This will sign you out of all your devices (including any Plex Media Server you own) for your security, and you will then need to sign back in with your new password.
If you use SSO to sign into Plex: We kindly request that you log out of all active sessions by visiting https://plex.tv/security and clicking the button that says ”Sign out of all devices”. This will sign you out of all your devices (including any Plex Media Server you own) for your security, and you will then need to sign back in as normal.
Additional Security Measures You Can Take
We remind you that no one at Plex will ever reach out to you over email to ask for a password or credit card number for payments. For further account protection, we also recommend enabling two-factor authentication on your Plex account if you haven’t already done so.
Lastly, we sincerely apologize for any inconvenience this situation may cause you. We take pride in our security systems, which helped us quickly detect this incident, and we want to assure you that we are working swiftly to prevent potential future incidents from occurring.
For step-by-step instructions on how to reset your password, visit:https://support.plex.tv/articles/account-requires-password-reset
You must log in or register to comment.
Glad I never gave Plex any payment details, don’t reuse passwords, and don’t plan on using it any more so I can just ignore this
I bought a lifetime subscription years ago, and even if the payment method got decrypted, it’s well expired. Not to mention I haven’t had a Plex server running for ages.
They say that passwords are hashed but we’re they salted?
Nevermind the credit cards, it’s the viewing habits they can sell that really make money.
End of the day does it even matter? They’ve gotten a ton of other information including authentication data which is probably just as, if not more, useful/lucrative to them.
From another source:
Server owners will also have to claim their server again and possibly update it, as Plex has also announced that it had “made adjustments” that will temporarily prevent “regular” users from connecting to any Plex server they have been granted access to.
The reason given is that too many Plex Media Server instances have yet to be updated to version 1.42.1, which contains a fix for a vulnerability (CVE-2025-34158CVE-2025-34158) that could be exploited remotely by authenticated users to gain access to the server and tamper with it and the data on it.
This part should have been a lot more visible and not just hidden as part of a generalized forum post. The error the individual users got doesn’t do anything to make it clear what the user or server owners need to do.
As an intentional change by Plex, presenting basic guidance as to what the error theyve caused means should be the absolute bare minimum. This is the piece that annoys me most.
I hate the tone companies always use with this
Some evil guys did something to us, it happened to us, and there was nothing we could have done to prevent it, but we were so quick to respond and stop it!
Aka, you fucked up with your security. Could you just once admit that?
I understand what you are saying, and what you want… but admitting fault publicly is a huge liability, as they have then stated it was their negligence that caused the issue. (bear with me and read this wall of text – or skip to the last paragraph)
I’ve worked in the Sec Ops space, and it’s an arms race all the time. There are tools to help identify issues and breaches quickly, but the attack surface is just not something that can be managed 100%. Even if you know there is a problem, you probably have to send an issue to a developer team to update their dependency and then they might need to change their code as well and get a code review approved and get a window to promote to production. A Zero-Day vulnerability is not something you can anticipate.
You’ve seen the XKCD of the software stack where a tiny peg is propping up the whole thing? The same idea applies to security, but the tiny peg is a supply chain attack where some dependency is either vulnerable, or attacked by malicious actors and through that gain access to your environment.
Maybe your developers leverage WidgetX1Z library for their app, and the WidgetX1Z library just updated with a change-log that looks reasonable, but the new code has a backdoor that allows an attacker to compromise your developers computer. They now have a foothold in your environment even with rigorous controls. I’ve yet to meet a developer who didn’t need, or at least want, full admin rights on their box. You now have an attacker with local admin inside your network. They might trip alarms, but by then the damage might be done and they were able to harvest the dev database of user accounts and send it back home. That dev database was probably a time-delayed copy of prod, so that the developer could be entirely sure there were no negative impacts of their changes.
I’m not saying this is what happened to Plex, but the idea that modern companies even CAN fully control the data they have is crazy. Unless you are doing full code reviews of all third-party libraries and changes or writing everything in-house (which would be insane), with infallible review, you cannot fully protect against a breach. And even then I’m not sure.
The real threat here is what data do companies collect about us? If all they have is a username, password and company-specific data, then the impact of a breach is not that big – you, as a consumer, should not re-use a password. When they collect tons of other information about us such as age, race, location, gender, sex, orientation, habits, preferences, contacts, partners, politics, etc, then those details become available for anyone willing to pay. We should use breach notifications like this to push for stronger data laws that prevent companies from collecting, storing, buying or selling personal data about their customers. It is literally impossible for a company to fully protect that information, so it should not be allowed.
A great place to start is data privacy laws. If they don’t collect unnecessary PII, it can’t be exposed.
But yes, companies need to face more liability. While it’s true that no one is inhackable - you’d need to be perfect everywhere all the time and the bad guys only need one break to succeed - there are best practices that make it a lot more unlikely. If you as a company have been hacked and you’re not taking good care of your customers data, you should be liable for carelessness. Admittedly following good data security practices can be expensive but that’s why there should be consequences for those who cut corners
I fully agree: Companies and their leadership should be held accountable when they cut corners and disregard customer data security. The ideal solution would be that a company is required to not store any information beyond what is required to provide the service, a la GDPR, but with a much stricter limit. I would put “marketing” outside that boundary. As a youtube user, you need literally nothing, maybe a username and password to retain history and inferred preferences, but trying to collect info about me should be punished. If your company can’t survive without targeted content, your company should not survive.
In bygone days, your car’s manufacturer didn’t know anything about you and we still bought cars. Not to start a whole new thread, but this ties in to right-to-repair and subscriptions for features as well. I did not buy a license to the car, I bought the fucking car; a license to use the car is called a lease.
i had to argue with some friends that when a breach happen and the company did not do everything in they’re power to prevent it, then it is the company’s fault.
They argued that bad actor should never do bad things, even it they are at hands reach.
If a company exposes an s3 bucket with clients data publicly, the company is 100% at fault if someone discovers it and sell the data. ofc the guy would be liable too.
I’m no lawyer, but wouldn’t that basically open them up to an instant win for anyone who files lawsuits against them?
Yes and no. hacking isn’t new. Everyone could get sued technically for security breaches for not taking enough interest in their own security.
But then it’s ridiculous if you could sue your own grandma cuz you once used her computer to print your resume and because she uses default passwords now someone has all your info you had from anything you left behind.
Ransom and hacking is pretty common unfortunately in the industry. And it is in part on the user to also take practices to protect themselves if they haven’t enabled 2F yet. And there’s way more you can do where you make email masks now and simply do not fill in with your accurate information like don’t use your real name.and use a VPN. Store stuff on ext drives and less on clouds that don’t use e2e encryption
I don’t know if it’s perfect but as a user just always have it back in your mind that your information can be obtained(if you ever used a web service to check your info on the dark web, this is pretty much going to be a given) . And it probably has. So maybe at least you can try to control what gets obtained.
In some ways 2fa is a weak spot even disregarding recovery processes being open to social engineering, now you’re giving a verified identifier uniquely tied to you
I generate unique email addresses and passwords for every account but can’t realistically do that with phone numbers
2fa by sms or voice isn’t especially secure anyway since you’re open to sim attacks and social engineering. I have a lot more hope for Passkeys but don’t really trust the practical advice arts of managing them yet
Depends on how good the lawyers were that wrote the thing you said you read when signing up.
No one is safe from hackers. Everyone and every company will get hacked, it’s unavailable. What matters is how they react to the inevitable because that’s how best practices are made.
It was securedly hashed! We used ROT13! Twice! We’re fucking professionals!
It’s possible to use salts, peppers, and key stretching algorithms that repeatedly hash a password like 100,000 times. So yes, it’s possible to do so securely.
Ok, but what if it’s only hashed 80 000 times? Should I sue my provider?
This is why I barely trust any streaming platform… I mean I try to not use my ‘real’ email for anything (and I stupidly linked my other emails to it on my phone, so Google basically knows it even if they dont have direct access to the inboxes).
There is so much shit being hacked that the idea that rhat any information we put out there isn’t already available on the darkweb is stupid. Even some AI camera surveillance company has said that they built their database in part based on information they bought from the darkweb (I need to get the source again).
And I rarely hear about those same hackers getting caught. Its almost like they have it down to a T and it is simply too profitable and the chances of getting caught are too minimal to care. And this shit is continuing despite all the legislation being passed to monitor more and more internet activity, which makes me think if any of it will even work?
It is still rare that someone truly criminal is caught because of some internet searches. Most data is collected from confiscated computers and if they simply deleted their browsing history and used a basic file shredder to wipe their free space they would not be able to recover anything.
Jellyfin advertisement 🤷♂️
Stuff like this can happen to any app, developers are only human, shit happens. A bigger company is a bigger target for hackers, so there is some saftey in an open source app that’s not as popular, but then again a bigger company also has more resources to monitor for security breaches and quickly address them and push out a hot fix, can’t say I know how this works for free open source apps
I think the point here is that Jellyfin doesn’t have a centralized login or website like Plex does. An attacker would have to know about your server and log into it directly to get access. If you run it in a container, there isn’t a lot they can do other than trashing your media library, which you should have protected with filesystem snapshots anyway.
Jellyfin doesn’t even have write access to my files. If they can get access into the container’s process then I guess they could add stuff to the web interface which could contain bad stuff.
OK, coming from a Jellyfin user for years, its not like it’s impervious to any attacks.
I enjoy using Jellyfin and hope it continues to improve, but it has some problematic security of its own.
But if you just run it locally an a media server in your home, and you don’t expose the service to the internet, that doesn’t really matter? Though perhaps more people connect to their Jellyfin instances remotely than I realize.
It matters if someone manages to hide an exploit in jellyfin’s codebase, or more likely, a popular plugin. I imagine many folk have permissive outgoing firewall rules, in which case, an exploit could establish connectivity. Whether that eventually leads to privilege escalation on the jellyfin host would depend upon other variables.
edit: I should add that I’ve not used jellyfin and am unfamiliar with how plugins are implemented. I don’t want to speak out of turn, only to suggest, in the abstract, that just because software isn’t exposed to the net, doesn’t mean it cannot harbor exploits that could become problematic. Plugins just seem to be a common vector for such types of software.
Well. If you’re not streaming why have such a service in the first place? If I didn’t stream remotely with Plex (and share with my friends and family) I’d just go back to running Kodi on my htpc like I did ten years ago.
For example?
Lack of built-in 2FA for one thing
Just installed that yesterday lol
🍮🇫🇮
If you have Synology using DSM style install
Here is how to “claim” your server that it logs you out of.
https://forums.plex.tv/t/synology-faq-questions-answers-and-how-tos/490215/39
Tldr; Uninstall but keep files. Reinstall using the existing files and a newly token.
Sure would’ve been nice to know this 2 hours ago.
@davedornelles@mastodon.social
Word of warning. Resetting your password is causing lots of people to lose access to their server. I’ll be deleting config and reclaiming the server after work.
Didn’t need to delete anything, just logged in directly via the servers IP and claimed it.
That’s awesome that you had a slightly easier path to recovery
I’m not a security expert, but password hashing is mostly to slow down someone from getting all the passwords. You can’t reverse the hash, but you can generate hashes until you find a match. When hashing, you can dial in how much compute it would take someone to try and solve all the hashes in your database. If you used a good password, it will be more difficult to solve your hashed password. But it’s best to change your password as Plex suggests.
So it depends on how secure a password is and how strong of hashing Plex used when storing the hashed passwords. I have no idea if this is like a “this will take a year” or “this will take a billion years” to solve all the hashes. More compute also means you can solve the hashes faster. Maybe someone with a security background could chime in.
You can’t reverse the hash, but you can generate hashes until you find a match.
That’s called a rainbow table attack, and that’s why you should salt your hash. This salt basically appends a unique string of characters to every password before it goes into the hash. Let’s say your users are dumb and use “password” for their password. If a hacker has pre-generated a rainbow table, (which is extremely time and resource intensive), then they’ll instantly crack that as soon as they get a match on those common passwords. Even if they haven’t generated a rainbow table, they can just look for identical hashes and guess that those users are using common passwords.
But if you salt it, it’ll slow the hackers down drastically by invalidating their pre-generated table. Each user has their own salt stored alongside the username and hash, so User 1’s hash actually saw “password19,jJ03pa5/-@“ while user 2’s hash saw “passwords)205JrGp02?@-“. Because each of their salts are unique, their resulting hashes are unique too. Even though they used the same password. Now the hackers need to crack the hash for each user, by incorporating the existing salts for each user. They’ll start with the weak and common passwords first, which is why it’s still best practice to use strong passwords. But they can’t actually start the rainbow table process until after they have hacked the info, and they’ll need to create fresh tables for every single user.
Best explanation of salt I’ve ever seen. Thanks!
NaCl
So is this user specific salt word stored in a table somewhere, how does the company decrypt a salted password otherwise, and so if the salt is also stored somewhere alongside the encrypted password, couldn’t the hacker get his hands on both the salt and the password and use that to figure out the password?
Yes, the salt is stored right alongside the username and hashed password. The point of the salt isn’t to be unknown; It’s to make every single password unique before it gets hashed, which invalidates the hackers’ pre-generated rainbow tables. It forces them to re-generate their table for each user. Even identical passwords will create different hashes, because the salt is different for each user. Essentially requiring the hacker to brute force every single password, even after they have the database downloaded.
Basically, the hash algorithms are known. There are a few common ones, but they’re all reliable. A rainbow table is generated by running potential passwords through each hash, and saving the results. For a simplified example: maybe for a certain hashing algorithm, “password” generates the hash “12345”. I have a pre-generated table with millions of potential passwords that tells me as much. And I have repeated this for all of the most popular hashes. This gigantic database (literally hundreds of GB in size) of millions of potential passwords and resulting hashes for the most popular algorithms is my rainbow table. This took hours of cooking my CPU to generate.
So I hack an unsalted password database, and find a bunch of hashes that are listed as “12345”. I can now guess that they’re probably using that specific hash algorithm, and can immediately crack a bunch of passwords purely because I have already brute-forced them before I hacked anything. I can also crack the rest of the passwords much faster, because I’m only needing to brute force the one algorithm I know they used, instead of being forced to hash with all of them.
But now let’s say it’s a salted hash instead. When I hack the database, my pre-generated rainbow tables are useless. Because now “password” is not being hashed as “12345”. It’s being hashed as something entirely different, because the salt is added before it gets hashed. Even if multiple users use “password”, it still doesn’t help me because each of their salts is unique. So even if two different users use “password”, they’ll each return different hashes. So I need to recreate my rainbow table for every single user. Even if two users both used “password” I’ll still need to check each one individually, with their unique salts.
This doesn’t completely invalidate the breach, but it drastically slows down my ability to access individual accounts. The goal is simply to slow me down long enough for the company to be able to send out “hey, change your password” notifications, and for the users to do so. Without a salt, once I have the database, I instantly know which hash the company is using. And I can immediately access a bunch of accounts using my pre-generated rainbow table. But with the salt, I’m still forced to crack each user individually.
To be clear, weak passwords will still crack faster. A good password guessing attack doesn’t just brute force. It starts with known lists of common/popular/weak passwords, because that known list of weak passwords will often get you into an account extremely quickly.
the salt does not need to be encrypted. the point of it is that it makes a generic rainbow table useless, because the crackers need to compute hashes themselves for all passwords.
as they said, the purpose of hashing is to slow down the crackers, because they need to find the string that produces that hash. a rainbow table cancels that, it makes password lookup for an account almost instantaneous. but a rainbow table is only really useful for unsalted hashes, because for salted hashes a different rainbow table is needed that takes the salt into account.
If the hash is unique per person, hackers need to build a new table per person. It doesn’t matter if the hackers can get their hand on the salt; the point is that they cannot try the common passwords easily for all users; it takes N times as long where N is the number of users with a different salt (hopefully all of them)
Not entirely
Firstly you don’t “generate hashes until there is a match”. You can generate hashes until the end of the universe and you’ll still have only a fraction of all possible hashes.
What typically is used are large lookup tables with hashes from known passwords. You can then take that table, take a hash you got, and look it up.
So firstly, hashes should be salted, and if salted correctly, it’s already extremely much harder to use because these tables no longer work. There are few more things you can do but that pretty much is a hard wall already.
The problem is that many corporate systems out there have horrible security. They either use a hash that has been known to be broken since a long time ago (hello LinkedIn), don’t use salting (hello linkediiiiiinn), or don’t use hashing at all.
It’s because of idiots like these that there are so many accounts with password tables out there
What to do?
Use password managers. Now all your site’s have different, safe passwords and you only need to know one. Use 2FA where possible and supported
Can you also use a list of common passwords and a ruleset you apply to those common passwords, and then
hash(applyRule(commonPassword), salt) == compromised hash?I’m not entirely sure what you mean but my password manager alerts when the hash of one of my passwords matches one from a dark web data dump, and prompts me to replace it with a newly generated one.
I’m sure it’s not a unique feature
Admittedly I do have a few bad password, a combination of I don’t see how I could care (like a Reddit alt account) and sites that break the password change automation (yeah I’m lazy)
I wonder how that works. The point of password hashing is to uniquely scramble your password. So userOneHash(“password”) should give a different output than userTwoHash(“password”) even if they use the same password. So your password manager shouldn’t really be able to generate the same password hash since an infinite number of hashes can be generated from the same password.
If they are following best practices then individual hashes should be salted and the database of hashes should be peppered so even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords.
I don’t think that’s how salts work. I might be wrong, but I think it works like this
Password + Salt -> Hash
- “p@ssword” + “hakf” -> “hifbskjf”
- “p@ssword” + “jkjh” -> “gaidjshj”
- “p@ssword” + “afgd” -> “afgdufj”
Notice how those 3 users use the same password, but the different salts results in 3 different hashes. That doesn’t make it any harder to crack a single hash, but it means I have to crack the same password 3 times. It just slows down password cracking.
Edit: my explanation isn’t wrong, but I didn’t understand the pepper part until now. So I understand the above now.
You missed the part about pepper. Pepper is something that’s added, like salt, but that isn’t stored with the password. A low security version of this is an environment variable, but it could also be a secure hardware device on the machine.
So it’s more like this:
- “p@ssword” + “hakf” + “pepper” -> “hifbskjf”
- “p@ssword” + “jkjh” + “pepper” -> “gaidjshj”
If an attacker only has the salt, they’ll “crack” the password into something that’s not the original password:
brute_force("higbskjf", "hakf") - > "kdrnskk". The idea is that it might take a few days for the attacker to recognize the error, and by then the security team has already responded and locked the backdoor.Even if the passwords are peppered, users should assume their password is compromised and change them. But peppering may prevent a cascade effect from reused passwords.
I actually didn’t realize pepper was a thing. I mostly do frontend. But that’s really interesting!
That’s all you can do though, extend the time it takes to brute force, so I’m not sure what the distinction being made is.
Response time is critical. It’s the difference between immediately getting pwned vs. having time for the security team to identify the threat, notify their users, and users to assess the impact of the breach and change their passwords.
even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords
I thought you were suggesting that salted hashed passwords were uncrackable but maybe I misunderstood this
Edit: I understand the offline pepper part now. My bad
Gotcha, no, I wasn’t trying to make that claim, it’s just a way to make it more difficult/time consuming
I harbor a strong dislike for the profiteers at Plex but their security incident response is textbook correct. Good job security dudes! The rest of your stupid company should listen to you more often.
Overall I agree, but not requiring users to change password when the hashes were taken is a bit too soft IMO.
It will also be interesting to see if they make a public disclosure about the specifics of who and how. They also don’t specifically define if media watched data was included or excluded.
Either way, happy I migrated to Jellyfin.
It shows how low the bar is, that just bare bones complying with GDPR notification requirements so as not to risk a €20M fine, is enough to make people talk about how good a job you did.
As I slide the needle from “strongly dislike” to “not a fan”.
Good on em
I do think they missed a bit about password reuse, since they tell you to reset the password on their site, you should be changing the password on any other sites where you reused it. But yeah, not arguing about it being good otherwise.
They say password were securely hashed, following best practices, which would include a salt, which is different elsewhere.
But if you can solve the hash by generating password guesses, hashing them, and comparing them to the hashed passwords in the database. Say I hash “p@ssword” and I use the salts sorted in the stolen database. I find that jon@example.com uses “p@ssword”. I then go to Amazon.com, login with Jon’s account, and order a bunch of stuff to my address.
Salt just makes it so I can’t hash “p@ssword” once and find everyone with that password the database. Instead I have to hash “p@ssword” multiple times. It really only slows me down.
I’m not a security expert, can someone tell me if I got that right?
That assumes the salt was also compromised/extracted. Unfortunately, they don’t say. Which one could read as not compromised. But they’re not transparently explicit about it.
I was surprised they didn’t recommend changing passwords elsewhere, too. I would also prefer them to be transparent about how they were vulnerable/attacked.
That’s correct. All salt does is force the attacker to compromise each password individually. Those passwords should still be considered compromised and users should change them everywhere they’re used.
If you add pepper (random data stored separately from the passwords and salts, like an ENV var or ideally secure hardware device), an attacker would also need the pepper to crack the password correctly, which significantly raises the bar. However, even then it’s good practice to change that password everywhere even if compromise is unlikely, because again, someone could link your login to another compromised site and crack the easier site’s password hash.
The only reason it’s okay to not recommend a password change is if the password hash database was provably not compromised, but in that case, I’d want details on how they kow that.
I’m not a security expert, but to my knowledge that’s the point - even a unique salt global to your site/service can help. Worth mentioning are rainbow tables, which are databases of hashes for known strings, so you can take a hash and look up the string, and very easily defeated by salts.
But if you use a salt that is global to your site/server, you still have this problem: If a hacker cracks “p@ssword” in your database, they immediately know all users that also use “p@ssword”. Imo the biggest benefit of using salts is two users with the same password get different hashes. Right?
I’m not saying using a global salt isn’t better than no salt, but I do think you’re missing out on a huge benefit of using a per hash salt. Keep in mind I’m a frontend engineer not backend or security lol.
They also say
meaning they cannot be read by a third party
which equally isn’t true.
If your password is guessable with trillions of attempts, and whatever information and time an attacker wants, then of course can they crack your hash, “read” your password, and try it on other services.
Sadly the kind of password susceptible to being broken on account of not being strong enough is also the kind people use everywhere because they memorize it. A truly strong password will only be found in a password manager.
If the password is securely hashed, and the attack only includes data exfiltration, then there’s theoretically no risk of breaking into users’ accounts anyways. However, the issue is that if somebody can log into your Plex account, that means they got your password somehow - and if they did get that password, they can use it elsewhere. So if there’s any reason to change your password on Plex, then there’s just as much reason to change that same password elsewhere.
Do any of you receive a password reset mail? I don’t. So I fear somebody might have already changed /taken over my account? Even though i do use two factor auth?
- I did receive the initial notice
- I did not receive the reset mail i asked for. Not in spam either. I have checked that the emailadress is identical to the one i received the original notice for.
Try it again. I bet their password reset service was swamped after sending the notice.
No cigar still. Beginning to get a tiny bit nervous
I received it fine about an hour ago
For me that worked, about 9 hours ago. Maybe there is more load now that the Americas are awake?
Hope they did actually delete my data when I deleted my account, but I don’t think I use that password anywhere anymore anyway.
The hash was only exposed.
-
admitted the issue immediately
-
reassured users as to actual scope of breach, probable risk
-
provided recommended actions for users who think they may be impacted.
-
explained best-practices (enough for a laymen’s audience) and how they limited scope and impact.
-
did not deflect blame
My god…I’ve got to hand it to plex. This is the perfect incident response letter. Love 'em or hate 'em, this is a good example for other CISOs.
Yeah, I have to agree. When a breach occurs (and it happens to just about every organization at some point or another) a press release this honest, responsible and immediate is not really the norm. I see this as a show of competence on the security front and integrity for the company as a whole.
I do wish Plex wasn’t further enshitifying their product more with every release, but that’s a different issue.
I mean I don’t understand the accolades for literally just following the law.
You can follow the law and still screw up the response/announcement pretty badly, and so many do not even manage that much.
So yeah. It’s satisfying when someone acts both professionally and conscientiously in a situation like this.
Yeah, even if it is the law, companies do tend to fall short of adhering to said law. For example, a lab that does cancer screening got hacked and pretty much messed up their entire response.
Fully agree. There is no time and space to play the blame game, as it simply does not matter at this point. React swiftly and be transparent. You are free to invest months afterwards for investigations and followups
They didn’t provide any real timelines, unless I missed something. Trust me bro, we shut it down real fast.
I don’t understand what the difference would be. The damage is done and they notified people of those damages.
Well, if it said “The attacker gained access to systems in October 2023 and we patched out the vulnerability during March 2025,” you’d be asking why it took so long to discover the intrusion and why they didn’t let us know for six months?
Well, if it said…
It didn’t
It was rhetorical.
-
Man. My decision to go with Jellyfin just keeps paying off more and more
No doubt. Why do you need an account on their servers to use a server on your own hardware? So dumb.
The second I saw that I immediately looked for alternatives and abandoned plans to have my own Plex server. I knew it would enshittify fast when they can lock you out of your own server
fuck plex for plenty of other reasons, but you can disable authentication on your local network.
Just a matter of time until they remove that
For me… my server software is running. But the account doesn’t see it. And as such I can’t claim my server to get it back up and running.
Fun times. Glad I changed my password. :/
If you just changed your password and now you don’t have access… Directly connect to the server http://<serverip>:32400/web and you’ll get the setup prompt to connect it back to your account.
If that doesn’t work you can restart the server and try again (should catch up that it’s unauth’d). Or run a tool like https://github.com/ChuckPa/UserCredentialReset to reset it so you can reauth it.
Thanks for that second link… I’ll give it a try.
I’ve done nearly everything I can think of to get it sorted.
Out side of jellyfin. That said. I’m going to spin up a container of jellyfin tonight. This has absolutely taught me that Plex is a huge point of failure for my media consumption.
jellyfin is goated. Long live jellyfin!
Good luck getting a similar reaction to the myriad of security issues Jellyfin has
Yeah, but you can run jellyfin with local accounts, entirely within a VPN. Pretty much makes most security issues irrelevant.
Which is the exact mindset that enables Jellyfin devs to not fix those issues, congratulations
Maybe? Like, I’d very much prefer they fix them, even though they do not impact my use case.
I don’t mean to come across as confrontational, but, maybe stop defending it then? You can keep using and liking the software while still holding the devs accountable for what is basic modern web security.
If all the Jellyfin users I saw acknowledging the issues actually stopped acting like it was a non issue, maybe the Jellyfin devs would do something about it.
On the one hand, maybe. On the other hand, the point here was more that the centralised design of Plex that necessitates an online account which might hold some private data makes such issues much worse, not that jellyfin’s issued should not be fixed.
My comment, that you answered first to, was about the way the Jellyfin devs would not react the same way to a security incidence, since they do not care about it (or at least don’t see it as important).
Also, the decentralized nature of Jellyfin does not mitigate such attacks, since you don’t need the users credentials to begin with
Y hope you know how to harden jellyfinn, because they are not better than plex team…
Jellyfin dev team is not in charge of your self hosted security though. You know what you are getting, source code available, and it’s up to you setting the security.
But they are responsible for the unsecured / gruyere cheese product they ship.
Jellyfinn has a lot of holes and it is easy to deploy it in a insecure way by not techie people. Last time I checked they even didn’t have a recommended practices for hardening it
Not techie people are not going to be able to open it for internet access. If you have the knowledge to set a internet available service you should have the knowledge to be able to provide basic security.
Most security issues with jellyfin are an issue only for a specific type of user. The one who is selling access to their server. The worst Jellyfin security issue makes selling access to your server a higher risk situation.
I hope someday those issues would get patched, but I get why there are other priorities for the dev team right now, about issues that bother to a bigger majority of jellyfin users.
Well, when I was talking about not techie people I didn’t mean technology analphabets, everybody can open a port in your consumer router with the help of chatgpt, not everybodies is able to realizes they need a reverse proxy with tls and modify the headers for the Auth…
Being secure in internet is like the herd inmunity for corona times, your system could be fairly secure, but if you are hammered with several bot nets it is going to be a challenge, and there is responsabiity is shipping a product that is easy to be infected.
And your third paragraph really confirms why this post is necessary
Have to point a dns to the ip, buy a domain, stablish ddns. I don’t see it happening often. If you know all that you are ought to know about getting hitm
Bot hits are not a problem for jellyfin. The main problem right now is unauthorized access to endpoints for people who know the hash that is being used in that endpoint.
It’s a targeted attack that hampers availability of the services (making it more available than it should be). It doesn’t make internet more insecure or anything.
As I said previously I haven’t actually known of any of these attacks happening on the wild. As they are kinda hard of pull of. You need to know the precisely hash used for the endpoint, the most normal way of knowing that without being an authorized user is because you used to be an authorized user and you are not anymore. That’s weird in jellyfin current ecosystem. People say that the hash could be calculated by a complete outsider, but I have never seen anyone pulling it off on the wild. You need to know a lot of things about the service you are attacking to be able to do it.
So, yes is a security vulnerability, all software have those. But I think it gets blown out of proportion often.
Every year Jellyfin improves and Plex further enshittifies. You’re fighting against the tide here.
???
This is not about enshitification. The best user friendly app can be a security nightmare and an utterly crap can be rock solid.
It is not about that, not even development models or just rock star programmers.
It is about who has a performing security team and who doesn’t.
None of Jellyfin’s security issues affect me.
All of Plex’s shit does.
My Jellyfin is behind a Crowdsec + Cloudflare proxy with geoblocking and other protections + Reverse Proxy with additional protections, in a rootless Docker container with no access to the Docker socket, and has only access to a mounted folder which contains just downloaded movies and shows. The effort to break in is high, the reward very low.
But the most important difference between Jellyfin and Plex is that neither Jellyfin devs nor Jellyfin instances have any personal or credit card information from their users, and therefore are way less a problem if hacked into.
Good to read you know how to implement some protection layers around your jellyfinn :)
But most of the people (specially the plex ones) don’t have the technical background to deploy something like you have, and convince those people to do the switch without knowing how to protect themselves is not a wise thing to do. Specially when this time, plex response was perfectly fine :)
But most of the people (specially the plex ones) don’t have the technical background
Seems weird to say, because I had to setup Plex one time on a server for testing and it was a bit harder than setting up Jellyfin, so I wouldn’t call most Plex hosters dumb.
Plus they are still hosting something on their servers, they would still need to secure it in some ways?
p.s., the “Jellyfin is insecure dont host it on the internet” is just fear mongering at this point…
Jellyfinn has a nice record of problems during the authentication and escalating privileges, even the developer team recommends to use it behind a vpn and don’t expose it to internet.
If course, you can use a reverse proxy with and external Auth framework to mitigate it, pair it with fail2ban, geo restrictions and a second factor, but those things are not in the scope of the regular user.
Let’s face reality, plex is not such widespread for being the default option in kali Linux…
You’re exactly the kind of Jellyfin user the rest has to thank for the devs lax approach to security. If you actually demanded even basic security, the devs would maybe at least consider it a priority.
But until it no longer provides an unsecured API, you should maybe think about whether you want to portrait it as secure.
I already answered your second paragraph: Jellyfin holds no sensible data.
And there is no central server gathering data from all users, an hacker would need to find and break in multiple Jellyfin instances, to get useless data from 1 to maybe 10 users each time.
And Plex is not easier to install and secure than Jellyfin.
Jellyfin holds no sensible data.
Maybe if you don’t live in a country where piracy is actively prosecuted
And Plex is not easier to install and secure than Jellyfin.
You can literally start a Plex server from a exe on desktop windows. Don’t make a fool out of yourself.
Also it is immensely more secure, unless with “Jellyfin” you actually mean “Jellyfin plus a myriad of convoluted extra steps every user has to take by themselves since the devs can’t be arsed to follow basic standards for web security”
Sometimes your data is not important but your computer, nobody wants to be in a netbot.
Well, perhaps plex is not better in security (we don’t know for sure) but at least they have a cyber team, a monitoring system and in every bodies hope, dedicated developers for these topics.
Jellyfinn dies not hve a team like this one per se. Could the developers be better fit and knowledged in jellyfinn than plex? Perhaps, but probably the focus is in the features and not in the security
Huh, I guess centralizing all of that userdata was a bad idea. Weird. If you hack some dude’s Jellyfin, you just hack some dude and no one else.
You don’t even have to hack jellyfin though. Quite a few endpoints aren’t behind authentication at all.
But that doesn’t help your case so I’m sure you’ll just downvote me.
Edit: For those who don’t know. https://github.com/jellyfin/jellyfin/issues/5415
Several issues. Some require being logged in with any account (to get other user information on the server, including admin)… others are endpoints that let media access if you guess a guessable md5 hash(which is normalized in docker setups in general… and standardized by *arr setups. So highly guessable if you use these tools… which most of you are). The sort of thing that media companies will absolutely abuse eventually if they’re not already doing it to collect proof that you’re hosting their content illegally. But I just find it laughable that this is the answer… but ya’ll are frothing at the mouth over plex leaking an email address… Oh no! not the email address you already get boatloads of spam at! However will you live!
I’m angry about both, yet still prefer Jellyfin. Why? I control everything about it. I self host it and can choose who has access (including putting it behind a VPN). I have the code so I can patch it if I choose. I can even disable the problematic endpoints of I’m fine with the repercussions.
With Plex, i have to live with their central servers. With Jellyfin, I don’t, and it’s much less likely a corpo comes after me specifically than happens to see something via a Plex compromise.
I think both are fine services, and I appreciate Plex’s response here. I still prefer Jellyfin.
While I whish access were secured at some point. I’m still yet to see one of those guessed hash attacks on the wild.
A good thing about Jellyfin is that we KNOW its insecurities because it’s open source.
Other software may be insecure like that but you would only know after an incident happens because you cannot audit the source code.
Other software may be insecure like that but you would only know after an incident happens because you cannot audit the source code.
You don’t need to audit the source code to find vulnerabilities in endpoints. You need source code to know exactly why it’s vulnerable. Plex is constantly being tested by jackasses like me who try random shit. Hell we just got a forced patch for plex that they rolled out this month. https://forums.plex.tv/t/plex-media-server-security-update/928341
Yup, and that’s why I still use it despite its security issues. I run it in a rootless container, so even if there’s some sort of breach, it should be contained.
Removed by mod
you can just make your case and see what happens first.
Oh… You mean like half dozen or so times that I’ve already brought this up over the past 2 years on lemmy, and a while before that on Reddit? It’s only after I write a whole book on the matter that the upvotes kick in. And these discussions ALWAYS end up with much higher downvote ratios than most of the other stuff I comment on. Up to and including getting called names like “shill”.
Example of the last time this was brought up that I participated in… https://slrpnk.net/comment/15703455 (which got mod removed it seems… it’s still accessible to me on my server at https://lemmy.saik0.com/post/1622830) which was the “news” of a plex staff member leaving a comment for the plex app on the Google Play store…
Or this time… Where we were all complaining about the app redesign (which I also hate) https://lemmy.saik0.com/post/1517257… The root comment was lemm.ee though… which is gone. My comment starts at https://lemmy.saik0.com/comment/4476520.
I’ve discussed the matter ad nauseum… and more often than not it’s received pretty poorly. It’s not a cop out or “bitch-ass pre complaint” when I have the history to point at.
Edit: Oh and here too… https://beehaw.org/post/19228632
Have you tried being less of a prick about it?
I find I’m less of a prick about things if I’m not called things like “prick” and “shill”.
Yet here we are. You’ve fulfilled the prophesy! Thanks for making the world a better place.
Maybe if you keep getting called a prick and a shill it’s time to do some introspection.
Yeah you’re right. I should probably drop my lemmy instance. This place is a cesspool.
Bruh. You were being a prick about it long before he called you out on a being said prick. It’s why he called you a prick.
I feel at this point that you just wanted to write “prick” as many times as you could in one sentence… Have at it.
so what, first of all, you’re just assuming the person or people reading your comment will do the same thing that’s been done to you by others before, which is weird. I’ve had the same kind of comment downvoted and upvoted on different threads. not everyone sees every comment…
but even if you were 100% right, it’s still a bitch-ass pre-complaint. it’s one thing to start with “this is gonna be downvoted to hell but I’m still gonna say it” or something along those lines… what you said was specifically about the person you were replying to, and you even gave a reason like “oh this is gonna hurt your feefees so you’re gonna downvote it” it’s just weird. the vibes are off.
Oh no! Not the vibes! However shall I live without the vibes!
alone, probably
Married with kids… I don’t even get the pleasure of my own thoughts most days anymore…
Don’t expose jellyfin to the internet and it won’t be hacked. But you are forced to make a Plex account, if you want to use Plex.
Don’t expose Jellyfin and you don’t have a competitor program that does what Plex does… stop recommending it as a replacement if it’s not a replacement. And this is ignoring that it’s recommended to expose to the internet on their own documents.
But you are forced to make a Plex account, if you want to use it.
You’ve missed the point. You can’t be mad at plex for taking action and closing security gaps after becoming aware of them… then in the same breath recommend a service that can’t even be on the internet because it’s so poorly secured.
You can use Jellyfin with wireguard and still have what Plex does. Unless you want to run an open streaming service (which would probably be illegal in most countries anyway).
90% of Plex users probably don’t need what Plex does and would be happy with Jellyfin.
You can use Jellyfin with wireguard and still have what Plex does.
Okay… Run wireguard on a roku TV or other many other common media devices. You can’t…
Unless you want to run an open streaming service (which would probably be illegal in most countries anyway).
You can use Plex and JF both without actually hosting illegal content. You should still be worried about devs who refuse to fix a basic security issue that they actively block from being merged.
90% of Plex users probably don’t need what Plex does and would be happy with Jellyfin.
probably… and 99% of users likely have no idea how to secure things properly on their own. Which makes this whole premise even more dangerous for the “typical” person.
You can use Plex and JF both without actually hosting illegal content.
Where’s the fun in that? We’re on Lemmy. Cut loose a little.
Well… I mean… you can host your spank bank materials there. Fun is what you make of it.
Okay… Run wireguard on a roku TV or other many other common media devices. You can’t…
Sucks for you. Android TV boxes can, Linux Media PCs can. Weird. Almost like you’re pirating media and you can’t be asked for a bit more effort.
Sucks for LG tv people… and Samsung Tizen users… And all sort of other people too! But I guess you go out of your way to purchase hardware for everywhere that you go and want to watch TV then, eh?
I sure as shit am not dragging a whole Media PC setup to a hotel with me. Or to my in-laws house. Or my aunt’s… But they all have a roku.
Your answer is effectively throw money and support at it… which isn’t really a good answer. Especially the moment the user isn’t strictly “you”.
So how are they hacking you? I mean I don’t see those issues as really bad. Should it be fixed yes can anyone really do anything bit that I can see. Am I missing something.
Endpoints that dont give you any data that would be considered a breach.
That unauthentic endpoint shit is so overblown. They should be authenticated and I hope it changes in the future, but its really not a serious issue. If they worry you, put the endpoints behind your own authentication through your reverse proxy.
Complete access to your media without authentication isn’t “don’t give you any data”.
Meanwhile you’re all frothing at the mouth cause Plex leaked email addresses and encrypted passwords.
And you’re correct. It’s not a breach… because it wasn’t protected to begin with.
Edit: You ninja edited your post… bad nettiquette.
put the endpoints behind your own authentication through your reverse proxy.
Breaks every app for jellyfin including tv apps. So no. that’s not a valid answer.
Edit2: And I want to be clear about this… I don’t simp for Plex I want off of the platform too… But Jellyfin in it’s current state is a much worse security nightmare IMO. I can at least kill the plex relay binary and packet sniff it to know that it’s not sharing data I don’t want it to share. Jellyfin just lets everyone in that can guess a filepath (which you can “fix” by obfuscating it… but ask any security professional about that.) and somehow Jellyfin is the messiah? Devs ignoring a 5+ year old issue that already proof-of-concepted… is wild.
Complete access to your media without authentication isn’t “don’t give you any data”.
The media on my server is not what I’d consider private data, it’s just media. If someone wants to spend their time brute forcing randomized UUIDs to have a minuscule chance of viewing some media on my server, then I really couldn’t care less. Especially since they’re gonna get blocked by http probing detection after a few tries.
If someone could the emails and hashed passwords, then I would care about the spam I’d be constantly receiving after and the possibility of my friends and family’s passwords being exposed, as not all of them use secure passwords (despite my best efforts to convince them to change that).
Simply put, if I was using Plex right now, this breach would impact the many family members and friends using my server, something I’d feel guilty about. Meanwhile, with Jellyfin, none of these concerns would have any effect on them.
Edit: You ninja edited your post… bad nettiquette.
I edited it right after posting because I accidentally clicked post. Didn’t think you’d respond that fast.
Meanwhile you’re all frothing at the mouth cause Plex leaked email addresses and encrypted passwords.
This was my only comment in the thread. Kinda feels like your reply here is taking out your frustration with this entire thread on my reply.
put the endpoints behind your own authentication through your reverse proxy.
Breaks every app for jellyfin including tv apps. So no. that’s not a valid answer.
I assumed you were talking about stuff besides media playback. There are other endpoints that can be secure using your reverse proxy without breaking any apps.
Jellyfin just lets everyone in that can guess a filepath
That’s not how the endpoint works. It is a randomized UUID.
Depending on your security posture, this may be an issue for you. It is not for me, and likely is not for many other users. My media is not sensitive information. My email and other identification info is.
Edit: formatting
That’s not how the endpoint works. It is a randomized UUID.
It’s not. It’s an MD5 of the filepath. UUIDs are generic and random, not specifically tied to something.
https://github.com/search?q=repo%3Ajellyfin%2Fjellyfin+md5&type=code
If you do a basic search, you’ll find that most api endpoint generated values are simply md5 of the filepath. And they just call this a GUID in the code… it’s not. It’s completely determinable. And the problem with this is expounded considerably if you use a default docker config (so folder path is known) and an *arr stack (so filenames get standardized). How many people modify these things significantly? Pre-hash a few permutations and just check away… Get someone like Sony (who’ve installed rootkits on people’s computer before… so they don’t give a shit), and now you could find yourself in court.
https://github.com/jellyfin/jellyfin/blob/3936fc9f253d15ae31afbdfe5fcf1684c441263c/Jellyfin.Api/Controllers/VideosController.cs#L315 is the api call itself. No auth.
Depending on your security posture
Is exactly the problem I have though with the evangelical preaching all about jellyfin here. I’ve brought this topic up probably about a half dozen times in the 2 years I’ve been on lemmy… and a while longer before on Reddit. DOZENS of people comment the same things you are… and get it completely wrong. And many more end up messaging me or responding that they had no idea this was an issue. Yet I continue to see people singing praises of Jellyfin! and how it must be so much more secure! When it completely isn’t. So many people brush it off… then flip their shit about Plex doing something.
Especially since they’re gonna get blocked by http probing detection after a few tries.
If we’re talking “mitigations”. Plex is more secure by default… and if you want to get off their auth… you can access your network via VPN and set the VPN subnet as “local” so you don’t have to do their auth. But at least plex doesn’t just let unauthed people access whatever they can guess as a default out the box option. And certainly don’t have any security issues sitting around for 5+ years waiting for a dev to do something about it.
Edit: forgot to finish a thought. Finished it.
Edit2:
This was my only comment in the thread. Kinda feels like your reply here is taking out your frustration with this entire thread on my reply.
Which immediately points to Jellyfin… as if it was “better” somehow. while downplaying the actual issue without actually reading what I’m complaining about
That unauthentic endpoint shit is so overblown.
Overblown if you have mitigations? Sure… but how many do? And why are we treating software that is taking actual actions to better security as “Worse” than something that can’t clear a simple problem in 5+ years because devs don’t want to “break compatibility”.
Edit3: OH! forgot this as well… “well they’d need to know where to find servers before they can access them to check!” Yup… hello shodan! https://www.shodan.io/search?query=jellyfin Would be trivial to make a script that does all of this and crawls shodan or other sources for domain/ip information. Hell you can probably just look up all LE certs issued that contain “jf” or “jellyfin” or other permutations of subdomains too. But shodan has a list of 11,788 when I check… that’s not insignificant…
It’s not. It’s an MD5 of the filepath. UUIDs are generic and random, not specifically tied to something.
Fair enough, I was not aware of this, and I wish the developers made this more clear in the issue thread. This does not change my point that my media is not confidential data. I do agree that it should be by default, but a “breach” where someone accesses a piece of media from my server has no tangible impact on me or my server. A breach that includes my email and account information, absolutely does.
Depending on your security posture
Is exactly the problem I have though with the evangelical preaching all about jellyfin here. I’ve brought this topic up probably about a half dozen times in the 2 years I’ve been on lemmy… and a while longer before on Reddit. DOZENS of people comment the same things you are… and get it completely wrong. And many more end up messaging me or responding that they had no idea this was an issue. Yet I continue to see people singing praises of Jellyfin! and how it must be so much more secure! When it completely isn’t. So many people brush it off… then flip their shit about Plex doing something.
I don’t entirely understand what this response has to do with what I said. I’m surprised to hear you say that people praise Jellyfin as being far more secure than Plex, as I have not heard that. Security has nothing to do with why I use Jellyfin over Plex.
Overblown if you have mitigations? Sure… but how many do? And why are we treating software that is taking actual actions to better security as “Worse” than something that can’t clear a simple problem in 5+ years because devs don’t want to “break compatibility”.
I feel it’s overblown either way, as I don’t believe the average user considers their media sensitive enough for it to be an issue. I’m not treating Plex as worse. Again, I’M NOT THE ONE WHO SAID ANY OF THAT. I am simply stating that in this specific instance, this Plex breach has a worse impact than the Jellyfin security concerns you bring up.
Which immediately points to Jellyfin… as if it was “better” somehow. while downplaying the actual issue without actually reading what I’m complaining about
My guy, I didn’t start the comment thread, I’m not the one who brought up Jellyfin. I also believe I responded to every point I made, while you ignored many of mine. I don’t know how you can say I’m not reading your comment. You’re being very weirdly hostile when I’m just trying to have a conversation. I don’t have significant stakes in either Plex or Jellyfin. I do prefer one, but I don’t give a shit what others want to use.
Edit3: OH! forgot this as well… “well they’d need to know where to find servers before they can access them to check!” Yup… hello shodan! https://www.shodan.io/search?query=jellyfin Would be trivial to make a script that does all of this and crawls shodan or other sources for domain/ip information. Hell you can probably just look up all LE certs issued that contain “jf” or “jellyfin” or other permutations of subdomains too. But shodan has a list of 11,788 when I check… that’s not insignificant…
Just want to add that I’m not some completely uninformed user. I have a career in cybersecurity, as well as a degree and plenty of certifications. When discussing a vulnerability, we need to consider the actual risk of a vulnerability, using its likelihood of being exploited and its potential impact. The likelihood of someone attempting to brute force media on my Jellyfin is practically nonexistent, as they have essentially nothing to gain. At best, they find an episode of a show or movie that they could find elsewhere. The impact of someone exploiting this vulnerability is also practically nothing. They would get a stream of the video, minutely impacting the performance of my server.
Again, to be clear, I AGREE with sharing this information. People should be aware of this when using Jellyfin. However, it is not an issue for the majority of users. It is also not anywhere near as bad as a breach of actual account information, data that actually is sensitive. I do not agree with framing it to look like using Jellyfin should be considered generally insecure.
Edit: minor phrasing adjustments
I do agree that it should be by default, but a “breach” where someone accesses a piece of media from my server has no tangible impact on me or my server. A breach that includes my email and account information, absolutely does.
Until a media company like Sony scans your server for their content and serves you a summons… Then it will have a significant impact on you. And I doubt the content that Plex leaked actually has any meaningful impact at all. It sucks… and is bad… but shit happens and nothing is perfect. I’m much more trusting of a company that actually responds and fixes problems that gets reported than one that hides in the corner with finger in ears for 5+ years.
I don’t entirely understand what this response has to do with what I said. I’m surprised to hear you say that people praise Jellyfin as being far more secure than Plex, as I have not heard that. Security has nothing to do with why I use Jellyfin over Plex.
We’re on a thread where Plex is being derided for a security problem… Where the principal comment I responded to says “Glad I’m on Jellyfin”. This is an implicit “jellyfin doesn’t have this problem, it’s secure” statement. Otherwise there’d be no point or relevance to the comment for the topic at hand.
My guy, I didn’t start the comment thread, I’m not the one who brought up Jellyfin.
You wrote
Endpoints that dont give you any data that would be considered a breach.
You are perpetuating that Jellyfin is “secure” to use on the internet. I was directly referencing what you said. I’m not sure why you keep thinking I’m talking about something else.
Just want to add that I’m not a completely random user. I have a career in cybersecurity as well as a degree and plenty of certifications.
I’m a CISO. I hire people like you and give you your job. I’m also no “completely random” but playing the appeal to authority card is stupid on a random internet forum. If I were to leak content secured by the applications that I have security ownership of. I’d be completely fucking jacked. Leaking emails and password hashes are meaningless… emails are all well known and password hashes means I just force reset the entire userbase and move on. Plex’s “leak” is annoying… but not actually sensitive at all. You should know this. It will take a significant amount of time for the bcrypt+salted+peppered passwords to actually be decrypted. There’s LOTS of time to hash that out, this email is the start of that process.
Now if your media isn’t worth securing… then why use authentication at all on Plex or JF? Why do you care about your account auth that protects your media if the media isn’t worth protecting? Why is it your default stance that exposing the media is such a nonissue… that your more worried about the data that secures your media more than the actual security of the media?
When discussing a vulnerability, we need to consider the actual risk of a vulnerability, using its likelihood of being exploited and its potential impact. The likelihood of someone attempting to brute force media on my Jellyfin is practically nonexistent, as they have essentially nothing to gain.
Unless you’re a media company like Sony, WB, or other company that actually has ownership rights of the IP that you’re storing. Remember… Sony has done things like install rootkits on their consumers computers in order to stop piracy. Why do you think that they’re above asking servers freely if they have their copyrighted content?
The impact isn’t a technical one. but a legal one. And JF could close that door and keep the media confidential in of itself so that this is a non-issue all together but specifically won’t because of “backwards compatibility”. But somehow you trust them to make secure decisions elsewhere with your content?
Love you for still trying. I don’t know how often I’ve written the same comment. They simply don’t care.
I think people think that I’m anti-jellyfin or something. I’d love to dump Plex… I WANT to dump it so bad (basically the day they did the arcade shit I’ve been highly turned off, what was that? 6 years ago?). But Plex is the best tool for what I need. Jellyfin could be there… But it’s not. Everytime I see it recommended blindly without the massive caveats (especially in the context of a random Plex fuckup that is substantially less of a problem) I just feel compelled to attempt to remind people. I dunno. Deaf ears maybe… but blind trust just because it’s open source isn’t the answer either. And honestly it turns me off contributing to some of the projects that I do because if I was to speak out about problems in those… how many people would listen?
The most succinct response I’ve seen on the matter “The statements The Jellyfin Project makes about exposing Jellyfin directly to the Internet, without a reverse proxy, is less about Jellyfin being insecure and more about there being no effort made to make Jellyfin secure.”
But that doesn’t help your case so I’m sure you’ll just downvote me.
Didn’t bother reading any further
And? I mean they should be fixed but don’t see a real dangerous issue. Someone can stream my media randomly.
Personally I wish I could just make authentication optional on my jellyfin just like it is for peertube and funkwhale.
That would be a perfectly valid answer… But the Devs have posted several times that they’re not interested in resolving it.
I’d accept a checkbox on install of Jellyfin for “Check this box for better security… some unsupported software might not like this. Go to Options/blah/blah to change this later if you need to change this later.”
I’d probably shut the fuck up about this whole thing and dump Plex. But every single time Plex ends up in an article there’s people singing praises about Jellyfin when there’s completely open endpoints… It just baffles me. Downvotes be damned, I’ll bring it up though when I see it since the devs won’t bother telling people their software has a potentially big problem (especially if you use default configs, docker, and *arr stacks).
Well its good to make sure people know about it, but I would think most admins already know and just don’t care. Its certainly not news to me, and doesn’t seem very useful in terms of actually exploiting anything.
I’m curious what youd think a kind of worst case scenario would be for any of the current jellyfin auth issues. Like what would someone with bad intentions be able to do?
I think the Plex issue with emails being stolen is a bigger problem because then those emails can get phished for their Plex accounts and possibility more. I still wouldn’t consider it a huge deal though, Plex handled it correctly.
My real issue with Plex and why I constantly shit on them is that they stole from XBMC and made a business model that monetizes piracy or at least tries to.
Stolen is a bit loaded in my opinion… XBMC was open source. All the parts that rely on that are available for free. Lots of websites out there sell shit… and run off of NGINX or Apache. taking open source things and building on them is common at this point.
I’m curious what youd think a kind of worst case scenario would be for any of the current jellyfin auth issues. Like what would someone with bad intentions be able to do?
Edit: Fuck, hit enter early… one moment. Edit2: here we go…
you have your setup… you configured it like the git repo said too and even used the container guide told you to (https://jellyfin.org/docs/general/installation/container/). You have now standardized the path… because the internal path that is recommended in the official compose will likely not change… (especially in the linuxserver version, https://hub.docker.com/r/linuxserver/jellyfin). Then you hear about *arr stack stuff and how people evangelize that on this platform too ( I’m one of them!). Standard naming convention gets applied there too…
So now bigbucksbunny.mov is stored on /data/movies/bigbucksbunny(2008)/bigbucksbunny.mov. You can pre-calc that md5 hash and probably nail people right now and get a result. Now be SONY or some other lawsuit happy studio. Grab a list of all your releases and precompile common paths and names (this would like be something that an LLM would be good at doing… fetching lists of paths that people post on reddit and other places)… generate the MD5 list. Maybe 1000 permutations of your top 10 movies… bonus points if there’s no physical release (since you could claim that you ripped the content yourself… can’t do that on streaming only content). Curl through the list of 10000 variants… if you get a hit on anything then you know they have your content… and it’s publicly accessible (which could be argued in court for distribution… though I’m not a lawyer and don’t know how reasonable that is.) You as the owner would then be on the hook… and lawsuits would commence promptly.
This is a potential “worse case” in my mind. Of course because they have evidence of access direct from your system, they can then subpoena access to the whole system… where your whole library becomes available for them to search further for more copyright violations and now your in real deep shit to explain to the courts.
Now… if you’re in a country that doesn’t care! Cool… just stop recommending Jellyfin to those that would get fucked by this. Are there ways to mitigate this highly? Absolutely… fail2ban, anubis, cloudflare bot detection shit, changing paths or adding GUID to your media library path… all can probably fix this… But none of that is in the jellyfin docs… and NOBODY else seems to mention it except for me when this discussion comes up… So how many people are actually doing it?
Stolen is loaded… XBMC was open source. All the parts that rely on that are available for free.
Okay so they violated the GPL to produce their product, it started off on good terms and contributing back up stream but then they got greedy and decided to stop giving back, On top of that they also provide nothing upstream to FFMPEG or any other of the open source projects they benefited massively from… basically they are leeches of open source software… but you are technically correct [1] to say its not literally stealing.
[1] The best kind of correct
I just edited what I meant to originally send… Now I’m replying so you get flagged and can look at it. Sorry that I fat fingered the enter button and jacked up the thread. My bad.
I mean they could also just go to Plex and ask them what’s on your server. And don’t say they don’t know considering they sent emails about what you watched. And Plex is getting into the data selling game. I am surprised this hasn’t been done.
I mean they could also just go to Plex and ask them what’s on your server.
There we go. Finally this argument came up… Plex doesn’t have a list of whats on your server.
And don’t say they don’t know considering they sent emails about what you watched.
They don’t. The metadata of “what you watched” recently isn’t attached to what data source it was watched from. You can go a search for a movie that isn’t on your server, click it and mark as watched and it will show up on that email list. You can also disable that function all together and then nothing is synced to them. You can also make a claim that they know what you have since you probably pull metadata on those items from them. Except you can pull metadata on just about anything without having the content at all.
But once again… I’d love to get off of Plex. I want to actively get off of Plex. But Jellyfin is a worse pot to jump into.
Edit2: here we go
That makes sense, I appreciate you taking the time. Its certainly not a very big issue for me personally, and i do have other mitigations in place for more general attacks like fail2ban, but not everyone is in the same situation so its a valid concern to mention.
I do think you’re overestimating the risk, Studios are unlikely to go to such lengths when there are bigger, easier targets. Still, it’s not entirely negligible, even if the exploit seems fairly benign to me personally.
My thinking as a sysadmin is if someone has security concerns, they wouldnt be JUST with jellyfin in most cases, you’d be securing an entire server (or paying someone else to handle that part), so its issues to keep in mind sure, but the mitigation would be mainly outside of jellyfin specifically anyway, thus why its not really mentioned in jellyfin’s docs or considered a big concern by the devs.
So I’m not really disagreeing with anything you’ve said, but I you haven’t changed my mind either, I’m still going to recommend jellyfin over plex.
Your recommendation should change depending on the needs of the person you are recommending too. If you recommended I change to jellyfin you would be wrong, for example.
Sure you always seem like a shill. You might not be but it comes across. Plex is not perfect either and has had breaches and been used to hack someones machine. As far as I know jellyfish has bit been used in that space and these issues could not be used for that.
and been used to hack someones machine
That person was using a horrifically out of date version of the plex server with known, documented, and already patched vulnerabilities.
This is fear mongering. Feel a duty to call it out so it doesn’t scare someone out of experiencing the joys of Jellyfin.
Good job! You understand that servers serve data! You are very smart!
That’s rich coming from you
Do you think your bank serving your data/account access to someone that isn’t you would be acceptable?
After all, their servers are just serving data, therefore they’re correctly doing their job, right?
Good servers would serve data only to those authenticated to receive it! Which Jellyfin clearly isn’t.
You’re literally in a thread where the OP topic is Plex getting hacked. I guess more secure on paper is good enough for willful ignorance.
I’m in a thread where Plex admits, responds, then TAKES ACTION. Versus the open source project that’s known about an issue for 5+ years… and sticks their fingers in their ears and tells you that you’re the problem.
I guess that we’ll just reward that project that’s lucked itself into not having an issue rather than a product that actually is trying.
Edit: Oh… and the actual “loss” of data matters here… My email isn’t special. My username isn’t special… The hashed and salted password isn’t special to me. None of this data matters to me in the slightest in this instance. However, potentially probing the content on my server directly DOES matter to me.
deleted by creator
Your email, username, and password don’t matter but the fact that you have Avengers: Endgame does? Jesus Christ man, this is why people say you’re a shill for Plex.
The only “Sensitive” item is the password… But it’s hashed and salted using bcrypt. And for me personally… it’s unique. Therefore non-important. Further their recommendation to replace the password is sufficient. Not sure how me pointing out this fact is “shill”. but you do you.
I’m in a thread where Plex admits, responds, then TAKES ACTION. Versus the open source project that’s known about an issue for 5+ years… and sticks their fingers in their ears and tells you that you’re the problem.
If installing wireguard and using proper opsec is hard then I guess they’re right.
I guess that we’ll just reward that project that’s lucked itself into not having an issue rather than a product that actually is trying.
You paid good money for it. Should Jellyfin users get a refund? PM me, I’ll send all of you $0 in XMR.
If installing wireguard and using proper opsec is hard then I guess they’re right.
Already beaten to death this argument. You get wireguard installed on a “smart” TV and then that argument will matter to me.
Doesn’t matter if your info is stolen?
Name email address, password, access history, and probably IP and location…
And that’s just what they disclosed, but they don’t have any timeline or real actions taken to prevent continued access. They don’t even tell you what exactly has been accessed: “information that was accessed included emails, usernames, securely hashed passwords and authentication data.”. It’s really not text book response for a security breach.But all of that is less important to you than the fact you have Avengers: Endgame in your library?
They are leeches taking money from you, but you 'd defend them even if they killed your dog.Edit: it’s the third time in a decade Plex got hacked. Please list instances where jellyfin leaked the data of all their users.
Name email address, password, access history, and probably IP and location…
Interesting that you assume this is the list of taken things when that wasn’t what was disclosed to us. And Plex has been absolutely forthcoming with this in the past.
Edit: it’s the third time in a decade Plex got hacked. Please list instances where jellyfin leaked the data of all their users.
Literally everyday since those attack vectors are actively open right now and have been open for 5+ years (jellyfins whole lifetime) and proof of concepted for the developers that whole time.
I geoblock everywhere but my home town and VPN everyone else, plex kiddie. If Jellyfin can’t do security, do it yourself and get to whitelisting and blacklisting. You can, can’t you, or do Plex users get confused when they see a wireguard private key?
Weird, I’d more think Plex users to be the lazy type to install their systems by copying and pasting from ChatGPT.
Well, see, if I used jellyfin I’d have to be at my mothers more often to fix her shit…and I really dont want to be at her house more than I have to.
Q: How can you tell someone uses Jellfin?
A: Don’t worry, they’ll tell you!
Strange…
This reads like the typical thing a Linux user would mention to a windows user.
And the windows user would the flamed and roasted one.How do you know someone uses Plex ?
They’ll tell you they got the lifetime for only 299 and it’s a steal you should buy it tooMany years ago, I scooped up my lifetime plex sub for I believe $100. But, when plex started pushing their own login portal, I grew wary and bitter. I outright deleted my account shortly thereafter. I more or less respect the hustle but not my cup of tea.
How do you know someone uses Plex?
Check their browser history for ChatGPT queries on how to connect to 192.168.1.1.
Why would you go to what’s most likely your router?
127.0.0.1
