696
Plex got hacked. (forums.plex.tv)
submitted 22 hours ago by als to c/technology@lemmy.world

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

top 50 comments
sorted by: hot top controversial new old
[-] ngwoo@lemmy.world 8 points 3 hours ago

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

[-] hackitfast@lemmy.world 5 points 3 hours ago

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.

[-] ramjambamalam@lemmy.ca 12 points 4 hours ago

They say that passwords are hashed but we're they salted?

[-] inclementimmigrant@lemmy.world 9 points 4 hours ago

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.

[-] BarbecueCowboy@lemmy.dbzer0.com 3 points 2 hours ago

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.

[-] ArmchairAce1944@discuss.online 8 points 5 hours ago

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.

[-] ademir@lemmy.eco.br 1 points 3 hours ago

@davedornelles@mastodon.social

[-] CriticalMiss@lemmy.world 78 points 10 hours ago

Jellyfin advertisement 🤷‍♂️

[-] BackgrndNoize@lemmy.world 10 points 6 hours ago* (last edited 6 hours ago)

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

[-] Sneptaur@pawb.social 10 points 5 hours ago

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.

[-] purplemonkeymad@programming.dev 4 points 4 hours ago

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.

[-] TheGreenWizard@lemmy.zip 4 points 6 hours ago

OK, coming from a Jellyfin user for years, its not like it's impervious to any attacks.

[-] localhorst@sh.itjust.works 4 points 8 hours ago

🍮🇫🇮

[-] Retro_unlimited@lemmy.world 4 points 8 hours ago

Just installed that yesterday lol

[-] Patches@ttrpg.network 7 points 7 hours ago

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.

[-] moseschrute@lemmy.world 22 points 10 hours ago* (last edited 10 hours ago)

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.

[-] mic_check_one_two@lemmy.dbzer0.com 18 points 7 hours ago

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.

[-] ClanOfTheOcho@lemmy.world 6 points 7 hours ago

Best explanation of salt I've ever seen. Thanks!

[-] BackgrndNoize@lemmy.world 2 points 6 hours ago

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?

[-] mic_check_one_two@lemmy.dbzer0.com 4 points 4 hours ago* (last edited 4 hours ago)

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.

[-] WhyJiffie@sh.itjust.works 6 points 5 hours ago

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.

[-] Amir@lemmy.ml 1 points 5 hours ago

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)

[-] ayyy@sh.itjust.works 134 points 16 hours ago

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.

[-] fmstrat@lemmy.nowsci.com 9 points 11 hours ago

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.

[-] skisnow@lemmy.ca 28 points 13 hours ago

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.

load more comments (10 replies)
[-] Ohh@lemmy.ml 3 points 8 hours ago

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.
[-] ramjambamalam@lemmy.ca 1 points 4 hours ago

Try it again. I bet their password reset service was swamped after sending the notice.

[-] Ohh@lemmy.ml 1 points 3 hours ago

No cigar still. Beginning to get a tiny bit nervous

[-] Patches@ttrpg.network 2 points 6 hours ago

I received it fine about an hour ago

[-] Kazumara@discuss.tchncs.de 2 points 7 hours ago

For me that worked, about 9 hours ago. Maybe there is more load now that the Americas are awake?

[-] boonhet@sopuli.xyz 19 points 12 hours ago

Hope they did actually delete my data when I deleted my account, but I don't think I use that password anywhere anymore anyway.

[-] bo5on@lemmy.dbzer0.com 7 points 11 hours ago

The hash was only exposed.

[-] JasonDJ@lemmy.zip 430 points 21 hours ago* (last edited 20 hours ago)
  • 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.

[-] Cocodapuf@lemmy.world 10 points 9 hours ago

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.

load more comments (9 replies)
load more comments
view more: next ›
this post was submitted on 08 Sep 2025
696 points (100.0% liked)

Technology

74944 readers
2836 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS