Technology

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.

The best solution would be to migrate to Jellyfin altogether

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.

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 enjoy using Jellyfin and hope it continues to improve, but it has some problematic security of its own.

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.

Nevermind the credit cards, it's the viewing habits they can sell that really make money.

They admitted the issue because they're a German company and they would get fined 20 million euros if they didn't.

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.

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

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.

If you have Synology.

Uninstall(without delete) and reinstall Synology.

It will allow you to log back in.