CVE-2026-72898: admin takeover via Metabase

The short answer

CVE-2026-72898 is a critical (CVSS 10.0) unauthenticated SQL injection in Metabase, the business-intelligence and dashboard tool a lot of casino, sportsbook, and crypto-exchange teams run internally for player, transaction, and KYC reporting. An attacker with no credentials can inject SQL through the password-reset endpoint and walk away with full administrator access to your Metabase instance — including the database credentials it has stored for every connected source. It's on CISA's Known Exploited Vulnerabilities list, it's already tied to a real breach, and if you run a self-hosted Metabase instance, patching it is not this week's task — it's today's.

Who this is for

This is written for whoever owns security decisions at an online casino, sportsbook, or crypto exchange — CISO, Head of Infrastructure, or the security-adjacent engineer who gets asked "are we affected by this" every time a CVE makes the news. It matters even if security doesn't own Metabase directly, which is the point: at most operators, Metabase is stood up by a data or BI team to build player-activity dashboards, cashier reporting, or KYC review queues, and it rarely appears on a security asset inventory or in a penetration test scope, despite sitting on live production-database credentials. If you don't run Metabase at all, the fifteen minutes it takes to confirm that — checking your internal tooling list, asking the data team directly — is still worth it before you skip the rest of this post.

What we know about CVE-2026-72898

• Vulnerability class: unauthenticated SQL injection (CWE-89) in the POST /api/session/reset_password endpoint. The endpoint fails to restrict unexpected fields in the request body, so a value that should be treated as a plain user identifier can instead be interpreted as part of a SQL expression against the application database.
• CVSS: 10.0 — the maximum possible score, reflecting network-reachable, no-authentication, no-user-interaction, low-complexity exploitation.
• Impact: an attacker can inject arbitrary SQL into Metabase's own application database and obtain full administrator access to the instance — enough to change configuration, read or export any data reachable through Metabase's configured database connections, and steal the stored credentials for those connections.
• Affected versions: x.58.0–x.58.23, x.59.0–x.59.20, x.60.0–x.60.16, x.61.0–x.61.10, x.62.0–x.62.8, and x.63.0–x.63.4, spanning both the open-source (0.x) and Enterprise/Pro (1.x) release lines.
• Patched versions: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5, or the matching 1.x Enterprise/Pro build.
• Timeline: Metabase published its security advisory (GHSA-vwf4-m7j8-wcjf) on 2026-08-06. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-08-11, which for US federal agencies carries a remediation deadline of today, 2026-08-14 — a useful marker of urgency even if you're not a federal agency.
• Confirmed exploited: Metabase has stated the flaw was exploited against its own Metabase Cloud service before the advisory was public, and multiple self-hosted customers have separately reported compromise. Metabase Cloud is now patched on the vendor's side; self-hosted deployments are not automatically protected.

We're deliberately not describing the injection payload or the exact request that triggers it. The version check and the detection indicators below are what matter for defense, and neither requires the exploit mechanics.

A breach already happened because of this

On 2026-08-13, hardware-wallet maker Trezor disclosed that its fulfillment partner, ShipMonk, had been breached, exposing shipping and contact details — full names, emails, phone numbers, and delivery addresses — for roughly 13,700 customers. ShipMonk told Trezor the attackers got in by exploiting a vulnerability in Metabase, the third-party analytics platform it uses internally. Public reporting describes this as the same Metabase SQL-injection zero-day covered here, part of a wider campaign that also reportedly hit laptop maker Framework and form-builder Tally — though ShipMonk's own statement didn't cite CVE-2026-72898 by number, so treat the identity as "widely reported," not vendor-confirmed.

The mechanism matters more than the specific company: ShipMonk isn't a security vendor and Metabase wasn't its production system — it was an internal analytics tool, exactly the kind of "not actually a security tool" asset described above. That's precisely the profile of the risk for a casino or exchange running Metabase against a player or transaction database.

What to check in the next 24 hours

