Yesterday (Sunday), we received an email through our Bug Bounty program that should make any CEO or CTO skip a beat: a report that a large amount of our users’ data had been leaked. What’s worse, it had been posted on a public forum (Leak Radar). The security reporter was helpful enough to attach a dump of what had been posted.

Upon inspecting the data in a clean room environment (just in case it was compromised), we discovered that the leak included almost 1,400 user accounts, complete with usernames and passwords in plain text.

This is where you start sweating.

A leak of such size usually means that the backend was compromised. We immediately started thinking about possible attack vectors that could lead to a leak of such magnitude.

As we dove into the data, it became clear that this was a “dirty” data dump, meaning that much of the data didn’t even make sense. We started filtering out data that didn’t make sense (e.g., usernames that didn’t match our structure), and then we de-duplicated this list.

We were now down to ~300 user accounts, which was less than 1% of our users. Still bad, but this changed the equation from “definitely something on our end” to it becoming plausible that these were either datasets with reused passwords and/or from compromised end-user devices (spoiler: it was).

The next step was to correlate the reported usernames with our actual data to see if they were even real accounts. At this point, we had already spot-checked and confirmed that at least two of the accounts existed in our system.

After writing some custom tooling, we were able to find the following:

• 228 of the ~300 accounts actually existed in our system
• 41 out of the 228 accounts had activity in the last year
• 5 of the 41 accounts were actual paying customers

The first thing we did at this point was to reset the passwords on all affected user accounts to minimize the blast radius of the leak (regardless of how it came to be). Note that this was within about three hours after the report — on a Sunday night. This is where I must give a massive shout-out to our CTO, who was leading this effort in the middle of the night in his time zone.

At this point, we had done the most pressing damage control to mitigate the blast radius of the leak. We could continue in the morning with the rest of the team.

While we started to reach out to the affected users, we simultaneously started looking at both the audit logs for these users and the patterns around them. For instance, were they all created or accessed around the same time? No immediate pattern emerged. Some were several years old, others were somewhat new. The vast majority of the accounts, however, hadn’t been accessed for a long time.

The plot thickens.

After investigating our internal systems, including access logs, we became confident that there was no breach in our system. If the breach was not on our end, where did the data for this leak come from?

Enter Have I Been Pwned. For those not familiar, Have I Been Pwned is an open database that allows you to monitor if you have been part of a data leak. They also have a great API available. Was there a leak that correlated with all these accounts? Turns out there was.

The vast majority of the 228 accounts existed in one of three leaks:

• Synthient Stealer Log Threat Data Breach
• Data Troll Stealer Logs Data Breach
• ALIEN TXTBASE Stealer Logs Data Breach

What’s important to note here is that all these sources are “stealer logs”, meaning that most of them appear to have been captured directly from compromised desktops. These are malware-infected machines where credentials were stolen from browsers.

With all this data, we became confident in concluding that this was not a breach on our end, but rather a combination of compromised end devices and reused passwords.

This is an attack vector that is difficult to protect against, but we believe we can better protect our users from this type of attack going forward.

What we are doing next

Even though this leak didn’t appear to have originated from an issue on our end, we still wanted to do better. We have supported SSO and Multi Factor Authentication (MFA) for many years. This certainly helps improve our overall security posture, but many users still choose not to use it. For instance, none of the users in the leak had MFA turned on.

Also, we can’t prevent users from reusing passwords from other services, which exposes their Screenly account even if we have the best security posture in the world.

So how can we make our customers more secure without adding more friction? Many services are moving to passkeys, a great technology we’re fans of, but we’re not convinced it would have changed anything in this scenario.

Instead, we decided to implement Magic Links and get away from passwords altogether. This is a well-established concept by now that is widely used. The way it works is very simple. Instead of creating a username and password, when you log in with your username (e.g., your email address), we will send you a Magic Link. When you click on this link, you will automatically be logged in. It’s straightforward and secure.

And the best part is that even if we were to be affected by a leak in the future, it would not be exploitable as we don’t even have passwords on file.

Work is underway on Magic Links, and we expect this feature to go live this week.

Timeline

• 2025-11-09 (Sunday) 19:21 UTC: Leak reported
• 2025-11-09 (Sunday) 21:00 UTC: Investigation begun
• 2025-11-09 (Sunday) 23:22 UTC: All affected users’ passwords were reset
• 2025-11-10 (Monday) 08:30 UTC: Investigation continues
• 2025-11-10 (Monday) 16:30 UTC: Investigation concluded