TL;DR - Metabase disclosed a critical SQL injection vulnerability on 7 August 2026 after it was already used to steal customer data from real companies. The flaw scores CVSS 10.0, requires no authentication, and gives a remote attacker administrator access to the instance. Cloud customers were patched for you. If you run Metabase self-hosted, the job is this week: upgrade to a patched version, then hunt for the compromise signature before you trust the instance again. What you need to do: identify your version, patch to the minimum safe release for your branch, and check logs for the indicator Metabase published.
On Thursday I did what I do with every self-hosted BI tool a client trusts with the crown jewels: I checked which version it was running, and whether it had any business being exposed to the internet at all.
It took four minutes. Version 0.62.6, reachable from the office VPN, holding the credentials for two customer databases and a pile of dashboards nobody had opened since April. Four minutes of work I have done a hundred times. Only this week it turned out the same question was about to be asked by a lot of people, the hard way, because the free BI tool a thousand SMBs run without thinking was the thing attackers had already broken into.
On 7 August, Metabase disclosed a critical SQL injection vulnerability that had been exploited as a zero-day to breach customer instances. Laptop maker Framework and form builder Tally have both confirmed customer data was stolen. LexisNexis says one of its products was impacted through a third-party vendor. Cloud customers were upgraded automatically. If you host Metabase yourself, nobody is doing this job for you.
The vulnerability needs no authentication and scores 10 out of 10 on CVSS. Metabase confirmed it was already actively exploited before the advisory went public.
Why this one matters more than the patch noise
Metabase is the analytics tool an SMB stands up on a quiet Friday because it is free, it has a nice interface, and the sales engineer at the SaaS vendor said dashboards would change everything. Then it quietly becomes the place where the business keeps its numbers, and more importantly, the stored credentials for the databases underneath those numbers.
That is exactly what made it a target. An unauthenticated SQL injection that hands over administrator access to the Metabase application database is not a defacement bug. From that position an attacker can change the application configuration, steal the stored credentials for connected databases, read any data reachable through those connections, and export it. One flaw, one endpoint, and the BI tool becomes the key to every database it was built to report on.
The affected surface is not small. Metabase says the vulnerability affects versions 1.58 and above, and self-hosted installations are vulnerable in the same way the cloud platform was. Cloud customers have already been upgraded and patched. Everyone else has to do it manually, which is precisely the population that does not have a scheduled patch window for a tool most people forgot was internet-adjacent.
By The Numbers
| Number | What it means |
|---|---|
| 10.0 | CVSS score, the maximum. Critical, actively exploited, no authentication required |
| 6 | Affected branches from 0.58 through 0.63 that need a minimum safe release |
| 0.63.5 | Highest minimum safe release: v63.5 fixes the last affected branch |
| 400 | The status code of the suspicious POST to /api/session/reset_password that marks a likely hit |
| 3 | Companies publicly confirmed or flagged so far: Framework, Tally, and LexisNexis |
| 3 Aug | Earliest confirmed date of access: both Framework and Tally instances were hit on this day |
What the attack actually does
The flaw is an unauthenticated SQL injection reachable through the password reset flow. Metabase's security advisory is blunt about the blast radius: a remote attacker can inject arbitrary SQL into the Metabase application database, gain administrator access to the instance, change configuration, steal stored credentials for connected databases, read any data accessible through those connections, and export it.
Translate that into SMB terms. Your Metabase instance is not the crown jewels. The crown jewels are the customer database it connects to, the credentials it holds for that database, and the dashboards that let anyone with admin access walk the whole company's numbers. An attacker who owns Metabase admin does not need to break into the database directly. They log in through the tool that was already allowed to.
That is the part worth pausing on. A lot of incident response starts with "how did they get into the database?" This one starts with "they came in through the reporting tool, and the reporting tool had the password."
The companies that already disclosed
This is not a theoretical disclosure. Framework, the laptop maker, told customers that an attacker accessed its Metabase instance on 3 August. Stolen data includes full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. Framework for Business customers may also have had company name, phone number, VAT, EIN, and billing email taken.
Tally, the form builder, said its Metabase analytics environment was compromised the same day. The attacker reached email addresses and passwords stored as cryptographic hashes. Tally is explicit that forms and submitted answers are stored separately and were not reached. Note the wording: password hashes were taken, and at the time of disclosure the hashing algorithm and salting had not been publicly confirmed. If you were a Tally user, treat those hashes as compromised until a vendor update says otherwise.
LexisNexis warned customers that its Diligence, Metabase API, and Newsdesk products were affected by an attack at a third-party vendor, disconnected the systems, and was working with a forensic firm. Whether customer data was exposed there is still under investigation.
Three different kinds of organisation, one common thread: a self-hosted or vendor-hosted Metabase instance, hit through the same unauthenticated flaw, with data theft as the goal.
Check your version, then patch
Metabase has published patched versions for every affected branch. The minimum safe releases are:
| Branch | Minimum safe version |
|---|---|
| 0.58 | 0.58.24 |
| 0.59 | 0.59.21 |
| 0.60 | 0.60.17 |
| 0.61 | 0.61.11 |
| 0.62 | 0.62.9 |
| 0.63 | 0.63.5 |
The check takes five minutes:
- Log in to your Metabase instance and note the version from the settings or about page.
- Compare it against the table. Anything older than the minimum for its branch is vulnerable.
- Upgrade from the Metabase release page or your usual package path. Both OSS and Enterprise (EE) builds are covered.
- Do not assume your cloud-hosted provider patched it. If a client or a department runs Metabase inside their own VPS, Docker, or Kubernetes, that is the instance at risk.
If you genuinely cannot upgrade this week, Metabase's temporary workaround is to block access to the /api/session/reset_password endpoint. That slows the specific attack path. It is a stopgap, not a fix, and it should not be your plan for longer than it takes to schedule the upgrade.
Forward this checklist to whoever runs your Metabase instance, even if that person is you. The difference between a patched instance and an unpatched one is this week.
Hunt for the compromise signature before you trust it
Patching a vulnerable instance is only half the job. Metabase published a specific signature for the attack: a POST request to /api/session/reset_password returning a 400 status code, followed by a successful GET request to /api/user/current. If your logs show that pairing, treat the instance as compromised, not just patched.
The advisory also lists the cleanup steps for an instance where the reset endpoint was publicly reachable. Run them all:
- Revoke all active user sessions by deleting every row in the
core_sessiontable in the Metabase application database. - Review API keys and delete any you do not recognise.
- Review administrator accounts for unexpected changes.
- Rotate credentials for every connected database.
- Review data warehouse logs for unauthorised access.
- Review Metabase activity and query history for anything unexpected.
That last pair is the one most teams skip. Rotating the database password does not help if the attacker already exported data or left a hidden API key behind. The log review is what tells you whether this was a close call or a quiet week of exfiltration.
And if you are running the vulnerable version and you cannot account for every API key and admin account, treat the instance as suspected-compromised until you can. The cost of assuming the best is another Framework or Tally notification, this time with your name in the subject line.
FAQ
Is my Metabase Cloud instance affected?
Metabase says Cloud customers have already been upgraded and patched. Verify with your account contact rather than assuming, but the managed offering was handled on your behalf.
Which versions are vulnerable?
Versions 1.58 and above, with patched minimum releases from 0.58.24 through 0.63.5 across branches 0.58 to 0.63. Check your version against the table above.
Do I need to worry if Metabase is only on my internal network?
The exploit is unauthenticated and was used in real attacks. Internal-only reduces exposure but does not remove it: one compromised laptop, VPN session, or guest network can reach an internal instance. Patch anyway.
Was the vulnerability assigned a CVE?
Not at the time of the disclosure. Metabase rated it Critical with a CVSS score of 10.0 and confirmed active exploitation.
What data did the attackers take?
Publicly disclosed so far: Framework customers had names, emails, IP addresses, billing and shipping details, and phone numbers taken. Tally confirmed email addresses and password hashes. Both instances were accessed on 3 August.
My take
I have stood in front of enough dashboards to know why Metabase ends up on a VPS with no patch process. It was free, it was easy, and the person who set it up moved on to another project six months ago. Nobody owns the BI tool, which means nobody owns the credentials it quietly holds.
The disclosure pattern here is the important part. This was a zero-day used in real attacks, disclosed after the fact, with patch versions and a compromise signature published together. That is the best-case outcome for a bad situation. The teams that act this week get a clean upgrade and a log check. The teams that wait for next month's patch cycle get to find out whether the attacker beat them to it.
The four-minute version check I do on every client BI tool is not a security strategy. It is the minimum bar. This week it happens to be the difference between patching a hole and investigating a breach.
Forward this to whoever owns your Metabase instance, and run the log check with them while the week is still quiet. The patch is the easy half. Knowing whether you were already hit is the part that decides what happens next.
Mathew Clark
Founder, SecureInSeconds
Currently: checking version numbers on every BI dashboard I can reach, and finding four-minute jobs that just got urgent.
Further Reading
- Metabase SQLi zero-day exploited in customer data-theft attacks (BleepingComputer)
- SQL injection using an unauthenticated endpoint leading to admin access (Metabase advisory, GitHub)
- Metabase security update blog post
- SecureInSeconds: the August 2026 patch Tuesday breakdown
- SecureInSeconds: Windows Defender and the RoguePlanet zero-day
- SecureInSeconds: verify before you patch, the CISA KEV triage workflow
- SecureInSeconds: the MFA fatigue playbook for session revocation
