Metabase CVE-2026-72898 SQL Injection: Recap and next steps

Key Takeaways

• Metabase disclosed CVE-2026-72898, an unauthenticated SQL injection vulnerability (CVSS 10.0) that attackers were already exploiting in the wild before a patch existed.
• A successful attack grants full admin access, exposing connected database credentials, query access, and configuration control - no login required.
• Framework and Tally have both disclosed data theft tied to this exact flaw, so the risk is confirmed, not theoretical.
• A patch closes the vulnerability going forward, but it doesn't tell you whether an attacker already got in before you patched - check logs, not just version numbers.
• Metabase is an application, not a hardened base image - but running it on a hardened container image shrinks what an attacker can do once inside, which is a different layer of defense than patching the app itself.

What happened

Metabase disclosed a previously unknown SQL injection vulnerability, tracked as CVE-2026-72898 (also referenced as GHSA-vwf4-m7j8-wcjf), that attackers had already been exploiting in the wild. The flaw is unauthenticated, rated CVSS 10.0, and can let a remote attacker gain full admin access to a Metabase instance - no credentials, no user interaction, just a crafted request to the public password-reset endpoint.

It affects Metabase versions x.58.0 through x.63.4. Fixed versions are:

• x.58.x → upgrade to x.58.23 or later
• x.59.x → upgrade to x.59.21 or later
• x.60.x → upgrade to x.60.17 or later
• x.61.x → upgrade to x.61.11 or later
• x.62.x → upgrade to x.62.9 or later
• x.63.x → upgrade to x.63.5 or later

From there, an attacker could:

• Access connected database credentials
• Query accessible data
• Change configurations
• Export data

This isn't theoretical. Both Framework and Tally have disclosed data theft following compromises of their Metabase environments, and n8n disclosed a related breach tied to its own Metabase instance.

If you're self-hosting Metabase, act now

Metabase's own recommendations are direct:

1. Upgrade immediately to the latest patched release for your version.
2. Revoke all active user sessions.
3. Review API keys and admin accounts for unexpected changes.
4. Rotate credentials for every connected database.
5. Review warehouse logs, Metabase activity, and query history for suspicious access.

If you're on Metabase Cloud, Metabase says you're already patched - but that doesn't mean you weren't affected before the patch shipped.

The indicator worth checking right now

One sequence in your logs is a strong signal of exploitation:

POST /api/session/reset_password → 400

followed by

GET /api/user/current → 200

A failed password-reset request immediately followed by a successful "current user" check is consistent with an attacker using the injection to mint themselves a valid session. If you see this pattern, treat the instance as compromised and start incident response - don't wait for further confirmation.

The important part: a patch closes the vulnerability, but it doesn't tell you whether someone got there before you patched. Patching and forensic review are two separate steps, and skipping the second one leaves you blind to whether you're cleaning up after an intrusion that already happened.

Is Metabase a base image? No - and that distinction matters

It's worth being precise here, because the terminology gets confused: Metabase is an application - an open-source business intelligence and analytics tool. It is not a base image.

A base image is the underlying operating system layer a container is built from - things like Debian, Alpine, or a distroless image. When you run Metabase in a container, that container has two layers: the Metabase application code (where this SQL injection lives) and the base image underneath it (the OS, libraries, and runtime Metabase sits on top of).

This vulnerability is entirely in the application layer. No base image, hardened or not, would have patched Metabase's password-reset endpoint - that fix has to come from Metabase itself. But the base image layer still matters here, for a specific reason: it determines what an attacker can do once they're in.

An attacker who gains admin access to Metabase through this flaw is now operating inside a running container. Whether that container gives them a shell, a package manager, and a path to pivot further, or whether it's stripped down to exactly what Metabase needs to run, depends entirely on the base image underneath it.

Why a hardened base image still reduces your exposure

A hardened container image - one stripped of unnecessary components, built with tight default configurations, and continuously scanned and patched - doesn't stop an application-layer SQL injection. What it does is limit the blast radius if an attacker gets in through one:

• No shell or package manager in production images means an attacker with admin access to Metabase has a much harder time pivoting into the underlying host or pulling in additional tooling.
• A minimal attack surface means fewer binaries and libraries are present to exploit for privilege escalation or persistence, even after initial compromise.
• Continuous rebuilds and fast CVE remediation at the OS layer mean the environment Metabase runs in isn't independently exposing you to a second, unrelated vulnerability while you're already dealing with this one.

This is the same logic behind why teams increasingly run applications - Metabase included - on CVE-free base images rather than default upstream images that ship with thousands of known vulnerabilities baked in before a single line of application code runs. The application still needs patching on its own schedule. The base image is what determines how contained an incident stays if that patching happens a day too late.

If you're evaluating how your container foundation holds up independent of application-layer bugs like this one, Echo's guides on container image vulnerability best practices and AI-ready hardened container images cover what a genuinely hardened base layer looks like in practice.

FAQ

Is Metabase itself a hardened base image?

No. Metabase is an application that runs inside a container, typically on top of a base image like Debian or Alpine. A hardened base image refers to that underlying OS layer, not to Metabase's own code. The two are separate layers of the same deployment, and this vulnerability lives entirely in Metabase's application code.

Does a hardened base image protect against this SQL injection?

Not directly - the flaw is in Metabase's password-reset endpoint, so only a Metabase patch fixes it. A hardened base image reduces what an attacker can do after gaining access, by removing shells, package managers, and unnecessary components that would otherwise help them pivot further inside the container or host.

How do I know if I was compromised before I patched?

Check your logs for a failed POST /api/session/reset_password request immediately followed by a successful GET /api/user/current request - this is the signature of CVE-2026-72898 being exploited. Also review admin accounts, API keys, and warehouse query logs for unexplained changes or access around the time the vulnerability was disclosed.

What's the difference between patching Metabase and hardening the container it runs in?

Patching Metabase fixes the specific application vulnerability - in this case, the SQL injection in the password-reset flow. Hardening the container's base image is a separate, ongoing practice that reduces the overall attack surface, so that whatever the next application-layer bug turns out to be, the surrounding environment limits how far an attacker can go.

Should self-hosted Metabase users do anything beyond upgrading?

Yes. Upgrading closes the vulnerability going forward, but it doesn't undo any access an attacker gained beforehand. Revoke active sessions, rotate all connected database credentials, and audit admin accounts and query logs, since the CVSS 10.0 rating and confirmed in-the-wild exploitation mean this wasn't a low-probability risk.