Tools / News / Nextcloud GmbH Leaks 367,000 Internal Records Through a Misconfigured Elasticsearch Cluster
Press

Nextcloud GmbH Leaks 367,000 Internal Records Through a Misconfigured Elasticsearch Cluster

· VaultTools

Cybernews researchers found an unprotected Elasticsearch database belonging to Nextcloud GmbH holding roughly 367,000 records (8GB), including invoices, contracts, employee details, and client setup scripts. The exposure was disclosed publicly on July 8, 2026; even the company behind the self-hosted cloud got a hosting configuration wrong.

VaultTools · July 16, 2026

A rack of server equipment in a dark data center, the kind of infrastructure where a single configuration mistake can expose an entire database. Photo on Unsplash

Table of Contents

What Happened

Nextcloud GmbH, the German company behind the widely used open-source self-hosted cloud platform, left an Elasticsearch database publicly accessible on the open internet. Security researchers at Cybernews discovered the exposed cluster on May 18, 2026 and reported that it held around 367,000 records totaling 7.92GB of data.

The irony is hard to miss. Nextcloud’s entire pitch is data sovereignty: run your own cloud so your files do not sit on someone else’s servers. Yet the company’s own hosting infrastructure was misconfigured in a way that put internal business data one URL away from anyone who looked. As the Cybernews team put it, “If our team could find the exposed data set, then attackers could have done so too.”

What Was Exposed

According to Cybernews, the leaked dataset mixed company and customer material: invoices, contracts, employee details and email addresses, client company names and addresses, and setup scripts built for corporate clients. Some of the information was unencrypted.

Heise online reported the same picture, describing roughly 360,000 entries and 8GB of data covering “Nextcloud customers, partners, and employees, along with contracts and scripts for corporate clients.” SC Media noted that researchers cautioned automated bots frequently scan the internet for exactly this kind of misconfiguration, so the data may have been copied before it was secured even though Nextcloud found no evidence of misuse.

The Disclosure Timeline

  • May 18, 2026 — Cybernews researchers discover the publicly accessible Elasticsearch cluster.
  • May 25, 2026 — the researchers notify Nextcloud GmbH, according to heise online.
  • May 27, 2026 — Nextcloud closes the gap and notifies the supervisory authorities.
  • July 8-9, 2026 — the exposure becomes public through Cybernews, heise online, and SC Media coverage.

The window between discovery and lockdown was short. The window between exposure and discovery is unknown, and that is the part no one can audit after the fact.

Nextcloud’s Response

Nextcloud attributed the incident to “a misconfiguration of the hosting structure” and stressed that “the open-source collaboration software and its users were not affected.” No customer-run Nextcloud servers were involved, and the company stated: “We are not currently aware of any case where the data was misused.”

That distinction matters and is fair to Nextcloud: the product was not breached, the company’s own hosting was. The response was also fast, with the database locked down two days after notification. But the episode still lands as a cautionary tale, because it shows that even an organization whose core competency is running file infrastructure can misconfigure a database.

Why This Matters for Browser-Based File Tools

The lesson is not that Nextcloud is careless. It is that server-side storage always carries configuration risk, no matter who operates it. A privacy-focused company with strong incentives and real expertise still ended up with 367,000 records on the open internet, because every database, bucket, and cluster is one settings change away from public.

Files processed entirely in the browser do not have this failure mode. When a PDF is merged or an image is compressed locally via WebAssembly, there is no upload, no server-side copy, and no Elasticsearch cluster holding the residue. Nothing needs to be locked down later, because nothing was ever stored. For one-off file tasks, the safest infrastructure is the kind that does not exist.

Sources

← Back to all news