Metabase Zero-Day Vulnerability Actively Exploited in the Wild
On August 8, 2026, the open-source business intelligence platform Metabase published a security advisory for a maximum-severity vulnerability that had been used to break into production installations of its own cloud for at least a week before disclosure, and by extension the data of customers who trusted those instances with sensitive operational telemetry. The flaw, tracked as GHSA-vwf4-m7j8-wcjf and CVE-2026-72898, scored a CVSS v3.1 of 10.0 and lets an unauthenticated remote attacker inject arbitrary SQL into Metabase's application database and walk away with full administrator privileges on the affected instance. CVSS 10.0 is the ceiling of the scale; it is reserved for issues that require no authentication, no user interaction, and only low attack complexity, and this one meets all three criteria without qualification.
The vulnerability lives in the POST `/api/session/reset_password` endpoint, a public unauthenticated route that any internet-reachable Metabase instance will answer. According to Metabase's advisory, the root cause is a failure to restrict undeclared fields in the password-reset request body. The endpoint expects a `token` and a `password`; if the caller also sends an undocumented parameter named `user-id`, the application accepts it, threads it through a Clojure merge that does not strip unknown keys, and passes that value to the lookup that resolves the account being reset. Instead of being treated as an integer identifier, the user-supplied value is interpreted by Metabase's query-building layer — HoneySQL — as a structural input. When the attacker submits `{"user-id": {"raw": "SQL"}}`, the keyword `:raw` in HoneySQL compiles to verbatim SQL with no quoting and no bound parameter, and the request becomes a blind SQL injection into the application's own database.
Metabase CEO Sameer Al-Sakran confirmed the timeline in a public statement: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability." The first signs of compromise were detected on August 2, 2026, and the company moved to block the endpoints used by the attackers, then locate and patch the underlying bug. The advisory itself was not published until August 8, which gave defenders a six-day window in which the exploit was being used in the wild by at least one threat actor without any patch, official workaround, or published indicator of compromise to lean on. By noon UTC on August 10, public proof-of-concept exploit code was circulating openly, dramatically widening the pool of attackers who could now replay the same attack against any internet-exposed Metabase instance.
The Indicator of Compromise That Should Be in Every Detection Pipeline
The simplest detection rule Metabase published is also the one most defenders will end up using. An attacker who succeeds against an unpatched instance will leave a very specific pattern in the access logs: a `POST /api/session/reset_password` request that returns HTTP 400 — a malformed reset token is expected, the injection sits in an unexpected field — followed within seconds by a `GET /api/user/current` request that returns HTTP 200. The first request is the attempt; the second is the attacker verifying that they have just been promoted to a Metabase session. Al-Sakran was explicit: "If you find that pattern in your application logs or in your server ingress logs, it is likely that your instance has been compromised."
That two-request pattern is reliable enough that it should be promoted to a hard alert in any environment that runs Metabase and has not yet rotated the application database. The endpoint itself should also be blocked at the load balancer or web application firewall for any organization that cannot patch within the next 24 hours. Blocking `/api/session/reset_password` will break the password reset flow, but in a period of active zero-day exploitation that is a much smaller cost than letting the next request through.
The Path From a Single Endpoint to Full Administrative Control
The reason a SQL injection in a single endpoint is enough to take over a Metabase instance is that the application database stores a great deal more than user records. It holds the configuration of the Metabase instance itself, the API keys for outbound integrations, the administrator accounts, and — most damaging from a data-loss perspective — the credentials for the databases that Metabase has been configured to query. Once the attacker can read and write the application database, they can promote themselves to administrator, change the alarm configuration so that nobody else gets notified, and use Metabase's own connections to query the underlying data warehouse as Metabase sees it. They can also export data through Metabase's built-in export endpoints, which means everything the legitimate users of the instance can see, the attacker can download.
Security firm Wiz, which has tracked exposure to Metabase across its customer base, has put the attack surface into sobering context. Approximately 13 percent of cloud environments run a self-hosted Metabase instance, and of those, roughly 25 percent are fully reachable from the public internet. That is a non-trivial population of analytics deployments that were reachable and unpatched while the exploit was being used in the wild. The same research identified roughly 2,500 Metabase instances visible on Shodan in the days leading up to the disclosure, and the number of vulnerable instances was large enough that CISA added the flaw to its Known Exploited Vulnerabilities catalog with an August 14, 2026 remediation deadline for federal agencies.
The Victims Who Have Spoken Up
Three of the most prominent companies to disclose breaches tied to this vulnerability did so within 48 hours of Metabase's advisory, and the picture they paint is consistent with the worst-case scenario for a SQL injection against a BI tool.
**Framework**, the modular laptop manufacturer, disclosed that an attacker accessed its customer Metabase instance on August 3, 2026, the day after Metabase itself first noticed the exploitation. The data set exposed for affected customers included full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. Framework Business customers had additional fields exposed, including VAT and EIN numbers. Notably, order and payment information was not accessed — Framework's payment processing lives outside the Metabase instance — but the data set is more than enough to enable targeted phishing and account-takeover attempts that rely on name, address, and email as the "knowledge-based authentication" answers that many consumer services still accept.
**Tally**, the form-builder platform, reported that its analytics environment was breached on the same day, August 3, and that attackers obtained email addresses and password hashes for affected users. The form responses and submissions themselves were not in scope of the Metabase instance, which limited the worst-case impact, but the email-plus-hash combination will still require a forced password reset for the affected users and a round of credential-stuffing detection against the rest of the user base.
**Kilo Code**, the AI coding platform, disclosed that the breach of its Metabase instance exposed Slack-bot authentication tokens for affected users. The incident window in their case was approximately four hours on August 2, and the company notified users four days after the breach. Stolen Slack tokens are a particularly nasty category of secret because they grant the same scope of access as the legitimate user, and they will keep working until explicitly revoked; rotating them is the only correct response.
**n8n**, the workflow automation platform, was also confirmed affected in the same wave. The disclosure listed 136 customer records containing names and emails, with five records additionally exposing bcrypt-hashed passwords for n8n Cloud accounts. n8n's investigation also surfaced a historical bug from April 2023 that had left 25 accounts with plain-text storage of their original signup passwords, which the company also disclosed in the same advisory.
The Patch Matrix and Why It Matters
Metabase ships in six actively supported release lines, and the patch is being delivered as a coordinated release across all of them at once. The fixed versions are 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, and 1.63.5. The lowest affected version is 1.58.0, and every installation on 1.58 or above is vulnerable until it has been upgraded to one of the fixed releases on its branch. Cloud customers were patched automatically; self-hosters — the population that Wiz has been tracking at 13 percent of cloud environments — have to upgrade themselves.
The fix is described in the advisory as an explicit restriction of the password reset flow to the expected inputs. The endpoint now stops accepting undeclared fields rather than merging them through into the database lookup, which addresses the root cause rather than papering over it. For organizations that have already been compromised, the patch alone is not enough. Metabase's own remediation list runs longer than the upgrade step: revoke active sessions by deleting rows from the `core_session` table, review and remove any unrecognized API keys, audit the administrator accounts for unexpected additions, rotate the credentials for every connected database, and review both the data warehouse access logs and the Metabase activity and query history for unauthorized access. None of those steps are optional in a "was it us?" situation, because the application database is the source of truth for who has administrator access to the instance, and any compromised row left in place is a foothold the attacker can re-establish.
The Broader Pattern: Why BI Tools Are a Soft Target
The Metabase incident is not the first time a business intelligence platform has been the pivot point for a wide-reaching breach, and it will not be the last. The structural problem is that BI tools sit at the seam between operational data and the people who want to see it, and they tend to be run by teams whose primary expertise is data, not the security of the application that surfaces the data. The application database of a BI tool holds the keys to the data warehouse and the read-only credentials that the rest of the company uses to query the data, which means a SQL injection against the BI tool is functionally equivalent to a SQL injection against the data warehouse itself.
The specific failure in Metabase's case — a public, unauthenticated endpoint that tolerates undeclared fields and forwards them to a query builder that interprets them as SQL — is a class of bug that keeps recurring because the frameworks that host the bug often predate the threat models that would have caught it. Clojure's merge is doing what merge has always done. HoneySQL's `:raw` is doing what `:raw` was designed to do. The application of those primitives to a publicly reachable authentication endpoint is the actual mistake, and the only durable fix is in the endpoint, not in the building blocks.
For defenders, the operational lesson is the same one the industry has been relearning for a decade: the most dangerous SQL injection is the one that an unauthenticated attacker can reach over the public internet, the one that gives them administrative access to the application that fronts the data they care about, and the one that they have not yet patched. The Metabase zero-day met all three criteria at once, and the affected organizations are now paying the cost of a six-day pre-disclosure exploitation window in user trust, incident response effort, and credential rotations.
Patching is the first step. The remaining steps — session revocation, key rotation, database credential rotation, log review — are the ones that close the loop. The patch prevents the next attacker from getting in; the cleanup makes sure the first attacker is no longer welcome.
What Defenders Should Do in the First 24 Hours
The shape of the response for any organization that runs a self-hosted Metabase instance on a version between 1.58.0 and 1.63.4 depends on whether the answer to "do we see the IoC pattern in the logs?" is yes, no, or unknown. The no branch is the simple one: apply the patch on the next maintenance window, review the change log for the upgrade, and write a short runbook note that records the IoC pattern so that the next operator knows where to look. The unknown branch is the right place to start for most organizations, because the default state of any analytics deployment is "we have logs, but we have not specifically looked for this pattern in the last ten days."
For the unknown case, the first concrete action is to query the application and ingress logs for the two-request pattern Metabase published. A check for `POST /api/session/reset_password` returning 400 followed by `GET /api/user/current` returning 200 is a good starting shape. If the result is any hits at all, the organization is in the yes branch, and the remediation step list from the previous section applies in full. If the result is clean, the organization is in the no branch and the priority shifts to upgrade hygiene.
The yes branch is more involved. The first action is to take the affected instance off the public internet while the cleanup is in progress, because as long as it is reachable, the same attacker can come back through the same path. The second action is to upgrade to the patched version, because the patch is what closes the door that was used in the first place. The third action is the incident response work: revoke sessions, audit admin accounts, rotate database credentials, look at the question history for exports that nobody on the team made, and notify the legal and compliance stakeholders who will need to weigh in on customer notification.
The fourth action, often forgotten in the urgency of a zero-day response, is to take a forensic image of the application database before the cleanup starts. The cleanup will overwrite the rows that tell the response story, and the post-incident writeup will need to know exactly which admin accounts were added, which sessions were minted, and which queries were run between the first POST and the discovery. The cheapest way to preserve that evidence is a `pg_dump` of the application database the moment the incident is confirmed.
The Lesson For Vendors of Adjacent Products
The Metabase disclosure is also a useful mirror for the engineering teams that run other BI tools, observability platforms, and internal dashboards. The class of vulnerability — a public, unauthenticated endpoint whose input is interpreted as SQL by a query builder that no longer enforces the identifier boundary — is not unique to Metabase. The same pattern can be found in any product that grew up around an expressive query builder and exposed its administrative endpoints to the internet because the default deployment pattern was "self-hosted on a VM with a public IP."
The defensive engineering response is the same in every case: the endpoint contract should be the smallest possible set of named fields, and any field that is not in that contract should be rejected at the boundary before it can be merged into the data structures that drive the query. The fix is local, the pattern is universal, and the disclosure of CVE-2026-72898 is a good moment to audit every adjacent tool the engineering team operates to confirm the same input validation is in place there too.