I don’t see 3 as a problem really? Server administrators are always able to modify standard user settings/content if they need to. In this case, it’s your Plex server and a friend’s access token for your server only, that can’t do much anyway…
As an example of how great it is to be able to use these tokens, if I share my Plex server with someone I’m able to use a little script to create an IMDB top 200 playlist (with films from my server) under their account (plus other stuff).
I’m leaning towards agreeing with Plex on this.
This isn’t the only API endpoint that can list tokens. Off the top of my head, I can think of 3 other API endpoints that are used to retrieve a token for various valid use cases. All three of those are accessible using a regular admin token (not the special PlexOnlineToken).
Can you give a set of steps to reproduce what you’re seeing with #2?
That’s exactly what should not be possible in a secure setup. You’re manipulating the account of a friend!
Not for a 100% right now, since not all tokens are affected. But you can try the following:
Call the API https://plex.tv/api/v2/server/access_tokens?auth_token=xxx and note down all the tokens. Then reset the password and choose the option to disconnect all devices. Then login again into all of your devices (including the server itself). Check then this API again. In my case 3 tokens were matching to previous. The other devices had received a new token.
Were the “createdAt” dates updated? If, after changing your password and signing out of all devices, and then just signing back in to your server/web client, you retrieve the list of tokens, are your previous tokens listed (without signing back in to those devices specifically)?
It’s just following a normal admin/standard user permission model - you’re a server administrator, giving access to a system you own, to standard users. On every system an administrator can modify standard user settings, reset user passwords and generate new tokens of whatever kind is appropriate for said system (etc).
Maybe I’m not understanding your possible solution, but all incoming requests to your server must be authorised - every action must provide authorisation proof (and handle it quickly because performance is critical). Users who have access to your server do this by providing server specific access tokens in each request. If you sniffed the incoming network traffic you’d see them.
Ultimately this isn’t a security risk to you as a server owner, nor are you storing data for users that is sacrosanct and needs to be obscured even from yourself. You don’t have their password for authentication, only the token they’re using for authorisation to access your own machine. Would you really mind if your mate who gave you access to his collection of Linux ISOs and family photos had the access token you were using to view his things? 
Thinking about it from a different angle; that request to Plex you make is returning a list of all the access tokens that can access your system. Why wouldn’t you want to have a traceable list of these?
EDIT: As for token lifetime, yes this could likely be improved if they linger for exceptionally long times…
Can you provide me one of this APIs?
Take a look at what python-plexapi and Tautulli use.
Ok. What about the following:
We know, that someone (attacker) had access to our servers using the admin token (we have seen this in the logs). Therefore we changed the password and signed out all our devices (lets assume for a second, that this works correctly).
Then the attacker had access to the API and could collect / store not only my tokens, but also (non admin) tokens from my friends (to access my server content).
As far as I can see here is that only my tokens are re-generated but not the friends tokens used to access my server.
→ So the attacker has still access to the content of my server (using a token of my friends), right? Not to the server settings, but to the media content.
I’m sorry but the more I think about this it screams a 3rd party app breach or another low level breach of the core OS/phone/whatever…
can anyone give me update to this problem? is it being fixed?
Which problem? The problem, as originally stated, has been shown to be inaccurate. Plex is not scanning for wallets. Systems have been independently compromised through, as yet, undetermined means.
There were two issues identified:
How is there no standard “sigh” emoji available yet. 
will have to do, though it’s a bit stronger than I’d like.
The “fixes” mentioned in point #2 above were new logging changes intended to help identify occurrences of credentials/tokens being misused per #1. Which has not been shown to be a security issue in Plex in any way to this point.
The fix I mentioned was that the “Preroll” feature can/could be used to steal non-Media files from the server.
I did miss that, mea culpa. And I apologize for the condescending tone of previous comment.
For the issue about tokens not resetting on a password change, this is intentional. If you have a lot of devices, it could be a pain to relink/re-sign in on every device just because you change your password.
However, if you really do want to reset your tokens, there is an option for that.
@anon18523487 i believe @martinr92 was saying that even checking that box that he was seeing reuse of certain tokens. see post from 6 days ago by him.
What about getting API access via the guest account even if it’s disabled? I seen another post of a user able to sign in to their app via guest even when it’s disabled. Dunno how accurate the post is but might want to look into this…
Please give the source of this statement.
Strictly speaking there is no “guest” account. Guest is just a special “managed user” inside your Plex Home. So to “sign in as guest”, you first have to sign in as a regular Plex user account and then later Switch User to the guest account.
