Server Version#: 4.147.1
Player Version#:
German news site mentioned that there are still open vulnerabilites in plex media server, CVE-2025-69414, CVE-2025-69415 and also in the plex.tv backend (CVE-2025-69416, CVE-2025-69417). Link to the news site: Plex Media Server: Noch ungepatchte Zugriffsschwachstellen | heise online.
I couldn’t find any information regarding these CVEs here in the forum and would like to know the current status of the mitigations.
Thanks!
Mathes
While the article claims this is vulnerabilities from „shortly after the security announcement in August 2025“… the CVEs were only raised / first received by NIST last Friday. Makes me wonder…
Does Plex, inc. have any information? Are these known issues, new or fixed?
Plex better get on top of this with a general statement as to whether the vulnerabilities indicated have already been addressed or not!
No news is good news?
Hello Plex team, can someone provide an update?!
I would think these types of posts should rise to the top of whoever monitors these forums!
I just scanned the plexinc/pms-docker:latest and linuxserver/plex:latest docker image and neither show that vulnerability. You can scan it yourself, too, to double check.
sudo docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image --severity LOW,MEDIUM,HIGH,CRITICAL --format table linuxserver/plex:latest
sudo docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image --severity LOW,MEDIUM,HIGH,CRITICAL --format table plexinc/pms-docker:latest
As someone whose full-time career is in security, reading the notes about the unpatched token management vulns is wild (and not just that they still remain unpatched). How are transient tokens being exchanged for permanent tokens? How are device tokens irrevocable? So many questions.
tl;dr: lmao so I guess I’m gonna sell my Lifetime Plex Pass and switch to an alternative media server (yes that one).
I’m hoping this silence means Plex is scrambling to get patches in place ASAP and then release PR.
The majority of these issues has been fixed for quite a while.
The only remaining thing is the /myplex/account endpoint. Let me remind you that in order to exploit that one, you need to have a valid access token in the first place – i.e. you need to be a legitimate user of that server.
It is currently being investigated if that endpoint can be removed altogether.
But first it needs to be clarified if it’s still being used by some client.
Thanks for the clarification that someone is looking in the remaining issues! Is there any update when this will be finished?
Thanks!
Mathes
Even if CVE-2025-69414 requires an existing transient token, plex.tv backend authorization flaws mean tokens may be retrievable or mis-scoped via backend APIs. In particular CVE-2025-69416 (device token can enumerate unrelated tokens via clients.plex.tv/devices.xml) and CVE-2025-69417 (share token leakage via shared_servers) indicate server-side authorization bypasses, not purely local issues.
Can you confirm whether these plex.tv API authorization paths are now fixed in production and whether token enumeration and share-token access are fully constrained?
Hi!
We have an issue open to stop both endpoints from returning tokens, now that we have verified that no instance of PMS or a Plex client is using them anymore. It should be patched in production soon.
That being said, let me also add that while returning tokens in these endpoints is bad practice (which is why we’re patching them), to retrieve such tokens you need to already be authenticated with a non-transient token yourself, that has similar (if not more elevated) credentials as provided by the other ones.
For example, getting tokens from shared_servers requires you to have a token associated with the server’s admin account. If you have that, you already have the keys to the castle. If you hit the endpoint on a server you’re not the admin of, you get nothing.
Sure, you can get different tokens, but if an attacker can hit those endpoints then the system was already compromised elsewhere.
I’m not trying to make light of a security issue. We take these seriously, and react with patching the more severe vulnerabilities as soon as possible. Others might get prioritized slightly lower, but get addressed nonetheless.
I hope that helps.
Please don’t remove the shared tokens from shared_servers. It is useful for the admin to be able to access their own server as another user through the API. For example, being able to change the audio/subtitle preferences on a show, or synchronizing playlists across users.
Hi,
in my Opinion it would help, in general sense, that Plex would provide this kind of information and their own view on the matter, in a more public form. At least when the topic gets published openly in the internet.
For me I can say that I don’t have a good feeling, that I and others have to ask in a forum for a comment on the matter and then wait for days to get some information on it.
I can understand that, if there is a responsible disclosure that you are not commenting on it till it is fixed. But if it is already published on the internet, to ask for information as a customer, is not a thing that makes me feel save with the product.
Mathes
Hi,
is there any news on this topic?
Mathes
What news are you expecting?
The remaining issue is very low-risk.
Hi,
maybe I was not good at reading between the lines in the other post above. But as there were some statements in the way of “some things are worked on” or “we are looking into removing the rest”, I assumed that we would get some kind of information if this is now done, or at least some kind of update like “we will do this in the next release”.
But taking your last statement that this a very low issue, I can now assume that nothing more will happen. So now I have to evaluate for myself, if I see it the same way and re-enable the internet access to my instance or not.
Mathes
Well, “fixed” would be good news to read. Together with info on which part of the API changed which way…
I don’t want to bother you, but if you mess with an existing endpoint (documented or not), it would be good practise to communicate changes to it.
