The last time you thought about your Metabase instance, you were probably admiring a dashboard. Maybe a nice funnel chart. Perhaps a bar graph that made your quarterly numbers look less depressing than they actually are.
Here’s the thing: attackers were thinking about your Metabase instance too. And they found something you didn’t want them to find.
If you’re self-hosting Metabase, stop reading and check your version right now. The rest of this article will still be here when you get back.
What Actually Happened
Let’s break down the timeline because it matters.
Attackers found a flaw in Metabase’s /api/session/reset_password endpoint, the password reset flow that should be innocuous, boring, and utterly uninteresting. Instead, it became the doorway to everything.
The exploit chain works like this:
- Attacker sends a
POSTrequest to/api/session/reset_password, the first request typically returns a 400 status code as the attacker probes the injection point - The SQL injection allows arbitrary query execution against the Metabase application database
- The attacker escalates to full administrator privileges on the instance
- From there, they can steal stored credentials for all connected databases, modify application configuration, read any data accessible through those connections, and export whatever they want
Metabase’s CEO Sameer Al-Sakran confirmed the attack pattern in the official security update. The company detected the attack against its own cloud infrastructure first, then moved to block the endpoints and patch the flaw.
The uncomfortable part? This was a genuine zero-day. Real attackers found the vulnerability before Metabase did. The company only learned about it because the exploit was being used against Metabase Cloud itself.
The Blast Radius Is Worse Than You Think
You might be thinking: “Okay, it’s a BI tool. What’s the worst that could happen?”
The answer is: everything.
A business intelligence platform sits at the intersection of your company’s most sensitive data. It’s the tool that connects to your data warehouse, your production database, your customer records, all the things you’d never expose directly to the internet, but happily feed into a dashboarding tool because it makes pretty charts.
“From there, the attacker could change the application configuration, steal stored credentials for the connected databases, read any data accessible through those connections, and export data.”
That’s not theoretical. That’s what happened.
Framework, the modular laptop maker, confirmed that attackers accessed customer names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. For Framework for Business customers, the haul also included VAT numbers, EINs, and billing emails.
Tally, the online form builder, reported that customer email addresses and password hashes were exposed through its compromised Metabase environment.
LexisNexis detected unusual activity on third-party vendor servers running Metabase and disconnected affected systems while conducting an investigation.
The pattern here should scare you: attackers didn’t target these companies directly. They targeted the analytics tool these companies used to understand their data. One vulnerability, multiple breaches.
The “We Only Store Hashes” Trap
Tally’s response deserves special scrutiny. The company told users that “a hash is one-way, so it can’t be turned back into your password.” Technically true. Practically dangerous.
Password hashes are only as secure as the algorithm used to generate them, whether they’re salted, and how much compute an attacker is willing to throw at cracking them. BleepingComputer asked Tally which hashing algorithm was used and whether the exposed hashes were salted, the company didn’t respond at the time of publication.
Silence on that question is not reassuring.
If Tally used bcrypt with per-user salts, the risk is manageable. If they used MD5 or SHA-1 without salts, a terrifyingly common practice, those “one-way” hashes are effectively plaintext for a determined attacker with a GPU cluster.
The bigger question the community has been asking: why did a form builder need customer phone numbers and physical addresses in a BI tool in the first place? The discussion on Hacker News around this point is sharp. Every piece of PII you load into your analytics stack expands your breach surface. Every unnecessary field is a gift to attackers.
Affected Versions and Patches
Here’s the version matrix from the advisory. If your version falls in the affected range, you have work to do:
| Major Version | Affected Range | Minimum Safe Release |
|---|---|---|
| 0.58 | >= 0.58.0, < 0.58.23 | 0.58.24 |
| 0.59 | >= 0.59.0, < 0.59.20 | 0.59.21 |
| 0.60 | >= 0.60.0, < 0.60.16 | 0.60.17 |
| 0.61 | >= 0.61.0, < 0.61.10 | 0.61.11 |
| 0.62 | >= 0.62.0, < 0.62.8 | 0.62.9 |
| 0.63 | >= 0.63.0, < 0.63.3 | 0.63.5 |
If you’re running version 0.57 or earlier, you’re not vulnerable to this specific flaw. If you’re on version 1.58 or above in any branch, upgrade immediately.
Metabase Cloud customers are already patched, the company handled that automatically. Self-hosted deployments require manual intervention.
The Docker image for each patched version follows the pattern metabase/metabase:v0.X.Y. For example, the fixed 0.63 branch is metabase/metabase:v0.63.5. JAR downloads are also available at downloads.metabase.com.
Your Incident Response Checklist
If your /api/session/reset_password endpoint was publicly accessible, and for most self-hosted deployments, it was, the patch alone isn’t enough. Metabase’s remediation checklist assumes the worst:
- Revoke all active user sessions, delete all rows in the
core_sessiontable from your Metabase application database - Review API keys, delete any you don’t recognize
- Audit administrator accounts, look for unexpected changes or new admin users
- Rotate credentials for all connected databases, assume the attackers have them
- Review data warehouse logs, look for unauthorized access
- Check Metabase activity and query history, look for queries you didn’t run
The session reset is critical. If attackers established sessions before you patched, those sessions persist unless you actively invalidate them. The core_session table is where Metabase stores session tokens, wiping it forces everyone to re-authenticate, including any attacker with a valid token.
Detecting the Attack in Your Logs
Metabase published a specific attack signature that’s worth hunting for right now:
- A
POSTrequest to/api/session/reset_passwordreturning a 400 status code - Followed by a
GETrequest to/api/user/currentreturning a 200 status code
If you see that pattern in your application logs or ingress logs, your instance has likely been compromised. That 400 response is the attacker probing the injection point, the 200 on /api/user/current is them confirming their admin session works.
Run this hunt even if you think you weren’t targeted. The window between August 3 (when Framework and Tally were hit) and August 6 (when the patch shipped) was wide open.
The Temporary Workaround
If you can’t patch immediately, and I genuinely can’t think of a good reason why you can’t, given a CVSS 10.0 with active exploitation, block the /api/session/reset_password endpoint at your load balancer, firewall, or reverse proxy.
This breaks password resets for legitimate users. That’s an acceptable tradeoff when the alternative is a complete takeover of your analytics infrastructure. Password resets can wait, your database credentials shouldn’t be in an attacker’s hands.
The Deeper Problem: BI Tools Are Security Blind Spots
This incident exposes something uncomfortable about how organizations treat their analytics stack. We spend enormous resources securing production databases, authentication systems, and cloud infrastructure, then connect all of it to a BI tool that’s resting comfortably behind a basic login page.
The Metabase flaw isn’t an isolated incident. This is the second time the platform has faced a severe pre-authentication vulnerability, following CVE-2023-38646 (CVSS 9.8) which allowed remote code execution on unpatched installations. History suggests we should stop calling these “one-off mistakes” and start recognizing a pattern.
The problem extends beyond Metabase. Supply chain attacks via CI/CD pipelines and malware injection in trusted code repositories demonstrate the broader reality: every piece of infrastructure between your users and their data is a potential attack surface. BI tools are uniquely dangerous because they sit at the data junction point, they need credentials to your most valuable systems to function, and they’re rarely given the same security scrutiny as the databases they connect to.
And here’s the uncomfortable question no one wants to answer: if a BI platform can be popped with a CVSS 10.0 unauthenticated SQL injection, what’s waiting in the other reporting tools, analytics platforms, and dashboarding solutions you’re running?
This is exactly the kind of issue that exposes why patching CVEs doesn’t guarantee security. You can close every known vulnerability on your books, and a zero-day can still walk right through the front door.
What This Means for Your Architecture
If you’re an architect or platform engineer, this incident should reshape how you think about your analytics stack:
Treat BI tools as Tier 0 infrastructure. They’re not dashboards, they’re credential vaults with visualization layers. They deserve the same network segmentation, monitoring, and access controls as your production databases.
Question the data flow. Does your BI platform genuinely need access to customer PII? Framework’s breach exposed a complete phishing kit, names, addresses, phone numbers, emails, because someone decided that data belonged in the analytics tool. The community reaction on Hacker News was sharp: a phishing email built from this data would look nearly identical to a legitimate Framework email. When you reduce the data in your analytics stack, you reduce the value of breaching it.
Plan for the inevitable. Assume your analytics platform will be breached. Design your data warehouse permissions, credential storage, and network architecture so that a BI compromise doesn’t become a total data breach. The attackers in this case were able to steal stored credentials for connected databases, that suggests Metabase was holding credentials with more access than the BI workload actually needed.
Build detection, not just prevention. The attack pattern, POST to reset_password returning 400, then GET to user/current returning 200, is specific enough to alert on. Add it to your SIEM, your log monitoring, your anything-that-looks-at-requests. That’s not just a Metabase problem, it’s a pattern for any unauthenticated endpoint in your stack.
The ASCII-Art Elephant in the Room
The most frustrating part of this incident? The vulnerability lives in password reset functionality, a feature that exists to help users who forgot their credentials. It’s the sort of endpoint that engineering teams implement quickly, test superficially, and never think about again.
That’s precisely why it was exploitable. The password reset flow is authentication-adjacent, which means it’s subject to careful security review, but it’s also low-traffic and rarely exercised, which means bugs hide longer.
The attackers didn’t target Metabase’s complex features. They went after the boring, routine, “why would anyone attack this” endpoint. And they got everything.
What You Should Do Right Now
The checklist is short, and it’s time-sensitive:
- Check your Metabase version immediately. Click the gear icon, select “About Metabase”, and verify your version against the table above. If you’re below the minimum safe release for your branch, you’re vulnerable.
- If you’re vulnerable, upgrade now. Not tomorrow. Not after the sprint ends. Now.
- Run the log hunt. Search for the attack pattern, POST to
/api/session/reset_passwordwith a 400 status, followed by GET to/api/user/currentwith 200. If you find it, treat the instance as breached. - If the endpoint was exposed, run the full remediation checklist. Session revocation, credential rotation, admin audit, log review. Every step.
- Rotate your database credentials anyway. Even if you don’t find evidence of compromise, the cost of rotation is lower than the cost of another Framework-style breach notification.
The good news: Metabase Cloud customers didn’t need to do anything, and the patches are available for all affected self-hosted versions. The bad news: the window between the first known exploitation (August 3) and the patch (August 6) was wide enough that multiple major companies got hit.
And if you’re running a self-hosted instance and you haven’t checked your version yet? That’s the single most actionable thing you can do right now. The dashboards will still be there when you finish. Hopefully, so will your data.
For deeper reading: check out how AI agents are becoming security nightmares and why building AI-powered vulnerability scanners is harder than it looks, both relevant to how we’ll need to defend against attacks like this in the future.