On August 3, 2026, Metabase discovered that its cloud platform had been attacked through a previously unknown zero-day vulnerability, and the fallout is landing in inboxes all week as companies that used Metabase for analytics send their customers breach notifications. The detail that matters for everyone downstream is simple and uncomfortable: a business intelligence tool that stores the credentials to your databases is a single door that, once forced, opens every room behind it. This is what happened, why it is bigger than one bug, and the architecture questions worth asking of any BI vendor — including DashboardFox.
What Happened: The Metabase Zero-Day
According to Metabase's own security advisory, the company identified an attack on Metabase Cloud on Monday, August 3, carried out with an unknown "0-day" vulnerability in versions 1.58 and above. Metabase blocked the endpoints used in the attack, patched the flaw, notified law enforcement, and engaged a third-party forensics firm. Security outlet heise reports the bug is rated CVSS 10.0 out of 10 — the maximum severity — and affects every release from version 58 through 63, in both Metabase's hosted cloud and self-hosted installations.
The mechanism is what makes it dangerous. The weakness sits in the password-reset API endpoint. Once in, the attacker could inject arbitrary SQL against the Metabase application database, escalate to administrator access, change configuration, and then steal the stored credentials for every connected database — reading and exporting any data reachable through those connections. In other words, the breach did not stop at Metabase. It reached whatever Metabase was connected to.
Metabase says its Cloud customers were already upgraded and patched. Self-hosted users are a different story: their instances may still be exposed until they upgrade, and Metabase's stopgap advice is to block the vulnerable endpoint in the meantime. Credit where it is due — Metabase moved fast, disclosed publicly, and gave operators a clear remediation path. That is the right way to handle an incident. But the speed of the response does not undo the structural exposure it revealed.
Why This Is Bigger Than One Bug
The most visible victim so far is Framework, the laptop maker. Per reporting from heise and Framework's own customer notice, the attacker accessed customer names, email addresses, phone numbers, and physical addresses, though not order or payment information. Tellingly, Framework told customers it is now reviewing how much data it shares with business intelligence platforms in the first place. Other companies that ran Metabase are issuing account-wide breach notices in the same window. If your vendors' notifications are piling up, this is why.
And this is not an isolated slip. Metabase has worked through a run of serious issues in 2026 alone: a February flaw that let a low-privileged user extract database credentials through injected notification-email templates, an April remote-code-execution bug that shipped with a public proof-of-concept exploit, and a separate code-execution bypass involving database connection details. Different bugs, same theme. Because the tool holds the keys to your data sources, every vulnerability in it is a potential vulnerability in everything it touches.
That is the real lesson, and it has nothing to do with Metabase specifically. Any BI tool that copies your data into its own store and stashes your database passwords becomes a concentrated, high-value target. The question is not whether a given vendor will ever have a vulnerability — every vendor will. The question is how much damage one vulnerability can do.
The Real Lesson: Architecture Determines Your Blast Radius
Feature checklists dominate BI buying decisions. Security architecture rarely comes up until an incident forces it. It should come up first, because architecture is what decides your blast radius when — not if — something goes wrong. Here are the questions worth putting to any BI vendor, Metabase or otherwise.
Does it store your data, or query it live? A tool that pulls your business data into its own warehouse is holding a copy an attacker can export in one motion. A tool that queries your database live and keeps nothing has far less to lose in a breach.
Where and how are database credentials stored? Connection credentials are the crown jewels. Ask whether they are encrypted at rest, isolated per customer, and never written into logs or configuration in plaintext.
Isolated instance, or shared pool? In a multi-tenant architecture where many customers share infrastructure, the blast radius of a platform-level compromise is every tenant at once. A dedicated, isolated database per customer contains the damage.
Read-only, or can it write back? A reporting tool that has no ability to write to your source databases cannot be turned into a weapon against them, even if it is compromised.
If the vendor's cloud is breached, what are your options? Managed cloud means the vendor patches for you — a real advantage over an unpatched self-hosted box. But the strongest position is having the choice to run the software entirely inside your own network, or fully air-gapped, so your BI data never sits in someone else's cloud at all.
What network controls exist? Static egress IPs for database firewall whitelisting, IP restrictions, and SSH tunneling all shrink the surface an attacker can reach.
Run any vendor through those six questions and the security picture gets clearer than any feature grid.
How DashboardFox Approaches This
Straight talk first: no BI tool is unbreachable, and DashboardFox is not claiming to be. Software has vulnerabilities; the honest goal is to limit how much a single one can cost you and to give you control over where your data lives. With that said, here is how DashboardFox is built against the questions above.
For native database connections — PostgreSQL, MySQL, SQL Server, MariaDB, Oracle — DashboardFox queries your database live and stores nothing. There is no copied dataset of your business data sitting in DashboardFox for an attacker to export. The honest caveat: data you import rather than connect to live, such as Airtable, REST API, or Excel and CSV uploads, is stored — encrypted at rest, in a database dedicated to your account.
That isolation is the default, not an upgrade. Every customer gets their own dedicated, isolated database rather than a shared multi-tenant pool, so a problem in one account does not spill into others. DashboardFox is also read-only by design: it has no functionality to write back to your source databases, so it cannot be used to alter or damage them. Credentials are stored encrypted, never in plaintext or in code, with AES-256 encryption at rest and TLS 1.2+ in transit. Network controls include a static egress IP on every plan for firewall whitelisting, IP restrictions, and SSH tunneling for tighter deployments.
On the deployment question, DashboardFox gives you both roads. The cloud version is managed, so patching is handled for you rather than left to an operator who may not learn about a vulnerability until customer data is already gone. Or you can run the exact same engine self-hosted — including fully air-gapped, with no phone-home — which is the option Framework now sounds like it wishes it had. Behind all of it: a US-based company that has shipped BI software since 1999, where you talk to actual engineers, with annual third-party penetration testing, cyber liability insurance, and SOC 2 Type II in progress.
None of that makes a breach impossible. It makes the blast radius small and the choices yours.
If You Run Metabase Right Now
This part is vendor-neutral advice — if you operate a Metabase instance, act on the incident regardless of what you think about alternatives. Based on Metabase's advisory:
- Upgrade immediately to the minimum safe point release for your major version (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5). If you cannot upgrade right away, block the
/api/session/reset_passwordendpoint as a temporary workaround. - Check your application and ingress logs for the attack signature: a
POST /api/session/reset_passwordreturning a 400, immediately followed by aGET /api/user/currentreturning a 200. That pattern suggests compromise. - If there is any sign of access, rotate the credentials for every connected database, revoke active sessions, review administrator accounts and API keys for anything you do not recognize, and check your data warehouse logs for unauthorized queries or exports.
Versions below 58 are not affected by this particular flaw, but the broader point stands: keep any self-hosted BI tool patched, and know what it would expose if it were breached.
Frequently Asked Questions
What is the August 2026 Metabase breach?
Metabase disclosed that on August 3, 2026, its cloud platform was attacked using a previously unknown zero-day vulnerability rated CVSS 10.0. Attackers could gain administrator access and steal the stored credentials for databases connected to a Metabase instance, then read and export data from them. Metabase patched its cloud and released fixes, but self-hosted instances remained exposed until upgraded.
Which Metabase versions are affected?
According to reporting on the incident, the vulnerability affects Metabase versions 58 through 63, in both the hosted cloud and self-hosted deployments. Versions below 58 are not affected by this specific flaw. Metabase published minimum safe point releases for each major version from 58 to 63.
Was customer data actually stolen?
Yes, in at least some cases. Framework, the laptop manufacturer, confirmed that attackers accessed customer names, email addresses, phone numbers, and addresses through its Metabase instance, though not order or payment data. Other companies that used Metabase for analytics have issued their own breach notifications.
I self-host Metabase — what should I do?
Upgrade to the minimum safe release for your version immediately, or block the password-reset endpoint if you cannot upgrade yet. Then check your logs for the known attack pattern and, if you find any sign of access, rotate all connected-database credentials, revoke sessions, and review admin accounts and API keys. Treat connected-database credentials as potentially exposed.
Why does a BI tool breach expose my databases?
Many BI tools store the credentials to your connected databases so they can query them, and some also copy your data into their own store. When the tool is compromised, those stored credentials and datasets are exactly what an attacker takes, which is how a breach of the analytics layer becomes a breach of the systems behind it.
How does DashboardFox reduce this risk?
For native database connections, DashboardFox queries live and stores none of your business data, so there is no copied dataset to exfiltrate; imported data is encrypted and isolated per customer. Every customer gets a dedicated database rather than a shared pool, the platform is read-only by design, and credentials are encrypted at rest. No BI tool is immune to vulnerabilities, but these choices limit how far a single one can reach.
Can I run BI without putting my data in a vendor's cloud?
Yes. DashboardFox offers a self-hosted version of the same engine that runs inside your own network, including fully air-gapped deployments with no phone-home. That keeps your BI data and database credentials entirely under your control, which is the strongest answer to the risk this incident exposed.
Get Started with DashboardFox
If this incident has you rethinking where your analytics data lives and who holds the keys to it, that is the right question to be asking. DashboardFox is built to keep the blast radius small — live queries that store nothing for direct connections, an isolated database per customer, read-only access by design, and the option to run it entirely in your own environment. See how it stacks up on the DashboardFox vs. Metabase comparison and the security overview, or start a free trial and connect your first database in minutes.