A password reset endpoint that resets the wrong thing
Metabase, the open-source business intelligence tool embedded in thousands of companies' analytics stacks, disclosed CVE-2026-72898 on August 8: a SQL injection vulnerability in versions 1.58 and above reachable through the unauthenticated /api/session/reset_password endpoint. The flaw carries the maximum possible CVSS score of 10.0, and successful exploitation does not just leak data sitting in a single table, it grants the attacker full administrator access to the Metabase instance itself, with every permission that any legitimate administrator account would normally hold.
From there, an attacker can modify application configuration, steal the credentials Metabase uses to connect to underlying databases, and pull data directly out of every connected data source the instance was ever configured to reach. Because Metabase instances are typically wired into production analytics, warehouse, or reporting databases specifically to surface business-critical dashboards for executives and product teams, an admin-level compromise of the BI layer is functionally equivalent to a compromise of whatever data that BI layer was originally built to visualize and report on.
The company found it by getting breached first
The origin story here is unusual and worth sitting with. Metabase identified this flaw during an active attack against its own cloud infrastructure, meaning the vendor's security team discovered a maximum-severity, unauthenticated admin-takeover bug in their own product because someone was actively using it against them in real time, rather than through internal code review or a bug bounty submission arriving through normal channels. CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 11, three days after public disclosure, confirming this was already being actively exploited in the wild well before the fix ever shipped to customers.
That sequencing matters enormously for prioritization decisions inside your own security team. A vendor discovering a critical bug via its own breach, then racing to patch and disclose within days, is a strong signal that working exploit code was already circulating among attackers, likely well before the CVE itself was even assigned a number. Any organization treating this as a routine item sitting in a patch backlog, rather than as an active-incident triage matter demanding immediate log review, is working from a dangerously false sense of the actual timeline involved.
Detection is unusually concrete for a SQL injection bug
Metabase's own disclosure included a specific, actionable exploitation signature: a POST request to /api/session/reset_password that returns an HTTP 400 status code, followed immediately by a GET request to /api/user/current that returns a 200. CEO Sameer Al-Sakran was direct about what that pattern means for customers checking their own logs: "If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised."
This is an unusual gift to defenders relative to most SQL injection disclosures, which often require deep forensic log analysis over many hours to distinguish real exploitation attempts from ordinary application traffic and background noise. Every SOC or IT team running self-hosted Metabase should be running this exact log query today, immediately, rather than waiting for a scheduled vulnerability scan cycle to eventually surface it weeks from now. The specificity of the pattern also strongly suggests Metabase's own incident response team reverse-engineered the exploit directly from real attack traffic captured during their breach, not from a theoretical proof of concept written after the fact.
Confirmed victims show the blast radius runs through the software supply chain
Three organizations have confirmed data exposure tied to this vulnerability so far: Framework, the modular PC and laptop maker; N8n, a widely used workflow automation platform; and Kilo Code. The presence of N8n on that list is particularly notable for CTOs, since automation platforms like N8n routinely hold credentials and API keys for dozens of downstream integrations spanning CRM, payments, and internal tooling. A Metabase compromise at a company running that kind of stack is never contained neatly to analytics data alone, it potentially cascades outward into every connected system that platform's automated workflows were ever granted access to touch.
This pattern, a BI or analytics tool compromise becoming a pivot point into a much wider set of connected systems, echoes what security teams have already seen play out with other embedded SaaS tooling earlier this year. It is a useful reminder that vulnerability severity scoring based purely on a tool's own stated function routinely understates the real blast radius once you account for everything that tool is actually integrated with inside a live production environment, credentials and all.
What to do if you run Metabase in production
Patch to the fixed release immediately if you have not already done so; this is a CISA KEV catalog entry carrying a federal remediation deadline, and private-sector organizations should treat that deadline as the outer bound rather than the actual target for their own response. Search application and ingress logs for the specific reset_password and user-current request pattern Metabase published, and if you find it anywhere in that history, assume admin-level compromise occurred and rotate every credential Metabase ever had access to, well beyond just the Metabase admin password itself.
Longer term, revisit why your BI tooling holds standing credentials to production databases at all, instead of scoped, read-only, least-privilege service accounts issued with short-lived tokens that expire automatically. This incident is a clean, concrete illustration of why analytics infrastructure deserves the same access-control rigor applied to your core application stack, and should no longer receive the looser governance it often gets simply because teams perceive it as internal-facing rather than customer-facing.
