117,206 Metabase Fingerprints: The Dashboard That Can Query the Warehouse

A business intelligence console is read-only in the sense that it does not write to production. That framing hides the actual risk. A BI tool receives database credentials so it can answer questions, and those credentials usually cannot distinguish between one question and all of them.

Context and method

Counts from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations.

The application fingerprint leads the title query by 9,186, about 8.5%. That direction is the more common one in this index, and the likely explanation is structural: Metabase serves a single-page application whose title is set by client-side JavaScript, so a scanner reading the served HTML finds the fingerprint and not the rendered title.

What the population represents

A reachable Metabase instance answers three questions for anyone who finds it: which databases it connects to, what questions have been saved, and whether the login page accepts anything other than a username and password.

The third is the interesting one. Metabase deployments vary enormously in authentication configuration. Some use the built-in login. Some delegate to LDAP, SAML or OIDC. Some permit new users to sign up, and once a user is inside, saved questions become visible according to collection permissions that frequently stay at the default.

The data behind those questions is the warehouse. A BI tool's database user commonly holds broad read access because narrowing it breaks dashboards, and the difference between reading one dashboard and reading every table in the schema is a single SQL editor tab.

The compromise path that matters

An attacker who reaches a BI console rarely needs a database exploit. The sequence is quieter: authenticate, browse saved questions for names that suggest source tables, then use the native query editor to run whatever the database user is permitted to run.

Two configurations turn that into a serious incident.

• A database user with read access to a schema holding personal data, combined with a login that permits self-registration.
• An instance carrying a known account on a shared password, which is common where a team installed the tool for an internal demo and never removed the demo account.

The secondary consequence is cached results. BI tools cache query output to make dashboards fast. That cache outlives revoked access unless someone reasons about it, and it sits on the same host that runs the query engine.

Distinguishing the two counts in practice

The gap of 9,186 instances is not trivia. It tells you which scanning method your own inventory should use. If you rely on page titles to find BI tools in your estate, you miss roughly the fraction that gap represents, because the title never appears in the served HTML.

That is a small, concrete lesson from a large number: pick the fingerprint dimension that matches how the product actually renders, and verify it against a host you own before quoting a global total in a report.

What to check on instances you find

1. Authentication configuration first. Whether self-registration is open is the one question that turns a console into a data breach.
2. The database user's grants. If the BI user can read every schema, the instance is a warehouse reader no matter what the dashboards display.
3. Saved questions and their visibility. Collections inherit permissions by default, and defaults are rarely reviewed.
4. Session and API key lifetime. Long-lived keys outlast the employee who created them.
5. Whether anonymous access is enabled for public dashboards, and what those dashboards show. It is the most common intentional exposure found on these hosts.

References

• ZoomEye search: https://www.zoomeye.org/
• Metabase documentation on authentication and permissions: https://www.metabase.com/docs/latest/