The bucket got popped. The only question that matters is what walked out the door
When a storage provider is breached, the headline is always "millions of records exposed." The detail that decides whether your files are now in a Telegram channel sits below the fold: what form the data was in when the attacker reached it. In nearly every 2026 case, the answer was readable. Passport scans and verification selfies, sitting in an object store the attacker could just aws s3 cp down. Zero-knowledge storage changes that one variable. The provider holds ciphertext and nothing that decrypts it, so the same breach hands the attacker unreadable blobs. Not invisible. Unreadable. There's a difference, and this post is honest about where it ends.
What actually leaked in 2026
Three cases, one root cause, escalating stakes.
In Japan, the hotel check-in platform Tabiq (run by the startup Reqrea) left an Amazon S3 bucket — literally named tabiq — publicly readable. Researcher Anurag Sen found over a million guest passports and driver's licenses, plus the facial-verification selfies hotels use for contactless check-in, that anyone with a browser and the bucket name could pull. No credential theft. No exploit chain. The bucket was just open, with files dating back to early 2020.
In February, scans of roughly 700 attendees' passports from Abu Dhabi Finance Week turned up on an unprotected cloud server — among them former UK prime minister David Cameron and hedge-fund manager Alan Howard. A security researcher found it with off-the-shelf bucket-scanning software; organizers later blamed "a vulnerability in a third-party vendor-managed storage environment," and secured it only after the press asked.
And the serious one. The European Commission breach traced back to March 19, 2026, when attackers obtained a secret API key for the Commission's AWS account through a poisoned build of the open-source scanner Trivy. CERT-EU and ENISA attributed the intrusion to the group TeamPCP; the extortion crew ShinyHunters then published the dataset on March 28 — about 91.7 GB compressed, roughly 340 GB uncompressed. It hit the europa.eu platform that hosts sites and publications for EU institutions, exposing names, email addresses, and email contents, with at least 29 other EU entities implicated beyond the Commission itself.
Notice what every one of these shares. The attacker reached the storage layer, and the storage layer held the data in a form the attacker could read. That is the normal case. "Encrypted at rest" — the checkbox almost every provider ticks — did nothing here, because the provider also holds the key that undoes it. Encryption the host can reverse on demand is encryption the host's attacker inherits.
What zero-knowledge actually changes
Zero-knowledge (the engineering term is end-to-end encryption with client-held keys) moves the encryption boundary off the server and onto your device. Your file is sealed before it leaves your machine. Beebeeb encrypts each file with AES-256-GCM in the browser or the bb CLI, under a key derived from your passphrase with Argon2id tuned to 256 MiB of memory, then wrapped for sharing with X25519. Keys are zeroized from memory after use. The server stores the ciphertext and the wrapped keys, never a plaintext byte and never the password — login runs over OPAQUE, so even the authentication step doesn't hand the server a credential to lose.
Run the three 2026 breaches against that. An attacker who walks off with a beebeeb storage bucket gets AES-256-GCM blobs. To turn one back into a passport scan they'd need the per-file key, which is wrapped under a key they don't have, which derives from a passphrase that was never on the server. There's no plaintext directory to read and no host-held key to misuse, because the contents are opaque to the host by design. This is the property that separates beebeeb from Dropbox, which holds your keys and can read your files — and from iCloud, which is not zero-knowledge unless you specifically switch on Advanced Data Protection. With ADP off, an iCloud bucket breach is a plaintext breach, same as the cases above.
So is zero-knowledge storage immune to breaches?
No. Anyone who tells you otherwise is selling. Two honest limits.
Metadata leaks even when content doesn't. A breach of the storage layer still exposes what the server legitimately knows: object sizes, upload timestamps, which account owns which blob, whether a share link exists. We minimize this, but we can't encrypt a file's size to ourselves and still bill you for it or stream it back. If you upload passport-scan.jpg, the filename is encrypted, but a 2.1 MB object created at 14:03 is still a 2.1 MB object created at 14:03. For most people the content protection is the whole game. If your threat model includes traffic analysis, you should know the residual exists rather than be told it doesn't.
Your device is still your device. Zero-knowledge protects against a provider-side breach — the bucket, the database, a rogue admin, a subpoena to the host. It does nothing against malware on your laptop or a stolen, already-unlocked session, because on your authenticated machine the data is, correctly, decryptable. That's a different problem with different defenses, and it's the honest other half of the picture. We write about both on the security page.
The point
The Tabiq, Abu Dhabi, and Commission leaks weren't sophisticated. Two of the three were open buckets. They were damaging because the data was readable the instant it was reached — the standard arrangement when the host holds the keys. Zero-knowledge doesn't make you un-breachable; it makes a breach of the host produce ciphertext instead of passports. A worse afternoon for the attacker, a much better one for you.
For context: AWS S3 Standard runs about $0.023/GB-month in us-east-1, and most providers built on top of it still hold your keys. Beebeeb's 14-day free trial is zero-knowledge by the same architecture as every paid tier — if you want to see what "the host literally can't read this" looks like in practice, that's documented on the security page.