Metabase is the kind of tool that ends up connected to everything: the production database, the warehouse, sometimes a read replica of the customer records system, all wired in so analysts and product teams can build dashboards without waiting on engineering. That's exactly what made CVE-2026-72898 as damaging as it was. The flaw lived in POST /api/session/reset_password - an endpoint that, by design, has to be reachable by anyone who's forgotten their password, which means anyone at all. Bishop Fox's technical writeup and The Hacker News' coverage both confirm the same outcome: an attacker who never logs in can still walk out as an admin.
An unvalidated field is all it took
The root cause is unglamorous in the way the worst vulnerabilities usually are. The reset-password endpoint failed to restrict which fields it would accept in the request body, and an unexpected value in that body reached Metabase's application-database user lookup as raw structured input rather than a properly validated identifier. Metabase's own query-building layer then read that input as a SQL expression instead of data, giving an attacker the ability to inject arbitrary SQL into the query the reset flow runs. From there, the path to full administrative access - altering application-database records outright - was direct rather than requiring any further chaining.
Zero-day in the wild, disclosure five companies too late
Metabase published its advisory on 6 August confirming both the flaw and that it was already being actively exploited. That ordering matters: this wasn't a responsibly disclosed bug that attackers raced to weaponise afterward, it was already live when the advisory went out, and reporting on the incident puts the number of companies that had already lost customer data at five by that point. CISA added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog on 11 August, the same batch that included Cisco's actively exploited firewall flaw and Microsoft's Lazarus-linked kernel zero-day. Patched releases are available for every supported branch - 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5, or the matching 1.x Enterprise builds - which means the fix, once you know to apply it, is a straightforward upgrade rather than a redesign.
The dashboard tool was never the sensitive system - until it was
Nobody classifies their BI tool alongside their identity provider or their payment gateway when they're deciding what needs the tightest controls, and on paper that's a reasonable call: Metabase doesn't store payment details or issue tokens. What it does do is hold live credentials to every database an organisation has ever pointed it at, which this flaw turned into the actual prize. It's the same lesson as Check Point's management console auth bypass earlier this month and the Langflow chained RCE before it: the system that manages or connects to your real infrastructure needs the security posture of that infrastructure, not the security posture its own feature set suggests.
- Upgrade to a patched Metabase release immediately - 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5, or the equivalent 1.x Enterprise build.
- If an immediate upgrade isn't possible, block the
/api/session/reset_passwordendpoint at the network or reverse-proxy layer as an interim measure. - Audit Metabase admin accounts and activity logs now for any account or session you don't recognise, particularly if your instance has ever been reachable from the internet.
- Rotate credentials for every database connection configured inside Metabase if there's any chance the instance was exposed before you patched - admin access to Metabase means access to what Metabase connects to.
An analytics tool is rarely first on the list when teams model their attack surface, and that's precisely the gap this flaw exploited. If you'd like help auditing which of your internal tools hold more access than their threat model assumes, email sales@halfteck.com.