Is your Metabase 1.58+ installation leaking customer data right now?

09 August 2026 7 min read 1365 words

BLUF

Yes — if you run Metabase 1.58+ self-hosted and have not installed the August 6–7, 2026 patch, your instance may already be compromised. A previously unknown zero-day (CVSS 10.0) in an unauthenticated REST endpoint let an attacker inject arbitrary SQL into the Metabase application database and pivot to administrator access — stealing configuration, credentials for connected databases, and any data accessible. Framework (laptop maker) and Tally (form builder) disclosed customer data theft after Metabase notified them on August 6. The vendor patched Cloud automatically; self-hosted customers must patch themselves.

Key facts

Three GitHub Security Advisories published on the same day (2026-08-06): GHSA-vwf4-m7j8-wcjf (SQL injection via unauthenticated /api/session/reset_password endpoint, CVSS 10.0, Critical, actively exploited), GHSA-r8h2-qpfx-mx59 (SQL injection via publicly shared dashboard with field-filter, CVSS 9.6, actively exploited), GHSA-8hmm-hrhg-ppqp (low-privilege user reads the Metabase application DB, including bcrypt password hashes and — without MB_ENCRYPTION_SECRET_KEY set — stored credentials for every connected database in cleartext, CVSS 6.5).
Affected versions: Metabase 1.58 and above. Minimum safe releases per branch: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5.
No authentication required on the most severe vector (GHSA-vwf4-m7j8-wcjf) — only network reachability to the Metabase instance.
Publicly disclosed victims: Framework (full names, email addresses, login IPs, billing/shipping addresses, phone, company; for Framework for Business: company name, phone, VAT, EIN, billing email) and Tally (Metabase analytics environment compromised on August 3; full scope not disclosed at publication). LexisNexis notified customers about disruptions to Diligence, Metabase API and Newsdesk.
No CVE assigned at the time of publication — Metabase shipped GHSAs, CVSS 10.0, and the "actively exploited" flag. Temporary mitigation: block /api/session/reset_password until patched.
Primary source: Metabase Security Advisory (CEO Sameer Al-Sakran blog post + 3 GitHub Security Advisories). Independent sources: BleepingComputer, Framework and Tally customer notifications.

Decision table

Area	What we know	What it means for a B2B / manufacturing company	Recommended action (30 / 90 days)
Metabase infrastructure	Critical zero-day in an unauthenticated REST endpoint, publicly exploitable.	Any Metabase 1.58+ self-hosted instance exposed to the Internet (or reachable through a corporate VPN) was exposed from the release of 1.58 until the August 6–7, 2026 patches.	Immediate: patch to the nearest safe release in your branch. Within 30 days: audit network access to Metabase, segment it, monitor calls to `/api/session/reset_password`. Within 90 days: review all publicly shared dashboards and cards.
Identity and credentials	Theft of credentials for connected databases is possible (in cleartext if `MB_ENCRYPTION_SECRET_KEY` was not set).	An attacker could use stolen credentials to query production databases (Postgres, Snowflake, BigQuery, Redshift) directly, bypassing Metabase.	Immediate: rotate credentials for every connected database; set `MB_ENCRYPTION_SECRET_KEY` if it was not set. Within 30 days: enforce MFA for Metabase admin accounts. Within 90 days: move to a secrets manager with automatic rotation.
Data and privacy (GDPR)	Framework and Tally confirmed customer data theft (names, email, IP, billing, phone).	High risk of a personal data breach in the sense of GDPR Art. 33 (72h notification to the supervisory authority), depending on which datasets were visible through Metabase panels.	Immediate: review Metabase logs (24–72h back) for unusual queries, exports, admin account changes. Within 30 days: assess data scope, decide on supervisory authority notification. Within 90 days: DPO review + update of the record of processing activities.
NIS2 / national cybersecurity law — evidentiary obligations	A SaaS BI vendor breach propagates to its enterprise customers. The incident illustrates NIS2 Art. 21 (incident response + supplier risk management) and Art. 23 (notification deadlines).	Entities in scope of NIS2 must demonstrate that their BI SaaS providers are inventoried and that a 0-day response procedure exists.	Within 30 days: update the inventory of SaaS vendors with critical data impact. Within 90 days: add a "0-day at BI vendor" scenario to the BCP/DR plan, run a tabletop exercise.
Monitoring and detection	Metabase recommends reviewing logs, admin accounts, API keys, session history.	No public IoCs, but any non-standard admin activity (config change, export, new accounts) between August 3 and 8, 2026 is suspicious.	Within 30 days: audit admin accounts, review API keys, list connected databases. Within 90 days: alert on bulk exports (>X rows) and out-of-hours configuration changes.

