Metabase CVE-2026-72898 (CVSS 10.0) Leaked Customer Data — Patch Now

A flaw has been found in Metabase, the popular tool companies use to turn their data into charts and tables, that lets anyone impersonate an administrator from the outside with no login and no password whatsoever. It is tracked as CVE-2026-72898, with a severity of 10.0 out of 10. And this is not a story of "found, then fixed." It was used in real attacks while no patch existed, and only disclosed after the damage was done.

The damage is already public. Framework, the maker known for easily repairable laptops, notified "all customers" on August 7 that their names, addresses, phone numbers, email addresses, and login IP addresses had been accessed (TechCrunch). The workflow automation tool n8n, the form builder Tally, and the AI coding assistant Kilo Code have all disclosed in turn. None of them had their own systems broken into. In every case, the Metabase instance they used for internal analytics was the way in.

On August 11, CISA, part of the U.S. Department of Homeland Security, added the flaw to its catalog of vulnerabilities confirmed to be under active attack and ordered federal agencies to remediate by August 14 (you can also track the latest additions to that catalog here). If you use Metabase Cloud, the fix has already been applied on the provider's side, but if you run it yourself on your own servers or in Docker, updating is on you. Every release from 1.58 onward is affected, and the versions you need to move to are laid out in the table below.

What Metabase actually is

Metabase is what the industry calls a BI tool. It connects to the sales, membership, and other data sitting inside a company and lets people build charts and tables without writing code. BI stands for business intelligence, which really just means tools that make data easy to look at so that management and frontline staff can act on it. Released in 2015 as open-source software, it is reportedly used by around 50,000 companies worldwide, and its "set it up in five minutes, hand it to everyone" simplicity has spread it from engineer-led startups to single departments inside large enterprises.

What matters here is that Metabase connects directly to production databases. It is installed as a window onto a company's core data: sales systems, customer records, inventory. Which means that when the Metabase server itself is taken over, the attacker also gets at the connection credentials for every database behind it. It looks like a mere analytics tool, but it is really a ring of keys sitting at the center of the company's data.

That structure is exactly why the Framework and n8n incidents took the shape of "our systems were never attacked, yet customer data got out." You can guard your product database and membership system as tightly as you like, but if the screen you set up to look at those numbers faces outward, the same data is reachable through it. Convenient internal tools turning into a doorway into the whole company is a pattern we have seen before, including in the flaw that let attackers hijack the traffic gateway of the low-code platform Appsmith.

What was actually stolen using CVE-2026-72898

What makes CVE-2026-72898 decisively different from Metabase's earlier vulnerabilities is that it was disclosed at the "it already happened" stage, not the "it could happen" stage. Between August 2 and 3, attackers used a hole nobody yet knew about to get into Metabase's cloud platform and pull customer data out of the environments hosted there. Metabase itself noticed something was wrong on August 3, and notified affected customers on August 6. The companies involved had no way to spot it themselves; they learned about it only when the notice arrived.

Framework: every customer told "you are affected"

Framework drew the most coverage. It is a U.S. maker of laptops whose parts can be swapped and repaired individually, and its right-to-repair stance has earned it strong support among technical users. On August 6, the same day it heard from Metabase, the company rotated every credential for the databases it had connected, then emailed all customers on the 7th.

Accessed data included names, email addresses, physical addresses, phone numbers, and login IP addresses. For business customers, company names, VAT or tax identification numbers, and billing email addresses were also in scope. On the other hand, the company says payment details such as credit cards, and order histories, were not included (The Register). This is not the kind of leak where money is taken directly, but with addresses and phone numbers together, it is more than enough raw material for scam emails and calls pretending to come from the store.

n8n: 136 records, five of them with password hashes

n8n, the tool that automates business processes by wiring steps together on screen, used Metabase for internal analytics. The company issued a first report on August 8 and detailed findings on the 11th. In total, 136 records containing names and email addresses were accessed: 7 with cloud usernames and emails, 5 with names, usernames, emails, and hashed passwords, 62 with names and emails where access could not be confirmed, and 62 containing no sensitive information.

