Vulnerability · Application Security

Metabase SQLi Zero-Day Exploited in Customer Data-Theft Attacks

August 10, 2026 · 6 min read

On August 3, 2026, attackers exploited an unauthenticated SQL injection vulnerability in Metabase Cloud before anyone knew the flaw existed. The vulnerability carried a CVSS score of 10.0 and required no credentials to trigger. By the time Metabase disclosed the incident publicly on August 6 and pushed patches, at least two organizations, Framework and Tally Forms, had already lost customer data. For every team running a self-hosted Metabase instance, that gap between exploitation and public disclosure was the window that mattered.

What actually happened

Metabase is a widely used open-source business intelligence and data visualization platform. On August 3, 2026, Metabase identified an active attack against its cloud environment using an unknown zero-day SQL injection flaw affecting versions 1.58 and above (open-source branches 0.58 through 0.63). The flaw, tracked as GHSA-vwf4-m7j8-wcjf, allows a remote unauthenticated attacker to inject arbitrary SQL into the Metabase application database and obtain full administrator access. No CVE identifier had been assigned as of the reporting date.

Once an attacker holds admin access through this path, the blast radius extends further. According to the GitHub Security Advisory, an attacker could alter application configuration and steal the stored credentials for any databases connected to the Metabase instance. That last point matters because Metabase is almost always connected to production or near-production data sources. The analytics tool is the bridge.

Metabase patched its cloud environment and disclosed publicly on August 6, 2026. That same day, Framework, the maker of modular and repairable laptops, received notification from Metabase that its instance had been compromised. Framework sent customer notification emails on the evening of August 6. A spokesperson confirmed the breach affected all customers but declined to provide a specific count. Stolen data included full names, email addresses, login IP addresses, billing and shipping addresses, and phone numbers. For Framework for Business customers, company name, VAT, EIN, and billing email were also in scope. Payment and order data were not accessed.

Tally Forms, a form-building SaaS product, was also breached through the same vulnerability. Co-founder Filip Minev disclosed that an attacker gained unauthorized access to Tally's Metabase analytics environment. Metabase notified Tally on August 6 and access was shut down the same day. The data stolen from Tally users included email addresses and password hashes. Whether those hashes were salted or what algorithm was used was not specified in the breach notification.

Metabase Cloud customers were patched automatically. Self-hosted operators on any affected version had to upgrade manually. Fixed versions include 0.58.24 / 1.58.24, 0.59.21 / 1.59.21, 0.60.17 / 1.60.17, 0.61.11 / 1.61.11, 0.62.9 / 1.62.9, and 0.63.5 / 1.63.5. A temporary mitigation was blocking the /api/session/reset_password endpoint while a full upgrade was staged.

Why this should matter to you even if you don’t run Metabase

The organizations that got hit here, Framework and Tally, were almost certainly running Metabase for perfectly reasonable operational reasons. Metabase is a legitimate, widely adopted tool. That is exactly what makes this pattern worth paying attention to. The BI and analytics layer sits at the intersection of your data warehouse, your production databases, and your cloud credentials. It is treated as an internal tool rather than an externally facing attack surface, which means it often gets less scrutiny in patch cycles and firewall rule reviews than your customer-facing applications.

A CVSS 10.0 unauthenticated injection flaw is about as severe as vulnerabilities get. No phishing, no credential stuffing, no insider access required. An attacker with network access to the Metabase endpoint could go directly from anonymous to administrator. If your Metabase instance is reachable from the public internet, or from a network segment that an attacker could reach after an initial foothold, the attack path is short.

The self-hosted deployment model compounds the problem. Cloud-hosted customers were patched automatically, without any action on their part. Self-hosted operators had to know a patch existed, understand the severity, prioritize it against everything else in their queue, test the upgrade, and deploy it. In environments where the team running Metabase is the data or analytics team rather than the security or infrastructure team, that chain of awareness and action can take days or weeks. The three-day window between the August 3 attack and the August 6 public disclosure was not available to defenders. Attackers moved during the zero-day period, before any patch existed.

The credential theft angle deserves specific attention. Metabase stores connection strings and credentials for the databases it queries. If attackers can alter configuration and read those stored credentials, the Metabase breach becomes an initial access event for whatever sits behind it. One compromised analytics instance can become the key to a data warehouse or a production database. Organizations running Metabase should treat those downstream connections as potentially compromised, even if those systems show no direct signs of intrusion.

The control that would have blunted it

The control category here is vulnerability management, specifically the patch management component that covers third-party and internally deployed software tools, not just operating systems and first-party applications. Cyber insurers increasingly ask about this during underwriting and at renewal. A policy that requires patching of internet-facing systems within a defined SLA (commonly 14 to 30 days for critical vulnerabilities) is only meaningful if your inventory actually includes tools like Metabase. If it is not in your asset inventory, it is not in your patch SLA, and it is not in your risk picture.

For self-hosted Metabase specifically, the operational reality is that upgrade testing takes time. Metabase upgrades occasionally involve database migrations or configuration changes that need validation before production deployment. That friction is real, and it is one reason analytics tools drift behind on patch currency. One practical approach is to stage a non-production Metabase instance that mirrors your production configuration closely enough to catch upgrade issues, so the testing cycle can run faster when a critical patch drops. That does not eliminate the window, but it shortens it meaningfully.

Network segmentation is the other control that would have reduced the blast radius here. A Metabase instance that is not directly reachable from the public internet, that sits behind a VPN or an internal load balancer with access restricted to known IP ranges, requires an attacker to already have a foothold before they can reach the vulnerable endpoint. That does not make the vulnerability irrelevant, but it removes the unauthenticated remote exploitation scenario. Many teams expose Metabase dashboards to a broader internal network or even externally for convenience. Reviewing that exposure is worth doing this week regardless of whether you have already patched.

Finally, the stored credentials issue points to a principle that applies well beyond Metabase. Credentials stored in analytics and BI tools should follow least-privilege database accounts with read-only access scoped to the schemas those tools actually need. An attacker who steals a read-only credential for a specific reporting schema is in a meaningfully worse position than one who steals an account with broad read-write access across your data warehouse. Rotating those credentials after this incident, and auditing what permissions they carry, is a concrete post-incident action regardless of whether you believe your instance was affected.

Strondex's vulnerability management platform helps teams maintain accurate software inventory across self-hosted tools and internally deployed applications, so critical patches like this one get tracked and assigned within your existing SLA commitments.