Step	Action	Why it matters
1. Inventory	Find every Metabase instance you run — self-hosted OSS or Enterprise/Pro, including anything a data or BI team stood up without security's sign-off	This tool is routinely missing from security asset inventories precisely because it isn't labeled a security tool
2. Version check	Confirm the exact build against the affected-version list above; upgrade to 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5 (or the matching 1.x build) regardless of exposure	Version alone determines vulnerability — there's no configuration workaround that fully closes this
3. Cloud status	If you use Metabase Cloud, confirm patched status directly in your account admin panel or via vendor communication rather than assuming	Cloud was where pre-disclosure exploitation actually happened; verify, don't assume
4. Exposure check	Determine whether the instance is reachable from the internet, or only from an internal network or VPN	Internet-facing is the most urgent case, but unauthenticated means any network path is sufficient — internal-only reduces risk, it doesn't remove it
5. Admin audit	Review the Metabase admin user list for accounts you don't recognize, and review recently modified database-connection settings	Successful exploitation grants admin access, which an attacker can use to create a persistent account or exfiltrate connection credentials
6. Credential rotation	Rotate credentials for every database connection configured in Metabase, on the assumption they were exposed if the instance was unpatched and reachable	Metabase stores these credentials to run its own queries; admin access exposes them directly
7. Log review	Search access and application logs for requests to /api/session/, /api/util/, or /api/user/ containing SQL-injection patterns (stray quotes, UNION SELECT, OR 1=1, SLEEP(), pg_sleep), and for the Metabase process spawning shells or command interpreters	These are the published detection indicators for this specific CVE; a hit on either is a strong signal of an exploitation attempt or success

If step 5, 6, or 7 turns up anything you can't explain, stop treating this as a patching task and escalate to an incident response engagement — a stored-credential-exposure event on a system connected to player or transaction data isn't something to sit on until the next change window.

Why this is a casino, exchange, or fintech problem specifically

Metabase's own published case studies name an online-casino platform integration and a 200-plus-person fintech analytics team among its users — this isn't a niche developer tool, it's a mainstream way operators build the KPI dashboards, cashier reporting, and KYC review queues that a data or compliance team relies on daily. That's also exactly why it tends to sit outside security's field of view. We've written before about CVEs landing in tools that are nominally security infrastructure — an unauthenticated RCE in Splunk, where the argument was that even security tooling is under-tested attack surface. Metabase pushes that same lesson one step further: it isn't even nominally a security tool, so it's even less likely to be in a vulnerability assessment's scope or a security team's asset inventory by default — while routinely holding direct database credentials to the same player, transaction, and KYC data that a casino or exchange spends the rest of its security budget protecting.

Two things close that gap:

• Put internal BI and analytics tooling in vulnerability-assessment scope, explicitly. A recurring vulnerability assessment that enumerates internal-facing assets — not just the customer-facing platform — is what catches a Metabase instance before a KEV listing forces a same-day fire drill. Our own VA engagements run 3–5 business days per cycle and are built around manual verification specifically so an internal dashboard doesn't get waved through as "not customer-facing, not in scope."
• Ask who owns every tool with a live database connection, not just who owns the database. Metabase, and tools like it, exist because a data or BI team needs read access to production data — which means the tool itself becomes an extension of that data's blast radius. If your asset inventory is organized around "who's in security" rather than "what has a database credential," this is the kind of exposure that inventory misses by design.

Limitations

This checklist gets you to "patched, verified, and audited for prior compromise" — it does not replace ongoing monitoring or prove your broader environment is clean. A vulnerability assessment finds exposure like this proactively across your estate; it does not watch continuously for the next one, which is what a Managed SOC is for. And if the admin audit or log review above turns up a confirmed indicator, patching the CVE doesn't undo whatever an attacker already did with admin access in the meantime — that's an incident-response question, not a patching one.

What to do next

Patch first, ask questions during the audit — don't wait for a confirmed compromise indicator to start the version upgrade. Once the immediate checklist is done, the durable fix is making sure internal BI and analytics tooling is part of your regular exposure-management cadence, not an exception to it. Tell us what you run internally and we'll scope a vulnerability assessment that treats your data-team tooling as attack surface, not background.

Sources and review

CVE-2026-72898 / GHSA-vwf4-m7j8-wcjf: Metabase's own security advisory (published 2026-08-06) and the CISA Known Exploited Vulnerabilities catalog (added 2026-08-11) are the primary sources for the vulnerability class, affected/patched version ranges, and exploitation status. Detection indicators are drawn from published third-party researcher advisories (Bishop Fox, Horizon3, runZero). The Trezor/ShipMonk breach details are drawn from Trezor's own 2026-08-13 disclosure and subsequent public reporting; the link to this specific CVE is described in that reporting as probable, not vendor-confirmed by CVE number, and is presented here with that caveat. Author: AnySec Engineering. Published 2026-08-14; last reviewed 2026-08-14.

---

Related reading

• When your SOC tool is the target: CVE-2026-20253 — the same "your internal tooling is attack surface" lesson, one layer up the stack in a tool that is nominally security infrastructure.
• Vulnerability assessment vs penetration testing for iGaming — what a recurring vulnerability assessment actually covers, and why internal-facing assets like this belong in scope.
• CVE-2026-16232: auth bypass in Check Point console — the admin-plane pattern from a firewall management console instead of a BI tool.