The count looks small, but during the investigation n8n also found and disclosed that a historical bug had left roughly 25 passwords stored without encryption. It considers it unlikely those were read in this incident, but the inquiry surfaced a separate problem all the same. The company filed with the Berlin data protection authority and emailed affected users individually asking them to reset their passwords. Disclosing the full breakdown even when the damage is small is worth comparing against how other companies write their notices.

Tally, Kilo Code, and Checkly followed

The form builder Tally announced on August 7 that email addresses and hashed passwords had been accessed, while stating explicitly that "they didn't reach your forms, or the answers people submitted to them" (BleepingComputer). Anaconda, which operates the AI coding assistant Kilo Code, pinned the intrusion down to a roughly four-hour window on August 2 and disclosed that Slack integration tokens for a small subset of users had been exposed. The monitoring service Checkly followed on August 10.

The common thread is that none of them had their production systems breached. What the attacker touched was the data gathered for analysis. Yet data gathered for analysis almost always contains names and email addresses. Guarding a production database rigorously means little if the copy you placed in an analytics platform is not guarded to the same standard — a reality that comes through in all five disclosures.

Who goes after this hole, and what happens next

Who first used this hole has not been disclosed. But judging by the behavior, it is natural to assume the target was set by a group that specializes in stealing corporate customer lists and trading them. Intrusion to exfiltration took only hours, and rather than wrecking servers or demanding a ransom, they walked away with nothing but tables of names and email addresses.

What they do is almost anticlimactically simple: send one crafted string to the password reset endpoint that is deliberately open to everyone. That alone hands them a session logged in as an administrator. From the admin screen they then read the connection credentials for every database wired into Metabase and export the customer lists sitting inside. From the attacker's point of view, this is less like cracking a locked safe and more like befriending the clerk who copies the safe's contents onto a desk every morning.

What ordinary users of these services lose is names, email addresses, physical addresses, and phone numbers — material that works as-is for fraud. When a message arrives saying "regarding your recent purchase" with your real name and address written correctly, most people do not question it. What the operators lose is not only the data itself. Because the connection credentials for the databases behind Metabase were exposed, there is no guarantee the damage stopped at Metabase, and that is where the investigation has to start. That is why Framework rotated every credential the same day it was notified. How to tell whether you need to make the same call is covered under "How to spot signs of intrusion" below.

What is happening technically

Four server-takeover flaws with different routes have been disclosed in Metabase over the past two months. The most severe is this one, CVE-2026-72898, and it is the only one that requires no account at all. The other three assume some level of login privilege. We will go newest first.

CVE-2026-72898: SQL poured into the password reset endpoint

The stage is an endpoint called POST /api/session/reset_password. It is where someone who forgot their password submits the token they received by email along with a new password, and by its nature it is exposed so that people who are not logged in can reach it. The only things it was supposed to accept were those two values.

But Metabase's handling carried extra fields along instead of discarding them when they were mixed into the submitted data. According to analysis by the security firm Wiz, an attacker sends the two expected fields plus a fabricated internal field that points at a user. Clojure, the programming language Metabase is built in, has a merging behavior that lets unknown keys pass through untouched, so the fabricated field flowed straight downstream.

The last line of defense is the part that assembles the database query. Normally a placeholder mechanism treats externally supplied values as values, never as commands. But the fabricated field carried an instruction saying "embed these contents into the statement verbatim, unprocessed." Because that instruction was honored, the query the attacker wrote ran in full against Metabase's own application database. Rewrite the table holding user records directly, and you have created an administrator session for yourself. The U.S. National Institute of Standards and Technology (NIST) classifies this as the textbook case of externally supplied text being treated as a command (CWE-89).

The severity landed at a perfect 10.0 because no authentication, no privileges, and no user interaction are required, and because the damage spills past Metabase itself onto the databases behind it. Steps to reproduce the attack have been circulating since around August 10, so any unpatched instance that gets discovered can be hit by anyone.

CVE-2026-59827: swallowing a planted payload in query results

A severity 9.9 flaw disclosed at the end of June. Metabase lets users write and run raw SQL, the query language for databases. When that raw SQL is run against the bundled lightweight database called H2, the returned results can include a column of type "OTHER." The problem was that Metabase restored the contents of that column into a Java object (deserialized it) without validation. Deserialization is the process of turning data that was serialized into text for storage or transmission back into live objects in a program.

