This is a most excellent place for technology news and articles.
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.
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.
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.
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
jellyfin is goated. Long live jellyfin!
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.
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
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.
Jellyfin advertisement 🤷♂️
I enjoy using Jellyfin and hope it continues to improve, but it has some problematic security of its own.
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.
I think that’s a pretty good response. More details will probably emerge in the next few days that could change my mind, but for now that gives me a bit of confidence in their platform.
In comparison, a few years ago I was a patient at an IVF clinic in Sydney. I saw some absolutely bonkers security and repeatedly raised it with them. They wouldn’t hear it, and almost expectedly they were hacked and now my sperm count is public information. Their response was delayed and appalling. If my medical records were treated a severely as a streaming platform, I would have been happy.
So what's your count, bro? Save me the trouble of looking it up myself and all.
I kid but the serious lack of security in medical isn't just in Australia. I'm just a construction worker with an interest in networking and such but I see blatant violations nearly every job I'm on.
I checked, their sperm count is over 300 million, I'm pretty sure I got pregnant reading it.
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!
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.
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.
Keep in mind that the only reason they deny you the ability to log in to your own local service with your own local sign-in method is that they may upsell you on their cloud junk. If there’d be no cloud account involved - your data would not be at risk and/or leaked. They endangered your privacy for marketing purposes.
If you have not moved off of Plex - do it now. This company is fully rotten.
The email they sent out has reply-to address that conveniently does not work…
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’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.
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.
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
This isn't the first time they've been breached, there was an incident in 2015 and 2022 as well. From what I can gather its the same info being gathered each time.
There might be others but I can't find th at the moment.
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
Hope they did actually delete my data when I deleted my account, but I don't think I use that password anywhere anymore anyway.
Can someone finally realize we need to hash the emails too? I don't really give a fuck about my passwords, I can change them and they have 2fa.
But changing my email? Pain in the ass and far more irritating to deal with.
Edit: late Nate, I meant encrypted.
They say that passwords are hashed but we're they salted?
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.
