Open Databases: Six Years Later, Why the Fuck Are We Still Talking About This?

I’ve been covering cybersecurity for years, and I have a question: why the fuck are we still talking about databases and other systems being left open to the internet? This isn’t a new technique or a mysterious attack nobody could have anticipated. It’s the same preventable category of mistake returning with different companies, different platforms and different victims.

The latest example that set me off involves CSC Telecom. Cybernews researchers reported finding a publicly accessible database containing more than 125 million SMS records, with messages dating from October 2022 through September 2026. Think about what a text-message provider may handle: telephone numbers, message contents, notifications and sometimes authentication codes. A service that handles communications for other organizations has a responsibility to protect them.

There is an important distinction. A database being exposed does not prove criminals downloaded it. Investigators have not established that CSC Telecom’s records were exploited. SEB also said its use of the provider was limited to general pension-fund information, not online banking passwords, authentication codes or account details. Those facts matter. But they do not make a publicly accessible message database acceptable.

We’ve been here before

I was writing about unprotected databases by March 2020, when I covered the Rogers ISP incident, and again in April when I wrote about another database putting more than 1.1 million people at risk. In November, I covered the Pray.com exposure, and The Security Box discussed it too. That case involved improperly secured cloud data rather than necessarily an open database in the narrow technical sense. The broader lesson was the same: information that should have been protected was reachable by people who should not have had access.

By January 2024, I was writing about a MongoDB database associated with an estate application that had reportedly been exposed. In March 2024, reporting about an SMS-routing provider’s exposed records raised a particularly uncomfortable question: what happens when the codes people depend on to protect their accounts can be viewed by outsiders? These aren’t theoretical concerns. The very systems intended to serve customers can become a route to exposing them.

Then came Total Fitness. In June 2024, researcher Jeremiah Fowler reported finding a database containing roughly 470,000 images associated with the gym chain, accessible without a password. Reports described sensitive identity documents among the material. Total Fitness disputed the characterization and extent of the exposure, said it secured the database, and reported no evidence of access by unauthorized people beyond the researcher. Fair enough; we should report the company’s response. But why was the material reachable in the first place?

Different year, same question

In January 2025, my blog headline practically wrote itself: “You’ve got to be kidding me … another two databases open but now closed?” That wasn’t the first time I’d asked why organizations were still making these mistakes, and it certainly wasn’t the last.

In September 2026, UpGuard published research identifying 16,326 Supabase databases with publicly readable tables among roughly 300,000 candidate domains. Some exposed personally identifiable information. The researchers described examples involving private messages, customer records and even plaintext passwords. This wasn’t simply a story about somebody forgetting to set a password. It involved how developers configured access policies, including row-level security. Publicly usable application keys are not substitutes for authorization rules.

And now CSC Telecom brings us back to messages, phone numbers and sensitive communications. Six years after the Pray.com story I covered, I’m still reading about information exposed because systems were not properly restricted.

A password isn’t the entire answer

When I say a database shouldn’t be open, I’m not claiming that slapping a password on everything solves security. It doesn’t. Systems need appropriate authentication, authorization, network restrictions, secure defaults, reviews before launch, monitoring and periodic testing. The organization should know what data it holds, who can reach it and whether anonymous users can retrieve records they have no business seeing.

Cloud services and modern application platforms can make development easier, but easier deployment does not remove responsibility. If an application collects names, messages, identity documents or authentication-related information, the people operating it need to verify that its access controls work. That includes checking from the perspective of someone who is not logged in. It also means treating a researcher notification as a warning that the preventive process failed, not merely a ticket to close.

How many more times?

I’m glad when researchers responsibly report exposures and organizations close them. That is better than leaving them open. But “we fixed it” is the beginning of accountability, not the end. What failed? How long was the information accessible? Was access logged? Who is notifying affected people? What will change so this doesn’t happen again?

I don’t need to claim every exposure became a criminal breach to be angry about the risk. I don’t need to identify the first podcast where I called this a one-time problem, either. The dated articles and research already show how long the subject has been with us.

So here’s my question to the people building, deploying and managing these systems: why are researchers still discovering preventable exposures after customer information is already sitting in public view? Why aren’t these checks happening before deployment?

Six years of talking about exposed data is more than enough. I’d much rather report that organizations learned the lesson. Until they do, I’ll keep asking the same damn question.

Related reporting and earlier coverage

CSC Telecom: Cybernews investigation

SEB statement on the CSC Telecom incident

My November 2020 Pray.com coverage

My January 2024 MongoDB coverage

My January 2025 commentary on two exposed databases

My March 2020 Rogers ISP coverage

My April 2020 database coverage

My June 2024 Total Fitness coverage

Total Fitness exposure reporting

UpGuard's Supabase research