Metabase CVSS 10 Zero-Day Exploited: Patch Now

A maximum-severity SQL injection flaw in Metabase has been exploited in the wild since August 3, and your vulnerability scanner almost certainly has no idea. The flaw — tracked as GHSA-vwf4-m7j8-wcjf, CVSS 10.0 — lives in an unauthenticated public endpoint. No credentials required. Attackers sent a crafted POST to Metabase’s password-reset route, injected arbitrary SQL against the application database, and walked out with admin access plus every database credential the instance had stored. Framework laptop customers and Tally users already have breach notices. If you self-host Metabase and haven’t patched, you’re exposed right now.

What the Vulnerability Actually Does

The vulnerable endpoint is POST /api/session/reset_password. It’s public — no session token, no API key, nothing. An attacker who can reach your Metabase URL can hit that endpoint and inject SQL directly into the application database. From there the blast radius is severe: full admin takeover of the Metabase instance, harvest of every stored database credential (Postgres, MySQL, Snowflake, Redshift, BigQuery — whatever you’ve connected), and bulk export of any data those databases hold.

This is why the CVSS score is 10.0. There’s no authentication to bypass, no privilege escalation required, and no network-level restriction on the endpoint by default. The GitHub Security Advisory was published without a matching CVE, which means NVD-based scanners, Dependabot, Renovate, and Snyk are all blind to it. The only way to know if you’re safe is to check your version manually.

Are You Affected?

Metabase Cloud was patched by August 4 — Metabase blocked the endpoint and pushed fixes to Cloud before going public. If you’re self-hosted and running any version in the 0.58 through 0.63 branches, check against this table:

Branch	Vulnerable Below	Minimum Safe Version
0.58	0.58.24	0.58.24
0.59	0.59.21	0.59.21
0.60	0.60.17	0.60.17
0.61	0.61.11	0.61.11
0.62	0.62.9	0.62.9
0.63	0.63.5	0.63.5

Metabase recommends upgrading to the latest patch for your current branch rather than jumping major versions, to avoid migration headaches.

Real Victims: Framework and Tally

Two companies have already disclosed breaches tied to this vulnerability. Framework — maker of the repairable laptops popular with the developer community — notified every customer in its database that names, login IPs, physical addresses, phone numbers, and email addresses were accessed. Payment information wasn’t in scope, but the breadth is notable: the company said it alerted “all customers,” not a subset. Online form builder Tally confirmed its Metabase environment was compromised on the same date.

The timeline moves fast: Metabase detected the attack on August 3, patched Cloud the same day, and notified Framework on August 6. Framework went public August 7. That’s a four-day window between first exploitation and customer notification — which means any self-hosted instance exposed during that window is fair game.

Fix It Now

If you can patch: Upgrade to the minimum safe version for your branch (see table above). Metabase’s official security update post has the direct download links.

If you can’t patch immediately: Block the endpoint at your reverse proxy or WAF. For nginx:

location = /api/session/reset_password {
    deny all;
    return 403;
}

This kills the password-reset feature but eliminates the attack surface until you can upgrade. Don’t leave it blocked permanently — patch as soon as possible.

If you think you were already hit: Check your ingress or application logs for this pattern: a POST /api/session/reset_password returning HTTP 400, immediately followed by a GET /api/user/current returning HTTP 200. That sequence is the exploitation fingerprint. If you find it, run TRUNCATE TABLE core_session; after patching, then rotate every database credential stored in Metabase — every single one.

BI Tools Are Not Low-Risk Infrastructure

Here’s the uncomfortable truth this breach surfaces: most engineering teams treat their BI tool like a read-only dashboard — something the data team manages, something that gets upgraded when there’s time. That assumption is wrong and this vulnerability proves it.

Metabase stores read/write credentials for every database you connect to it. One compromised instance is a skeleton key to your entire data layer. This isn’t a hypothetical risk — it’s exactly what happened to Framework. And this is the second time Metabase’s auth/session infrastructure has been the attack vector: the 2023 pre-auth RCE (CVSS 9.8) hit the same general area. Two critical vulnerabilities in the same subsystem in three years is a pattern, not a coincidence.

Self-hosted BI tools need to be in your regular patch rotation. They connect to production. They hold credentials. They deserve the same urgency as your application servers.

What to Do Right Now

• Check your Metabase version — Admin > Settings > About, or check your Docker image tag
• Patch to the safe version for your branch, or block /api/session/reset_password at the proxy immediately
• Rotate all database credentials connected to Metabase if you had any exposure window — assume they’re compromised

No CVE has been assigned yet. Don’t wait for your scanner to catch up.