On August 2, 2026, a zero-day vulnerability struck Metabase Cloud, the open-source business intelligence platform, compromising unauthenticated administrative access through the /api/session/reset_password endpoint. Metabase confirmed active exploitation on August 6 with security advisory GHSA-vwf4-m7j8-wcjf, assigning CVE-2026-72898 with a CVSS score of 10.0 in both version 4.0 and 3.1. The maximum severity stems not only from ease of exploitation — remote, no credentials, low complexity — but from Metabase's architectural role as a centralized data access hub: compromising an instance means inheriting stored credentials for every connected database.
- CVE-2026-72898 enables unauthenticated SQL injection on the
/api/session/reset_passwordendpoint, resulting in administrative privilege takeover of the Metabase instance - Metabase confirmed active exploitation starting August 2, 2026, with an estimated 4-hour duration for the Cloud incident; confirmed victims include n8n, Kilo Code, and Framework
- The CVSS 10.0/10.0 score (CVSS 4.0 and 3.1) reflects complete impact on confidentiality, integrity, and availability, with changed scope due to effects on connected resources
- CISA added the vulnerability to the KEV catalog with BOD 26-04 deadline set for August 14, 2026, for U.S. federal agencies
The Mechanism: From SQL Injection to Total Data Layer Control
The flaw lies in the absence of prepared statements in the password reset endpoint, which processes user input by inserting it directly into SQL queries against Metabase's application database. A remote, unauthenticated attacker — as documented in the CVE.org record — can inject arbitrary SQL via the /reset_password endpoint and gain administrative access to the connected instance.
From the admin panel, the attacker can modify configuration, steal stored credentials for connected databases, read accessible data, and export it. This is the crux of the risk: Metabase is not an isolated application but a unified access layer connecting to warehouses, transactional databases, and data lakes. Metabase CEO Sameer Al-Sakran provided a precise indicator of compromise: a log sequence showing POST /api/session/reset_password returning HTTP 400, followed by GET /api/user/current with HTTP 200, indicates likely instance compromise.
Blast Radius Multiplication: When BI Becomes Data Supply Chain
The most dangerous aspect of this incident is the architectural multiplier effect. Compromising Metabase doesn't just mean losing data on the platform: it means obtaining keys to access all upstream systems it queries. Organizations use Metabase to centralize analytics across heterogeneous databases — PostgreSQL, MySQL, Snowflake, BigQuery, Redshift — storing connection credentials in the application configuration.
Confirmed victims illustrate this pattern. n8n, a workflow automation platform, revealed the attacker obtained 136 customer records, including 5 with bcrypt-hashed passwords and 25 cloud accounts with passwords stored in plaintext due to a historical bug fixed in April 2023 — the latter contacted as a precaution, with no evidence of actual access. Kilo Code confirmed exposure of customer records and Slackbot tokens for a subset of users, with the Metabase Cloud incident occurring in an approximately 4-hour window on August 2. Framework, the modular laptop manufacturer, declared theft of customer PII: names, IP addresses, mailing addresses, phone numbers, and emails.
"Because the queries used returned a variable, non-deterministic set of rows each time they are run, we cannot determine which specific records were accessed" — n8n
Cloud Exposure: Thousands of Self-Hosted Instances Still Vulnerable
While Metabase Cloud was patched automatically, the risk concentrates on self-hosted instances. According to Wiz research cited by The Hacker News, approximately 13% of cloud environments host self-hosted Metabase instances; of these, roughly 25% are fully exposed to the Internet. The calculation yields an estimate of approximately 2,500 publicly accessible Metabase instances, each a potential vector for unauthenticated compromise.
Patched versions, per SecurityWeek and the Metabase advisory, are: 63.5, 62.9, 61.11, 60.17, 59.21, and 58.24. The advisory indicates versions from 1.58 onward are affected; no confirmation emerges for earlier versions. For instances that cannot update immediately, Metabase suggests blocking the /api/session/reset_password endpoint at the firewall or reverse proxy level.
What to Do Now
- Check logs: search for the documented IoC sequence — POST
/api/session/reset_passwordwith HTTP 400 followed by GET/api/user/currentwith HTTP 200 — in application and server ingress logs - Apply indicated patches: update to 63.5, 62.9, 61.11, 60.17, 59.21, or 58.24 depending on the branch in use; for Metabase Cloud, the update is automatic
- Block the endpoint: if immediate update is not feasible, block access to
/api/session/reset_passwordat the network perimeter - Audit database connections: for compromised or suspected instances, verify integrity of stored credentials and access to connected systems, per Metabase advisory post-incident response guidance
Why CISA Accelerated the Federal Timeline
Inclusion in CISA's Known Exploited Vulnerabilities catalog with BOD 26-04 deadline set for August 14, 2026 reflects convergence of three factors: maximum severity, confirmed exploitation, and measured Internet exposure. The binding operational directive requires U.S. federal agencies to patch or mitigate by the deadline; the short interval — just eight days from disclosure — signals the authority's perception of immediate risk.
The dossier does not specify whether the attack directly involved self-hosted open-source instances beyond Metabase Cloud, nor attribution to a specific threat actor. No evidence emerges of exploitation of connected databases beyond the Metabase application database in public disclosures, though the platform's architecture makes such a scenario technically plausible.
The Lesson: Data Centralization Carries a Security Cost
This incident is not a run-of-the-mill SQL injection on a marginal application. Metabase is a data access infrastructure for organizations that delegate connection to heterogeneous systems to it. BI layer security thus becomes as critical as that of the databases themselves — perhaps more so, because a single point of compromise exposes multiple silos. Victims n8n, Kilo Code, and Framework were not negligent users: they were customers of a cloud service that failed to secure an unauthenticated endpoint. The distinction between vendor and user responsibility blurs when the platform is designed as a universal bridge.
For organizations with self-hosted instances, the countdown is measured in days. For those already compromised, the question is no longer whether Metabase is secure, but how many databases were connected and with what privileges.
Information verified against cited sources and current as of publication.
Sources
- https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
- https://www.darkreading.com/vulnerabilities-threats/metabase-sql-zero-day-attacks-wide-blast-radius
- https://thehackernews.com/2026/08/metabase-zero-day-exploited-in-wild.html
- https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
- https://socradar.io/blog/critical-metabase-zero-day/
- https://www.cve.org/CVERecord?id=CVE-2026-72898
- https://www.cisa.gov/news-events/alerts/2026/08/11/cisa-adds-three-known-exploited-vulnerabilities-catalog
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- https://github.com/n8n-io/n8n/pull/5842