In mid-May 2026, security researchers scanning the internet for exposed systems found something that shouldn’t have been reachable at all: a database belonging to Nextcloud, a major European cloud collaboration company, sitting fully open on the public internet with no authentication required. No password. No login screen. Anyone who found the address could browse straight in.
How the Attack Unfolded
Inside was roughly 367,000 records totaling about 8 gigabytes: staff email addresses, client company names and addresses, customer contracts, invoice-related correspondence, and internal scripts the company had built for specific clients. Some of it, notably, sat completely unencrypted, meaning sensitive contact details were readable the moment anyone opened the file.
The company traced the cause to what it called a misconfiguration of its hosting infrastructure, not a flaw in its actual product. Once notified, Nextcloud secured the exposed database within two days. The incident became public roughly two months later.
Why This Matters If You’re Not a Big Company
It’s tempting to read a story about a major cloud company and assume the lesson doesn’t apply to a smaller business. It’s actually the opposite. This wasn’t a sophisticated hack. Nobody breached a firewall or exploited a zero-day vulnerability. A database was set up, and at some point in that setup, a setting that should have required a login was left open, the same category of mistake that happens constantly when any business spins up a new cloud service, a new database, or a new file share and moves fast to get it working.
The researchers who found it made the uncomfortable point directly: if their team found the exposed data through routine scanning, malicious actors likely could too, because bots scanning the internet for exactly this kind of misconfiguration run constantly, at scale, with no target list required. An open database doesn’t need to be found by someone looking for you specifically. It just needs to be found.
What Actually Would Have Stopped This
The fix here isn’t exotic. It’s a review step that many businesses skip specifically because cloud services feel like someone else’s responsibility to secure once you’ve signed up. They aren’t. Every cloud database, storage bucket, or search index a business spins up needs its access settings explicitly verified as private, not assumed private by default, because defaults vary by provider and by service, and a single missed checkbox is functionally identical to leaving a filing cabinet unlocked in a public lobby.
The second piece is routine, ongoing scanning of your own external footprint. The same techniques researchers and attackers use to find exposed systems are available to run against your own organization proactively, and catching a misconfigured database yourself, before anyone else finds it, is the difference between a quiet fix and a public disclosure.
Security Checklist for Your Business
Explicitly verify access controls on every cloud database, storage bucket, and search index, don’t assume a service is private by default.
Encrypt sensitive data at rest, not just in transit, so a misconfiguration exposes far less even when it happens.
Run regular external exposure scans against your own domains and cloud infrastructure to catch what an attacker’s scanner would find first.
Review access settings any time a new cloud service is stood up, especially ones spun up quickly to solve an immediate problem, since speed is exactly when this kind of setting gets missed.
None of this requires enterprise tooling or a dedicated security team. It requires treating “is this actually private” as a question to verify, not assume, every time something new gets connected to the internet. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.



