A European cloud company left a database open to the internet, and roughly 367,000 records spilled out. Misconfiguration is the most common way stored data leaks, and it is the case where encryption at rest actually earns its keep.
There was no zero-day and no ransomware crew in this one. Security researchers at Cybernews recently reported that Nextcloud GmbH, the German company behind the popular open-source cloud platform, had left an ElasticSearch database reachable from the open internet with no authentication in front of it. Inside were roughly 367,000 records, about 8 GB, a mix of employee data, client company details, contracts, and scripts built for customers. Some of it sat in the clear: staff and client email addresses, company names and addresses, and the details of people who had sent Nextcloud invoices.
To be fair to Nextcloud, the exposure was on its own corporate hosting, not inside customers' file vaults, and the researchers note the self-hosted open-source product was not the source of the leak. After Cybernews made contact, the company locked the archive within two days and notified the relevant authorities, attributing the incident to a hosting infrastructure misconfiguration. Handled about as well as these things can be. The reason it is worth writing about is not the company; it is the cause.
We tend to picture breaches as break-ins: a clever attacker defeating a strong lock. Far more often, the lock was simply left open. An access control set to "public" instead of "private," a storage bucket with default permissions, a test database that quietly went to production, an internal service that was never meant to face the internet. No exploit is required, because nothing was broken. Someone with a browser and a scanner just found data that was readable to anyone who looked.
That is what makes this class of incident so stubborn. You can hire the best team, patch on time, and run every audit, and one wrong setting on one server still undoes it. The attack surface is not just your code; it is every configuration choice made by every person and process that touches your storage, forever.
Here is the quiet assumption behind almost every storage leak: the data on the server is readable by the server. Providers keep files in a form they can index, preview, and search, which means the plaintext is right there whenever the access controls fail. When they fail, and eventually one of them does, the contents are exposed in exactly the form an attacker wants them. Encryption "in transit" and "at rest with a provider-held key" do nothing here, because the party doing the leaking is the party that holds the key.
A misconfiguration only exposes what the server could read in the first place. Make that ciphertext, and a leak spills noise.
There is a different design where the stored data is never readable to the operator at all. In a zero-knowledge, non-custodial system, files are encrypted on the sender's device before they are uploaded, and the servers hold only ciphertext. The encryption keys are generated on the user's device and never sent to the service. Set that same ElasticSearch cluster to "public" by mistake and the worst case is very different: an attacker walks away with encrypted blobs and no key, which is to say, with nothing usable.
This does not make you immune to mistakes. It changes what a mistake costs. Misconfiguration becomes an availability and hygiene problem rather than a confidentiality disaster, because the one thing an attacker needs, the ability to read the files, was never present on the server to be exposed.
SpaceBox Lite is built around exactly that boundary. Files are sealed on the sender's device with AES-256-GCM, and the keys are exchanged using post-quantum ML-KEM-768 (NIST FIPS 203). Your private key is generated locally and never reaches our servers, so what we store is ciphertext and nothing else. Senders need no account and hand over no personal data, so there is no directory of names, emails, and invoices sitting in a database waiting to be misconfigured into the open. If our storage were ever left exposed the way Nextcloud's was, the honest description of what leaked would be: unreadable bytes.
None of this is exotic. On-device encryption and non-custodial keys are established ideas, and plenty of tools use them. The point is narrower and more practical: when the breach is a misconfiguration, and it usually is, the only defense that still holds is the one where the data was never readable on the server to begin with. Store the ciphertext, keep the keys on the device, and a left-open door leads to an empty room.