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
-
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.
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.
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.
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 admitted the issue because they’re a German company and they would get fined 20 million euros if they didn’t.
Edit: I was wrong, it’s not German
they’re a German company
Unless there is a town called “German” in California, they are not.
You’re right, I’m sorry. I was misremembering.
-
Man. My decision to go with Jellyfin just keeps paying off more and more
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…
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 :)
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”
I mean jellyfin is as easy to install as clicking “install” in the default software manager at least on Linux
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
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…
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.
Same with Plex, except more serious, they have data breach after data breach and I read comments here of people applauding the response and probably most will continue to use it.
If your threat model includes being scared people are gonna guess whats on your server and try playing it, then thats up to you, personally It’s not something I’m worried about in contrast.
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…
I think the only advice I have seen is to use jellyfin behind a reverse proxy (instead of directly exposing it), because they are hardened.
Where have you seen this official advice for a vpn?
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.
If they don’t have a team, they don’t regularly look, if they dont look, they don’t report, if they don’t report your analysis maybe biased because you can only check about what you know…
I hope you can see my point
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.
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’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.
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.
The salt is part of the password hash
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.
I guess I’m going to find out if they really deleted my user data when I asked them to
Wellllll, we’re all waiting
So far I haven’t gotten any email from them. I’ll try to login later with my old username and password.
EDIT: Tried and they said username or password is incorrect. Since I’m using a password manager I’m confident those were what I used so maybe they really did delete it.
Accounts can be deactivated without being deleted.
They are a German company so they must follow the GDPR. They shouldn’t have your email anymore.
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.
That’s also a viable solution, but for me I just use Btrfs snapshots on my NAS. My files are stored on a different device and the Jellyfin container only sees them as a mounted dir, not even aware that it’s an SMB mount.
🍮🇫🇮
OK, coming from a Jellyfin user for years, its not like it’s impervious to any attacks.
Just installed that yesterday lol
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.
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…But brooo, don’t you know you need to have a cloud login. You neeeeeed it broo, so they can have all your info leaked bro. How else can I give access to somebody if I don’t pay 200+ bucks for the privilege of accessing my own library bro.
Data leaks happen bro, no need to worry it’s the third time in a decade. This is a text book pro response anyway, they deserve more money bro.
How dare you suggest people use another software bro, they deserve your money each month, not these leeches giving you free software. Plus Plex is so much more secure anyways, just look at them getting hacked bro. Your jellyfin is so insecure you need a PhD in cyber bro-security to even think about doing it. Look at all the jellyfin instances getting hacked every day. Someone could even guess a UUID and access 10s of playback of my pirates movie bro, see how it’s so full of holes bro
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.
Yep same here, I already got a brand new credit card with a brand new number because my renewal got stuck in a postal strike lmao
The best solution would be to migrate to Jellyfin altogether
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?
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.
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.
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)
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.
Then how would they email you?
Look at addy.io and similar.
Ideally, they wouldn’t
Decode like any other PII, so it is encrypted at rest and when stolen.
Encryption and hashing are different things. You can’t get the original back out of a secure hash. They’re used only to confirm that whatever piece of data you have now matches the one that was provided originally, because they produce the same hash. You can’t store hashes for any data that you ever want to be able to read.
Yeah I want thinking when I wrote that. But the idea still stands encrypt the emails.
e-mail hasing is viable if you are only using your email for sign in and account recovery. Unfortunately it’s not happening because every service would also want to send you periodical emails about other stuffs.
So not hashed, and readable through whatever API accesses it anyway.
I agree addy or simplelogin, etc are great.
I started using an email forwarding service when I setup a new email a few years ago and I still have zero spam, because as soon as one service sends one too many marketing emails that I can’t turn off, I simply disable the email alias I used with them (and enable it again if needed down the line).
This is the only way because no website, etc is gonna keep your email address safe and secure, because they don’t really care about you.
Using aliases everywhere also makes it hard to track you based on your email (assuming services share this between each other, advertisers, etc).
You must have a lot of trust in the email forwarding service you use though and I probably wouldn’t use them for anything very important like banks, etc.
What does hashing an email address mean to you? Please be specific.
I used a dump email account to set up my Plex so it really doesn’t matter if hackers have it.
I set mine up in 2012 maybe? So been a long time… But in general not just plex.
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.
I think you mean Plex got hacked AGAIN
lol
Easiest decision to delete an account I’ve ever made.
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.
Really that often? I guess their good and quick response has been engineered through lots of experience…
At some point, can you keep yourself using a service that constantly gets breached? I’d just be worried when the next one is coming, based on this record (that i havent verified for myself, gonna trust u bro).
I was going to get some links for you, but conveniently The Register already did that for me:
Thank you and yikes
They say that passwords are hashed but were 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.
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.
Nevermind the credit cards, it’s the viewing habits they can sell that really make money.
The fact that this is a real IT question and not a culinary review is hilarious
Even better that one of the responding comments is written by Barbecue Cowboy