cloud storage
2 articles with this tag
Rakuten Drive breach (stored data of 15,382 accounts): what was accessed and what users should do
On October 6, 2026, the cloud storage service Rakuten Drive announced that a third party had illegitimately obtained the credentials of a management account for part of the systems the service uses, accessed the systems, and obtained and viewed information. Affected were the stored data (including photos and documents) of 15,382 accounts between January 29 and September 17, 2026; the account name, display name and profile image URL of 687 accounts on August 27; and, on the same day, the account name, display name, encrypted password, the string added during password encryption and profile image URL of 313 accounts. The service says no secondary damage has been confirmed and that it will notify affected users individually by email or other means. In an August 13 update about suspicious push notifications seen on July 30, the service had said that unauthorized third-party access to stored data had not been confirmed at that time. This site's take: unlike a password, stored files cannot be taken back. Check for a notice, treat any ID documents or contracts you stored as seen, change your password, and do not respond to messages, payment demands or threats claiming to be Rakuten Drive.
Cloud storage public exposure: when data can leak even with Block Public Access enabled
Bucket leaks come from configuration, not attack. The line that matters in the docs: block public access settings do not alter existing policies or ACLs — the public settings remain underneath the block, and removing the block restores public access. So the goal is not "blocking is enabled" but "nothing is public even with blocking off". Apply it at the account level, because a bucket policy can grant someone the ability to turn a bucket-level block off. And "public" is defined more broadly than people assume.