Security Announcement, January 24

On January 23rd, some forum users reported seeing other buckets which didn’t belong to them. This
technical issue has been classified as “mild” and stems from an issue with Golang range variables on array types (we’ll be sharing more on this in the coming issues, as well as the lessons we’ve learned and the details about the fix.) This issue caused some bucket names to appear in the satellite web console (bucket page) for some users that did not create those buckets. None of the data or metadata in these buckets was exposed. Only the names of buckets, egress used, storage used, and object count were exposed.

Our awesome team worked overnight to figure out the issue, and get a fast resolution. Special thanks to Storjlings @littleskunk, @zeebo, krista, @Egon, @thePaul, @Brandon, @stefanbenten @keleffew and @calebcase

Please note that you may always follow our status at
Bugs and issues can be reported to
We take these kinds of issues seriously, whether mild or severe.

In summary, the data exposed was only the names of buckets, egress used, storage used, and object count. No data or metadata was exposed.

We’ll continue to post updates. Please stay tuned for further posts.


Can I ask you about public RCA report of this issue?


Thanks for the feedback and the quick resolution. Glad to hear it was limited to just bucket names.

With these things it’s always good to know you’re the only one with access to your encryption passphrase, so there is no mistake that can be made on the satellite or storagenode end that will actually give access to any data.

1 Like

Hi @Odmin thanks we are working on a more detailed piece, but for now I wanted to get the mst imprtant information to the community. We’ll be publishing a blog post as soon as its ready. Thank you

@brightsilence Yes, agree. While we take every report seriously, it is also good to know that the encryption is baked-in . thanks

1 Like

No problem, I just pay attention, that level of this problem is another that we have before and require RCA report (public and internal). It best practice for any security incidents. At this moment it less sensitive because we not on production, but the process of tracking security incidents should be like on production :wink:


It’s great to see the issue was picked up from the forum, and I’m loving the very professional status page and processes behind it! Definitely showing some maturity is incident management. :+1:


If anyone happens to encounter @zeebo on the forum, feel free to throw some extra sunshine his way – he is the amazing engineer who diagnosed and fixed this issue in record time (28 minutes!)