First, we apologize; we made a configuration error in our Object Storage provider after migrating from Backblaze B2 to iDrive e2. With this misconfiguration from March first to the ninth, we leaked the complete listing of our media buckets content. We were also asked not to make this information public until Mastodon Gmbh had a chance to publicly disclose, as they have informed several servers who also had this configuration issue. This was to ensure everyone had a chance to patch.

What was leaked?

This leak only contained our media assets, which means anything users uploaded to their posts. This would be your pictures, sound clips, gifs, and video clips you have uploaded to post for your followers and others to see. This part of the data isn’t that important, as this is mostly the stuff you have shared.

Another thing stored here is user data exports, generated upon a user’s request to dump their data. We keep this data for up to 30 days, which has now been refined to 7 days. What is included in this backup are:

• Avatar used at the time of export.
• Profile banner used at time of export.
• Public profile data, such as your follower count and metadata.
• List of all the posts you have made.
• Bookmarked posts list.
• Favorite/Liked post list.

These backups do not contain any of what is typically considered personally identifiable data. There were no emails(unless you listed them in your profile publically), and nothing related to your account was leaked, such as login information. All of that information is safely secured behind our secured servers.

What happened?

When we migrated away from Backblaze B2 storage to iDrive e2, the protocol that serves assets for us to provide to you was different. For example, Backblaze B2’s API doesn’t offer a complete directory listing all objects on public buckets. However, iDrive e2 is based on the Amazon S3 system, which API does do this.

Our bucket is set up as a private bucket with only two keys for access; one key is used for Mastodon to read/write to the Bucket uploads and cache from other servers. The other key is a read-only key placed on our CDN, allowing us to control access to the objects in the bucket. First, however, we should have checked if hitting the bucket through the CDN address gave a complete bucket listing. Unfortunately, it did, and once we were made aware, we locked down the CDN to only permit access to the images, videos, and audio from the bucket.

How we fixed it?

Since we only allow access to the bucket through our CDN, we have applied edge rules to the CDN to block access to the listing page and rules only to allow supported file extensions that should be served from the bucket. You will get a 403 error unless it is in the permitted extension list.