Metabase Zero-Day Hits CVSS 10, Framework Among the Casualties

Picture a bank where the front door is a slab of reinforced steel, the vault has biometric locks, and the guards rotate every four hours. Now picture the side door marked "password reset" propped open with a brick. That's the shape of the Metabase zero-day disclosed this week, and the brick has been sitting there long enough that someone already walked through it.

Metabase, the open-source BI tool that a lot of engineering teams quietly wire straight into their production replicas, is warning of a pre-auth flaw with a CVSS of 10.0 and no CVE assigned. The company confirms Metabase Cloud itself was hit. Framework, the modular-laptop maker, is one of the confirmed casualties on the customer side.

What Happened

As The Hacker News reported, Metabase disclosed that its cloud offering was attacked by someone exploiting an unknown zero-day in versions 1.58 and above. The bug lets an unauthenticated remote attacker inject arbitrary SQL directly into the Metabase application database, which is the boring bit that stores users, sessions, permissions, and connection strings for every warehouse Metabase talks to.

From there, the attacker gets administrator access to the instance. That means changing app config, stealing stored credentials for connected databases, reading anything those connections can see, and exporting it. It's the full loot table.

Metabase Cloud has already been updated. Self-hosted users need to move now. The fixed versions are x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, and x.63.5. Anything older in those branches is exposed. The temporary workaround, if you can't patch tonight, is to block the /api/session/reset_password endpoint at your ingress. That single line tells you more about the bug's origin than the advisory does.

On the customer-fallout side, Framework alerted its buyers that names, login IPs, addresses, phone numbers, and emails were pulled during the hack, according to reporting picked up from Engadget. No order or payment info was accessed, which is the one small mercy in an otherwise rough weekend for their trust and safety folks.

The uncomfortable historical footnote: exactly three years ago, Metabase patched CVE-2023-38646, a 9.8-scored pre-auth RCE. Same class of failure, same "before you log in" attack surface. Different door, same brick.

Technical Anatomy

The indicators of compromise Metabase published tell the whole story to anyone who has stared at web app logs at 2am. The pattern is a POST /api/session/reset_password returning 400, followed by a GET /api/user/current returning 200. In English: send a malformed reset-password request, then check that you are now logged in as somebody. If the second call returns 200 without an intervening login, the reset endpoint isn't just resetting passwords. It's minting sessions.

The CVSS 10 and the workaround guidance suggest a SQL injection somewhere in the reset-password token handling that lets an attacker write into the session table, escalate to an admin row, or otherwise convince the app that the anonymous caller is now a privileged user. CEO Sameer Al-Sakran's own words back this up: "If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised." That is not the language of a subtle bug. That is the language of "we saw them log the request and then we saw them get in."

What makes this class of flaw so devastating in a BI product specifically is the blast radius. A Metabase instance is almost always the point in your infrastructure with the widest data reach and the least production-grade hardening. It holds long-lived credentials to your primary replica, your warehouse, sometimes your event store. It runs behind a nice SSO login page that lulls everyone into thinking it's an internal tool. But the moment a pre-auth path bypasses that login, every downstream credential is loot, mappable straight onto ATT&CK techniques for credential access and collection.

Anyone who has ever run SELECT * FROM core_session in an incident call knows the sinking feeling. The session table is the crown jewels of a web app's identity model, and the fact that Metabase's own remediation guidance tells you to nuke every row in it after patching is the tell. If session forgery were not on the table, they wouldn't need you to invalidate every session on the planet.

Who Gets Burned

Start with the obvious victims. Framework has already gone public. Any company running Metabase self-hosted on a version older than the fixed releases, with the reset-password endpoint reachable from the public internet, should assume compromise until logs prove otherwise. Not "monitor for indicators." Assume. The IoC pattern is easy to grep, and if you find it, you are already in the disclosure business.

The messier group is the fintech and iGaming crowd. Metabase is beloved by data teams at payment startups, sportsbooks, and neobanks precisely because it makes SQL accessible to product managers without giving them raw warehouse credentials. That convenience comes from the tool holding those credentials on their behalf. Every stored connection string for a Postgres replica full of customer PANs, KYC records, or bet histories is now a question mark. Rotate them. All of them. Not just the ones you think were used recently.

Ad-tech platforms sit in a similar spot, with the added wrinkle that their warehouses tend to contain third-party audience data with contractual notification obligations. If your Metabase instance had a Snowflake key stored, and that key had unrestricted role bindings, the next 90 days involve lawyers as much as engineers.

The crypto and DeFi operators who run Metabase against their off-chain analytics stack should be equally worried, but for a different reason. Stolen internal metrics on order flow, liquidity positions, and treasury balances are the kind of thing that ends up on X within a week, weaponized by a competitor or a short-seller. The disclosure risk isn't just regulatory. It's reputational, and the market moves faster than any incident response plan.

Enterprise infra teams running Metabase as their internal metrics dashboard are the quietest casualties. The blast radius here is your own engineering culture: how many warehouse creds did the platform team paste into that instance over the last two years without rotating? Nobody wants to answer that honestly on a Friday.

Playbook for Security Teams

The order of operations matters. Patch to the fixed branch releases first: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, or x.63.5. If you can't patch in the next hour, block /api/session/reset_password at your reverse proxy. Nginx, Cloudflare, ALB rules, whatever you have. That single block breaks the exploit chain in front of unpatched instances.

Then run the IoC grep across your ingress logs and app logs. The POST reset_password 400 followed by GET user/current 200 is a distinctive fingerprint. Extend the window back as far as your log retention allows, because the disclosure calls this a zero-day, meaning exploitation predated the fix. Cross-reference hits against the CISA KEV catalog updates over the coming days, since active exploitation status is likely to land there.

Assume compromise if you find the pattern. Then work Metabase's own post-update checklist: delete every row in core_session to kill active sessions, review and prune unknown API keys, audit every administrator account for changes you didn't make, rotate every credential stored for a connected database, and pull warehouse audit logs to see who queried what and when. Also review Metabase's own activity and query history for exports you didn't authorize.

The bit most teams will skip, and shouldn't: the warehouse credential rotation. If a Metabase-stored Redshift or BigQuery service account was used to exfiltrate data, the fingerprint is in the warehouse audit log, not the Metabase log. Pull it. Read it. Then rotate anyway, because the attacker had ample time to persist elsewhere.

Key Takeaways

• Metabase disclosed a CVSS 10.0 pre-auth SQL injection with no CVE assigned, affecting versions 1.58 and above, fixed in the x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, and x.63.5 releases.
• Metabase Cloud was actively exploited, and Framework has publicly confirmed customer names, login IPs, addresses, phone numbers, and emails were accessed.
• The IoC is a POST to /api/session/reset_password with a 400 status, followed by GET /api/user/current with a 200. That pattern in your logs is a strong signal of compromise.
• Post-patch remediation includes wiping the core_session table, auditing API keys and admin accounts, rotating every connected-database credential, and reviewing warehouse audit logs.
• Metabase patched a similar pre-auth flaw, CVE-2023-38646 at CVSS 9.8, exactly three years ago. The side door keeps getting propped open. Treat BI tools as production-critical attack surface, not internal convenience.

The brick in the side door is out now, and the steel front door was never the problem.