Attackers turn this against Metabase by slipping a crafted object into the query results that springs malicious instructions the moment it is restored. The instant Metabase reassembles it without suspicion, the attacker's commands run on the server. NIST classifies this as deserialization of untrusted data (CWE-502). No administrator privileges are needed; an ordinary user account able to run SQL is enough. Because the default H2 sample database is itself a viable route, most Metabase instances in the standard configuration are affected.

CVE-2026-50148: swapping the driver via a Snowflake connection

Disclosed in July, also rated 10.0. The stage is the mechanism Metabase uses to connect to the external data storage service Snowflake (a so-called data warehouse, where large volumes of data are stored and analyzed in the cloud). Metabase loads components called drivers to connect to the various databases it supports, and the Snowflake driver had a flaw that let the server on the other end write arbitrary files onto the machine running Metabase.

To exploit it, an attacker first configures a Metabase connection pointing at a fake Snowflake server of their own. When Metabase connects, the fake server quietly overwrites Metabase's own driver component with a malicious one. The next time Metabase loads that driver, the substituted contents run as program code. Trace it back and the root cause is a flaw in the bundled Snowflake JDBC driver (the standard component for connecting to databases from Java), giving this one a supply-chain character born of depending on outside components. The same shape was noted in the vulnerability in Snowflake's command-line tool, and if you want to audit the components your own products pull in, our guide on how to check the safety of open-source components is a useful companion. Exploitation requires the privilege to add or modify database connections, which normally means an administrator.

CVE-2026-59826: slipping past the check on dangerous connection settings

A severity 9.1 flaw whose stage is the screen for registering a new database connection in Metabase. H2 connection strings can carry directives that automatically run SQL during initialization. Abusing such a directive lets arbitrary programs run on the server, so Metabase was supposed to reject dangerous connection settings. But the check could be bypassed along certain paths, so an administrator registering a crafted H2 connection ends up executing arbitrary Java code on the server. NIST files this under improper control of code generation (CWE-94).

Why Metabase keeps getting targeted

This is not Metabase's first takeover vulnerability. In 2023, a critical hole exploitable before login (CVE-2023-38646, severity 9.8) was found and CISA added it to its actively exploited list. That episode pushed Metabase to stop officially supporting H2 as a connection target for new installations. Even so, 2026 has brought serious flaws in March, June, July, and August, each by a different route.

The reason lies in what Metabase is. Connecting to every kind of database is its selling point, so the number of third-party connection components it pulls in is inevitably large. Being usable by anyone is its selling point, so the design opens raw SQL to ordinary users. Being instantly testable is its selling point, so a lightweight database ships in the box. The design choices made for ease of use are the same choices that widen the attack surface. Dark Reading's coverage makes the same point: because of how much Metabase is connected to, the blast radius of a single flaw jumps. Research showing that CVE-2023-38646 remains unpatched on thousands of deployments three years later suggests plenty of environments will repeat the pattern this time too.

How this unfolded

← Swipe to navigate

The attack began on August 2, Metabase noticed on the 3rd, and affected companies were told on the 6th. That means more than three days of moving around undetected. Fully accounting for what was taken during that blank period is hard, which is why each company's disclosure separates "records confirmed accessed" from "records whose access cannot be ruled out."

Affected versions and safe releases

Starting with CVE-2026-72898: every release from 1.58 onward is affected, and 1.57 and earlier are not. The free open-source edition's version numbers begin with "0" and the enterprise edition's with "1," but the numbers that follow are the same (for example, enterprise 1.60.17 corresponds to open-source 0.60.17). The table below writes branches as "x.60."

If you use Metabase Cloud, the update has already been applied on the provider's side. But this time that cloud platform was the one attacked, so "already patched" and "our data is fine" are two different questions. Check your admin mailbox for an individual notice from Metabase.

If you self-host on your own servers or in Docker, you have to move to the versions in the table yourself by swapping the JAR file or Docker image and restarting. As a stopgap when you cannot update right away, the vendor suggests blocking traffic to /api/session/reset_password at your load balancer or reverse proxy. You lose password resets, but you close the way in.