Marcin Białczyk's perspective

In the last 18 months, I have seen three recurring patterns in incidents around BI and dashboarding tools: (1) publicly shared dashboard links (UUID in the URL, no login required — Metabase default), (2) missing MB_ENCRYPTION_SECRET_KEY in production deployments, which leaves database credentials in cleartext in the application database, (3) unauthenticated REST endpoints exposed "temporarily" for debugging that stay in place for years. All three patterns appeared in the advisories published on August 6, 2026.

I would not treat Metabase Cloud as "the vendor takes responsibility." Under NIS2 Art. 21(2)(d), the in-scope entity remains responsible for its SaaS supply chain — not the BI vendor. In practice this means within 72h of a public disclosure you should have: (a) a list of all connected databases with a sensitivity grade, (b) rotation of database credentials (not on the logic "nothing showed up in logs" — exploitation may not have generated noise at the BI layer), (c) an entry in the incident register with the hypothesis "potential access 3–6 August 2026, no confirmed exfiltration / confirmed exfiltration X". "We did nothing because there are no IoCs" is not a defensible position for a regulated entity.

Looking ahead: organizations with mature Continuous Readiness (TLP/NIS2) maintain a list of 20–30 critical SaaS vendors with a named business owner, an SLA review cadence, and a 0-day response plan. Where that list is missing, start there — because the next "Metabase Cloud" will land in a different category (CI/CD, observability, support tooling) and the same questions will need to be answered in 72h.

Frequently asked questions

Has Metabase Cloud already been patched?

Yes. Per Metabase's August 6, 2026 communication, Cloud customers were automatically upgraded and patched. Even so, Cloud customers should verify that no unauthorized access occurred during the 1–6 August 2026 window and that credentials for connected databases were not read.

What if I cannot patch within hours?

For GHSA-vwf4-m7j8-wcjf (CVSS 10.0): block the /api/session/reset_password endpoint at the reverse proxy / WAF. For GHSA-r8h2-qpfx-mx59: disable public sharing for any dashboard that exposes field-filter (dimension) parameters. After patching: review admin accounts, rotate connected database credentials, audit logs.

Did my Metabase user password hashes leak?

GHSA-8hmm-hrhg-ppqp lets a low-privilege user read the Metabase application database, including bcrypt hashes of session passwords. If MB_ENCRYPTION_SECRET_KEY was not set (the default), the same vector returns credentials for every connected database in cleartext. Treat it as a real breach — bcrypt hashes are themselves vulnerable to offline cracking if passwords are weak.

Do I have to report this incident to my supervisory authority?

That depends on the scope of data visible through your Metabase panels and the result of your log review for the 1–6 August 2026 window. GDPR Art. 33 requires notification within 72 hours if there is a risk to the rights of data subjects. Legal interpretation requires consultation with a law firm — CHORS does not issue independent legal opinions.

Is this a supply-chain incident that counts toward NIS2 obligations?

Yes. For entities in scope of NIS2 Art. 21(2)(d), supply chain risk management covers critical SaaS providers that process operational data. This incident is illustrative and should be filed in your incident register as an internal case study.

How CHORS.NET helps

If you are applying the Metabase patches and want to verify that your instance — and your BI infrastructure as a whole — was not exposed, CHORS.NET can help with internet exposure audits, network access cleanup, and preparing your organization for zero-day scenarios at SaaS vendors, including NIS2 readiness.

Scope and limitations

We are not a 24/7 SOC and we do not guarantee detection of every incident at a SaaS vendor; this content is informational and does not replace continuous monitoring.
We do not certify compliance with NIS2/KSC and we do not issue independent legal opinions. For legal interpretation CHORS works with law firms.
Facts reflect the state of knowledge on August 7, 2026. Metabase may publish additional advisories or a CVE in the following days — review before making final decisions.
This material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.