Is Your Metabase Instance Exposed by the New Metabase Vulnerability Being Actively Exploited?

If you run Metabase, this one isn’t “keep an eye on it.” Metabase disclosed a critical, unauthenticated SQL injection zero-day affecting versions 1.58+ that’s already being used to get admin access, pull stored database credentials, and walk data right out the door . Real companies have already taken the hit—Framework confirmed customer data theft, and Tally disclosed exposure of user emails and password hashes . If your Metabase is internet-reachable (or your Metabase Cloud instance touches sensitive sources), you want to treat this like an active incident until you prove otherwise.

What’s happening (and why this one is so bad)

Metabase disclosed a critical unauthenticated SQL injection zero-day that affects Metabase versions 1.58 and above, and it’s already being actively exploited in the wild . The advisory rates it Critical (CVSS 10.0), which is basically Metabase saying: “assume real-world damage is on the table, fast.”

The ugly chain reaction (plain English)

This isn’t a “minor bug” that just crashes a dashboard. It’s a straight line to control:

1. Unauthenticated SQL injection lets an attacker inject arbitrary SQL into the Metabase application database
2. That can lead to administrator access inside your Metabase instance
3. With admin-level control, they can change configuration and steal stored credentials for connected databases
4. Now they can read and export any data Metabase can reach through those connections

That last point is why this is so dangerous: Metabase often sits in the middle of everything—production replicas, warehouses, even operational databases. If Metabase has a saved connection string, attackers don’t need to break into Snowflake/Postgres/BigQuery directly. They can take the “side door” and walk out with data.

Real companies already got hit

This isn’t theoretical.

• Framework confirmed attackers stole customer information after compromising its Metabase instance. Reported stolen data includes full names, email addresses, login IP addresses, billing and shipping address details, phone numbers, and company name . For business customers, it may also include VAT, EIN, and billing email .
• Tally disclosed its Metabase analytics environment was compromised, and attackers accessed user email addresses and passwords as cryptographic hashes. Tally also stated attackers didn’t reach forms or form responses, since those were stored separately .
• LexisNexis warned customers about a disruption tied to unusual activity on infrastructure hosted by a third-party vendor, explicitly mentioning impact to “Diligence, Metabase API and Newsdesk” .

Why defenders should treat this as “incident until proven otherwise”

Metabase is used both self-hosted and as Metabase Cloud, and Metabase said Cloud customers were already upgraded—self-hosted teams have to update manually . If your Metabase is internet-exposed, attackers don’t need credentials to start trying.

And because the path includes credential theft for connected databases, a Metabase compromise often isn’t the end. It’s the beginning.

Fast triage: are you exposed or already hit?

At this point, don’t guess. Run a quick triage in the same order an attacker would think about it: version → reachability → what Metabase can touch → evidence in logs.

1) Confirm your Metabase version (is it in the danger zone?)

Metabase said the zero-day affected versions 1.58 and above .

Do this now:

• Check the Metabase UI footer/about screen (common in admin areas).
• If you manage it via containers, check the image tag you deployed and when it was last pulled.
• If you run it behind a platform (Kubernetes, ECS, VM service), check the deployed artifact/version in your release history.

If you’re on 1.58+ and you haven’t explicitly patched since the disclosure window, assume you’re exposed until proven otherwise.

2) Confirm if it’s internet-reachable (directly or “accidentally”)

You’re not just looking for “public DNS.” You’re looking for anything that allows the login page to load from outside your trusted network.

Quick checks:

• Is the Metabase host accessible from a non-corporate network?
• Do you have a reverse proxy or load balancer that exposes it broadly?
• Any permissive firewall/security group rules (0.0.0.0/0) to the Metabase port?

If it’s reachable from the internet, treat triage as time-sensitive.

3) List what Metabase stores that would matter in a breach

Even if Metabase itself isn’t your data warehouse, it often holds the keys to it.

Make an inventory of:

• Connected data sources (production DBs, replicas, warehouses)
• Stored database credentials (users, tokens, connection strings)
• Any service accounts tied to Metabase connections

This tells you what an attacker could realistically read or export if they got in.

4) Hunt for the strongest indicator of compromise (IOC) in logs

Metabase called out a very specific pattern defenders can search for:

• A POST to /api/session/reset_password that returns HTTP 400
• Followed by a successful GET to /api/user/current

Metabase warns that system logs showing these entries have likely been compromised .

Where to look:

• Reverse proxy / WAF access logs (often the easiest place to spot the endpoint sequence)
• Metabase application logs (if request logging is enabled)
• Any centralized log pipeline (CloudWatch, ELK, Datadog)

5) Spot-check Metabase “behavior,” not just HTTP logs

Metabase also recommends inspecting logs and query history for signs of compromise .

Practical things to review:

• Unexpected spikes in query volume or long-running exports
• Queries run at odd hours for your org
• Access to tables that are rarely used for analytics (think auth tables, billing tables, admin tables)

If you find the IOC sequence or suspicious query history, stop thinking “patch.” Start thinking “containment.”

Action plan (patch + contain + clean up) — no fluff

If your triage turned up anything suspicious, operate like you’re in incident response mode. Even if you didn’t find a smoking gun, patching and basic containment is still the safest move while exploitation is active.

Patch (do this first if you can)

Metabase says the fix is available across affected branches (0.58 through 0.63). The minimum safe releases are: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5

Rules of thumb:

• Upgrade to the latest patch in your current branch if you can.
• Don’t “wait for a maintenance window.” This is the maintenance window.

If you can’t patch immediately (temporary mitigation)

Metabase’s stopgap is clear: temporarily block access to /api/session/reset_password until you can upgrade

That usually means one of these, depending on your setup:

• Reverse proxy rule (Nginx/Envoy/Apache)
• Load balancer/WAF rule
• Network policy (less ideal, but better than nothing)

Contain (assume credentials and sessions are dirty)

Metabase recommends these steps for self-hosted customers . Translate them into tickets your team can execute today:

• Revoke all active user sessions

Goal: kick out any attacker who’s already authenticated.

• Review administrator accounts and API keys for unauthorized changes

Look for:

• New admins you don’t recognize
• Permissions changes
• New/rotated API keys that weren’t part of planned work
• Rotate credentials for connected databases

Do the ones with the most access first:

1. Production databases / warehouses
2. Anything with customer PII
3. Any shared service accounts used outside Metabase

If your org uses the same DB credential in Metabase and other tools, assume that credential is now “shared risk” and rotate it everywhere.

Clean up and validate (prove you’re done)

Metabase’s guidance is to inspect logs and query history for signs of compromise . Make that concrete:

Log review

• Confirm you no longer see suspicious traffic hitting sensitive endpoints after mitigation/patching.
• Preserve logs before rotation/changes if you need forensics later.

Query/history review

• Search for unusual exports, large result sets, or access to tables that aren’t part of normal analytics.
• Look for sudden bursts of activity tied to one user, one IP, or odd hours.

If you found indicators earlier, treat this as more than a patch job: it’s a possible data access event. Document what was reachable through Metabase at the time, and plan your notifications based on what those connected sources contained.

‍