A critical Metabase vulnerability is being actively exploited in the wild to steal customer data, and at least two well-known companies have already confirmed they were hit. Framework Computer and the accounting platform Tally both disclosed breaches tied to the flaw, which is an unauthenticated SQL injection in Metabase versions 1.58 and newer.
If you run Metabase, even a hosted or embedded instance, this is a patch-now situation. The CVE carries a CVSS score of 10.0, which is the top of the severity scale, and the exploit requires no authentication at all.
What the vulnerability is
The flaw is a SQL injection in Metabase, the popular open source business intelligence and analytics tool. Because the injection point is reachable without logging in, a remote attacker can send crafted requests to an exposed instance and escalate all the way to administrator access. From there, the impact gets severe fast.
Once an attacker has admin rights on a Metabase instance, they can pull the credentials for every database the instance is configured to connect to. For most real deployments that is not a toy database. Metabase is usually wired up to the production data warehouse or application database, which means a single unauthenticated flaw can hand an attacker the keys to the entire data estate behind the analytics dashboard.
The good news buried in the description is that Metabase has already shipped fixed versions. The safe releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 depending on the branch you run. Upgrading to the patched release for your series closes the hole.
Who has been hit
Framework, the modular laptop maker known for selling repairable machines, confirmed the theft of a broad set of customer data. The breached data includes full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, company names, and for business customers VAT and EIN numbers. That is roughly everything an attacker needs for targeted phishing and identity fraud.
Tally, the accounting and bookkeeping platform, also confirmed a breach tied to the same Metabase vulnerability. Tally states that email addresses and cryptographic hashes of passwords were taken. Password hashes are less immediately useful than plaintext, but stolen hashes still warrant a forced password reset, especially if there is any chance they were salted or derived weakly.
LexisNexis has also reported impact via a third-party vendor that used the affected software, and took systems offline as a containment step. That is a useful reminder that these flaws do not stop at the company that runs Metabase directly. They ripple through the supply chain to every customer whose data flows through the affected analytics tooling.
How the attack plays out
Security researchers tracking the campaign described a fairly mechanical sequence. An attacker starts with a POST to the password reset endpoint, then follows it with a request that derives an admin session. From the defender’s side, the traffic pattern to watch for is a POST to /api/session/reset_password followed quickly by a GET to /api/user/current. That pairing is the signature of the exploit trying to forge an authenticated administrator session.
Because the exploit is unauthenticated, exposed Metabase instances are at risk even if no user account has ever been compromised. The attacker does not need a valid login. They only need the instance to be reachable over the network.
What admins should do right now
The response steps for anyone running Metabase are straightforward and time-sensitive.
First, upgrade to a patched release for your version series immediately. The fixed versions are listed above. Do not run this behind a patch backlog. The flaw is being actively exploited, so the only reliable mitigation is a known-good version.
Second, rotate the credentials for every database connected to the affected Metabase instance. Assume that if the instance was exposed and vulnerable, the stored database credentials may have been retrieved. Treat the analysis dashboard’s connections as compromised until proven otherwise.
Third, revoke all active user sessions in Metabase and review administrator accounts for unauthorized changes. An attacker who reached admin could have created their own backdoor account, added new users, or altered existing ones.
Finally, check your access logs for the exploit signature: a reset-password POST followed by a current-user GET. That pattern indicates a compromise attempt, and if you find it on a log that predates your upgrade, treat the environment as breached and go through full incident response rather than assuming the upgrade alone fixed things.
Wider lesson
This incident is a reminder that analytics and BI tools sit at an awkward intersection. They are seldom treated as security-critical infrastructure, yet they hold credentials to the most sensitive systems and are frequently internet-reachable. A single unauthenticated flaw in one becomes a high-severity event across every customer whose data touches it, as the Framework, Tally, and LexisNexis disclosures all show.
If you use Metabase, or any BI tool that connects to production databases, treat it as a tier-one asset. Keep it patched, keep it off the public internet or behind proper access controls, and assume that a compromise of it means a compromise of whatever it can reach.