ZoomEye survey finds 703 exposed NocoDB instances fronting production databases

What the survey found

A post on dev.to describes a census of internet-reachable NocoDB deployments carried out through ZoomEye, a search engine that indexes exposed services. A fingerprint query for the application returned 703 matches when it was run on 29 September 2026 at 02:48 UTC, according to the post.

NocoDB is an open-source project that layers a spreadsheet-style grid over an existing database, which makes it attractive to teams that need structured data without building a custom application. That same property, direct access to live data with no application logic in between, is what makes the count of reachable instances interesting from a security standpoint.

Why the interface is the risk

According to the post, the tool attaches to a live database and serves its tables through both a web interface and an API. A person who reaches the interface can generally read and edit the underlying rows, and built-in export functions can produce an entire table as a downloadable file.

Two settings account for most of the exposure, the author writes. The first is a sign-up option left open, which lets any visitor register an account. The second is a share link or public view that was set up to make collaboration easy and then forgotten.

There is also an inheritance problem. Because the grid is fed by a production database, the sensitivity of that data carries through to the grid view just as much as to the source system. A table of user records or billing information does not become less sensitive because someone is browsing it as a spreadsheet.

What the number does and does not tell you

The 703 figure counts fingerprint matches, not confirmed breaches. Some of the instances are intentionally reachable, the post notes, while others are remnants of finished projects whose hosts were never decommissioned. The survey cannot tell a deliberate public deployment from an abandoned one, so the count is better read as an upper bound on the problem than as a list of incidents.

What operators should check

The post closes with a short hardening checklist:

• Disable public sign-up unless the instance is genuinely meant to serve external users.
• Audit every shared view and revoke the ones no longer needed.
• Connect the platform to the database with a restricted account holding only the permissions the application actually uses, rather than a database owner credential.
• Turn on activity logging and pay attention to exports, because large downloads tend to happen before anyone reports a problem.

Why it matters

The story illustrates a recurring pattern in deployment security: tools that put a friendly interface in front of a powerful back end inherit the back end's sensitivity but not necessarily its access controls. The likely failure mode here is not a flaw in NocoDB itself but a misconfiguration, such as an open registration page or a stale share link, that turns a production dataset into something a stranger can browse and export wholesale.

For any team running self-hosted data tooling, the checklist generalises well beyond this one product: least-privilege database credentials, self-registration switched off by default, and periodic review of anything exposed publicly. A single fingerprint query on a public search engine is all it takes for an outsider to find an instance that was never meant to be found, and the 703 matches suggest that this is already happening across hundreds of deployments.