As for the three flaws disclosed in June and July, moving to the versions in the table closes them at the same time. On their own, CVE-2026-59827 and 59826 are fixed in x.58.15.1, x.59.12, x.60.6.3, and x.61.2 and later, while the Snowflake route CVE-2026-50148 is fixed in x.54.24, x.55.24, x.56.25, x.57.19, x.58.14, x.59.10, and x.60.4 and later. Even if you stay on x.57 or earlier, get at least to those numbers.

How to spot signs of intrusion

Updating and calling it done is what makes this one awkward. Because the attack was running before disclosure, you have to check for yourself whether you were already breached before you patched. The vendor asks operators to look for the following sequence in web server access logs.

If you find that sequence — or if you keep no logs and cannot tell — you should run through the vendor's post-incident steps in full: invalidate every session (delete the rows in the core_session table of the application database), review and revoke any API keys you do not recognize, audit administrator accounts for ones you did not create, rotate the passwords for every database connected to Metabase, and review the logs on those databases for suspicious queries.

Framework rotating credentials the day it was notified corresponds to the fourth item. If what the attacker took was connection credentials, fixing Metabase leaves the databases behind it wide open. Skip this step and you can end up patched but breached again weeks later by a different route.

What is confirmed and what is not

What to do right now

There are three stages. First, find out whether you have Metabase at all. Analytics platforms are often stood up by a team without going through IT, which makes "we surely don't use it" the most dangerous assumption in the building. An internal server running in Docker, an environment spun up for testing and forgotten, a reporting screen built by an outside development shop — all count. You can check the version from the gear icon at the top right of Metabase, in the admin settings.

Second, update to the versions in the table above. That is the only real fix. If you cannot get to it immediately, block the password reset endpoint or move Metabase itself somewhere invisible from the internet (inside your corporate network or behind a VPN). Wiz found that about a quarter of the self-hosted Metabase instances it saw in cloud environments were fully reachable from the internet. Closing that alone takes you out of the pool that indiscriminate scanning finds.

Third, inspect on the assumption that you were breached. Look for the log sequence above, and if you find it, move on to rotating everything. Skip this and update only, and the path to your connected databases stays open. The same ordering applies broadly to incidents where credentials are the prize, including the takeover flaw in a developer assistant tool we covered earlier.

Frequently asked questions

Summary

CVE-2026-72898 is the story of a screen set up to look at internal numbers turning out to be a shortcut to the company's customer list. One crafted string sent to a password reset endpoint that anyone can reach was enough to become an administrator, and before a patch existed, customer data was pulled from Framework, Tally, n8n, Kilo Code, and Checkly. The 10.0 severity is not just what the scoring math produced; it matches the breadth of the damage that actually occurred.

What to do is clear. Find out whether you have Metabase, move to whichever of x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, or x.63.5 applies, and check your logs for signs of intrusion. Those three. The three flaws from June and July close with the same update. While you are at it, take the opportunity to ask whether your analytics platform is guarded as strictly as your production database, and where in the company those "copies made only for viewing" are sitting. We will update this article as follow-up information emerges.

Sources

• ▸ Metabase Security Advisory - SQL injection using an unauthenticated endpoint leading to admin access (GHSA-vwf4-m7j8-wcjf / CVE-2026-72898)
• ▸ Metabase - Security update
• ▸ NVD - CVE-2026-72898
• ▸ CISA - Known Exploited Vulnerabilities Catalog
• ▸ Wiz - Inside the Metabase SQLi: Exploited in the Wild
• ▸ TechCrunch - Computer maker Framework notifies 'all customers' of a data breach
• ▸ n8n - Metabase security incident update
• ▸ Anaconda - Metabase Incident Impacting Kilo Code Data
• ▸ BleepingComputer - Metabase SQLi zero-day exploited in customer data-theft attacks
• ▸ SecurityWeek - Metabase Patches Vulnerability Exploited as Zero-Day
• ▸ Dark Reading - Metabase SQL Zero-Day Attacks Could Have Wide Blast Radius
• ▸ Metabase Security Advisory - Unsafe Deserialization of H2 Query Results (CVE-2026-59827)
• ▸ Metabase Security Advisory - Arbitrary Code Execution via Database Connection Detail Bypass (CVE-2026-59826)
• ▸ Metabase Security Advisory - Arbitrary File Write via Malicious Snowflake Connection (CVE-2026-50148)
• ▸ NVD - CVE-2023-38646 (the 2023 H2-related takeover flaw)