Plex Data Breach: 20 Million Users Forced to Reset Passwords

On August 24, 2022, Plex — the popular media streaming and management platform with over 20 million registered users — disclosed that it had discovered suspicious activity on one of its databases. The company immediately began an investigation and determined that a third party had accessed a limited subset of data, including emails, usernames, and encrypted passwords.

Plex forced a password reset for all user accounts, one of the most disruptive measures a platform can take, indicating that the company considered the risk significant enough to warrant universal action rather than targeted notifications.

What Happened

Plex's disclosure was brief. The company stated that it had "discovered suspicious activity on one of our databases" and that the accessed data included:

• Email addresses
• Usernames
• Encrypted (hashed) passwords

Plex emphasized that credit card and payment data were not stored on the affected database and were not compromised. The company also noted that passwords were "hashed and secured in accordance with best practices," though the specific hashing algorithm was not disclosed publicly.

The company did not reveal the attack vector — how the attacker gained access to the database — or the duration of the unauthorized access.

The Password Hashing Question

Plex's statement that passwords were "hashed and secured in accordance with best practices" raised the obvious question: which best practices?

Password hashing quality varies enormously:

Strong hashing (bcrypt, scrypt, Argon2): These algorithms are specifically designed for password storage. They are computationally expensive, meaning each password guess takes significant time and resources. A properly bcrypt-hashed password with adequate cost factor can take years to crack even with specialized hardware.

Weak hashing (MD5, SHA-1, SHA-256 without salt or work factor): These algorithms are fast, which is a desirable property for most hashing use cases but a critical weakness for password storage. Modern GPUs can compute billions of MD5 hashes per second, meaning weakly hashed passwords can be cracked in minutes.

Plex did not specify which algorithm was used. If the hashing was strong (bcrypt with cost factor 12+), users with strong, unique passwords had time to change them before cracking was likely. If the hashing was weak, many passwords could be cracked almost immediately.

The lack of transparency about hashing methodology — a common omission in breach disclosures — left users unable to accurately assess their own risk.

The Mass Password Reset Decision

Plex's decision to force a universal password reset rather than targeted resets for confirmed compromised accounts was notable. This approach:

Errs on the side of caution. If the company cannot determine exactly which accounts were accessed, resetting all passwords ensures complete coverage.

Causes significant user friction. Twenty million users forced to reset passwords means millions of support tickets, login failures on automated systems, and general frustration. For Plex, which is accessed through smart TVs, streaming devices, and automated media management tools, the impact on connected services was particularly disruptive.

Signals severity. A universal reset communicates to users that the breach was serious enough to warrant broad action, which can motivate users to also change reused passwords on other services.

Does not address credential reuse. If a user's Plex password was also used on other services, resetting the Plex password does not protect those other accounts. Users who reuse passwords need to change credentials everywhere that password was used.

The Timing Issue

The Plex breach occurred just one day after the LastPass breach disclosure (August 25, 2022), and in the same month as breaches affecting Twilio, DoorDash, and several other companies. August 2022 was an unusually dense month for significant data breaches.

This clustering creates breach fatigue — users bombarded with breach notifications become desensitized and may not take appropriate action (changing passwords, enabling MFA) because the volume of notifications makes each individual breach feel less urgent.

What Users Should Have Done

After the Plex breach, users needed to:

1. Reset their Plex password (forced by Plex)
2. Enable two-factor authentication on their Plex account
3. Change the same password on any other service where it was reused
4. Check Have I Been Pwned to see if their email appeared in the breach data once it was added
5. Move to a password manager if not already using one, to generate and store unique passwords for every service

The reality: most users probably completed step 1 (they had to), some completed step 2, and very few completed steps 3-5. This means the Plex breach likely contributed to credential stuffing attacks against other platforms for months or years afterward.

Lessons

1. Disclose hashing methodology. Users and security professionals cannot assess risk without knowing how passwords were protected. "Best practices" is not specific enough.

2. MFA should be the default, not an option. Had Plex required MFA, stolen password hashes would be significantly less useful to attackers.

3. Breach notifications should include actionable guidance. Telling users to change their password is step one. Telling them to change the same password everywhere else it is used is equally important.

4. Database access controls and monitoring are table stakes. The fact that suspicious activity was detected in a database suggests either insufficient access controls or insufficient monitoring to prevent the access in the first place.

How Safeguard.sh Helps

Safeguard.sh monitors your organization's exposure across breach databases, alerting you when employee credentials appear in newly disclosed breaches like the Plex incident. Our platform enforces password policies that prevent the use of known-compromised credentials and requires MFA for access to sensitive systems. By providing continuous visibility into credential exposure and enforcing authentication standards, Safeguard.sh helps organizations stay ahead of the credential-reuse problem that turns a single breach into a cascading security failure.