Analytics Tool 'Metabase' Server-Takeover Flaw CVE-2026-59827 Lets Ordinary Users Seize the Server — Update Now

The popular tool that turns company data into charts and tables, "Metabase," has a serious flaw that lets anyone with an ordinary employee login take over the entire server it runs on. Tracked as CVE-2026-59827, its severity is 9.9 out of 10 — the top tier. The vendor's security advisory went out on June 30, 2026, and it was assigned a common vulnerability number in early July.

At the same time, a second takeover hole exploitable by anyone with an administrator account (CVE-2026-59826, severity 9.1) was disclosed. Both stem from how Metabase handles "H2," a lightweight database it bundles, and they share one trait: the more you leave Metabase in its default state, the more exposed you are. The good news is that fixes already exist for both, and updating stops them. If you run Metabase in-house, move it to the latest version without putting it off.

What is Metabase in the first place?

Metabase is a "BI tool" that connects to the sales, membership, and other data sitting inside a company and lets you build charts and tables without programming. BI stands for business intelligence — essentially, tools that make data easy to visualize so it can inform business decisions. It is open-source software launched in 2015, and it is said to be used by roughly 50,000 companies worldwide. Its "install in five minutes, usable by everyone in the company" simplicity has made it widely adopted, from startups with engineers to departments inside large enterprises.

The key point here is that Metabase connects directly to a company's production databases to work. It is set up as a "gateway" that can reach core corporate data — sales systems, customer management systems, inventory data. That means if the Metabase server itself is taken over, an attacker gains reach into the connection credentials (usernames and passwords) of every connected database. It looks like just an analytics tool, but it is really a ring of keys placed at the heart of a company's data.

Platforms of a similar nature — those used to build internal business tools — have seen a run of takeover vulnerabilities before. One example is the flaw in the low-code platform Appsmith that let attackers hijack its communication endpoint, and the pattern is the same: a convenient internal tool becomes, in reverse, an entry point into the whole company's data.

What is the danger, and how large is the scope?

Both of this month's issues are the type where "an attacker can freely run programs on the server." In technical terms this is called remote code execution (RCE), and it sits among the most severe classes of vulnerability. Being able to run arbitrary commands on the server means that, in principle, anything is possible: stealing, altering, or deleting stored data, or using the machine as a stepping stone into other systems.

The one to watch most closely is the 9.9-rated CVE-2026-59827. All it requires is an ordinary user account that can run SQL — the query language — not an administrator account. And because Metabase ships by default with a practice-use lightweight database called "H2," the advisory explains that most Metabase instances left in this standard configuration are affected. A normal account handed out to an analyst can itself become the doorway to a server takeover.

The other issue, CVE-2026-59826 (9.1), has stricter conditions because exploiting it requires administrator privileges. Still, if an admin account is hijacked, or an insider turns malicious, it likewise allows arbitrary programs to run on the server. Put together, the two create an awkward situation for defenders: "whether from an ordinary account or an admin account, by different routes, the server can ultimately be seized."

Who targets this hole, and what happens?

The first to be targeted are companies and organizations running Metabase as their internal data platform. The likely attackers are ransomware groups that steal a company's internal data and demand a ransom, or crews that resell stolen customer information. Because Metabase sits at the intersection where a company's data converges, seizing it once gives efficient reach into large volumes of confidential information — making it a high-value target for them.

The attack flow goes like this. The attacker first obtains, by some means, an ordinary account that can log in to Metabase, then sends a crafted query that runs a program on the server. Credentials phished from an employee, a departed worker's un-deleted account, or a weak password on a Metabase instance exposed to the internet can all serve as the entry point. For the 9.9 flaw, there is no need to be an administrator — view-and-analyze privileges are enough.

As a result, what a company loses is not just one analytics tool. If the connection credentials for the production databases Metabase links to are stolen, the core corporate data itself — customer information, sales figures — can leak in a chain reaction. For the IT department that runs it, the scariest part is that the blast radius does not end at Metabase alone. Incidents where an internal business platform turns into an attacker's entry point keep recurring as cases where flaws in development and operations tools are exploited; this time, the stage was a company-wide data analytics platform.

A technical look at what is happening

Both issues are rooted in how Metabase handles the bundled lightweight database "H2," but they strike in different places. Each has its own identifier.

CVE-2026-59827: Blindly trusting a "plant" hidden in query results

In Metabase, users can write and run SQL — a query language for databases — directly. When you run this raw SQL against an H2 database, the results can include a column of a kind called "OTHER." The problem was that Metabase would reconstruct (deserialize) the contents of that column into a Java program object without validating it. Deserialization is the process of turning data that was stringified for storage or transmission back into the original in-program objects.

An attacker turns this mechanism against itself, slipping into the query results a component crafted so that malicious commands fire the moment it is restored. The instant Metabase reassembles it without suspicion, the attacker's commands run on the server. The U.S. National Institute of Standards and Technology (NIST) classifies this as "deserialization of untrusted data" (CWE-502). As noted above, the default H2 sample database serves as the route as-is, so many standard-configuration Metabase instances are affected. The 9.9 severity reflects exactly this point: the server can be seized without any special privileges.

CVE-2026-59826: Slipping past checks on dangerous connection settings

The second issue plays out on the "connection registration" screen where you add a new database to Metabase. An H2 database's connection string can include directives that automatically run SQL at initialization time. Because abusing such directives lets you run arbitrary programs on the server side, Metabase was supposed to inspect and reject dangerous connection settings. But there was a flaw that let this inspection be bypassed on one path, so when an administrator registers a crafted H2 connection, arbitrary Java code executes on the server.

NIST classifies this as "improper control of code generation" (CWE-94). Exploitation requires administrator privileges, so the severity is 9.1 — a notch below 59827 — but a Metabase admin account holds the entire analytics platform. If that account is hijacked, this hole leads straight through to a full server takeover. The vendor advisory recommends closing both at once.

H2 has been a recurring weak spot for Metabase

This is not the first time the bundled "H2" database has been a source of trouble for Metabase. In 2023, a critical takeover hole that could be exploited even before logging in (CVE-2023-38646, severity 9.8) was found, and the U.S. agency CISA ended up warning that it was "a vulnerability being used in real-world attacks." That episode prompted Metabase to stop supporting H2 as an official connection target for new installations.

Even so, in March 2026 another code-execution flaw abusing H2 connection strings in the enterprise edition (CVE-2026-33725) was disclosed, showing that the H2 problems have not been fully put to rest. This month's two issues sit on the same trajectory. H2 is easy to use, but by design it permits powerful operations on the server side, and that has become Metabase's repeating weak spot — the view held by experts.

The timeline so far

← Swipe to move

The vendor itself published the details as GitHub security advisories and released the fixes alongside them. Lined up with the two earlier episodes, the pattern of H2 problems recurring every few years comes into clear view.

Affected versions and the safe fixed versions

The two issues cover slightly different ranges. The 9.9 CVE-2026-59827 affects the 1.58 line and later, while the 9.1 CVE-2026-59826 affects the 1.55 line and later. The table below lists, per line, the version that closes both at once. Note that the free open-source edition's version numbers start with "0" and the enterprise edition's start with "1," but the numbers that follow are the same (for example, enterprise 1.58.15 corresponds to open-source 0.58.15).

If you use the cloud version (Metabase Cloud), the update is applied on the provider's side, so no action is generally required from you. If you run it on your own servers or via Docker — a "self-hosted" setup — you need to move to the latest version yourselves. In cases like this, where updating is the only fundamental fix, every day of delay extends the time you spend exposed.

What is confirmed and what is still unknown

What you can do right now

Because fixes exist, the direction is clear. The top priority is to update to the "Move up to" version in the table above (or later), matched to the line you run. On a self-hosted setup, that means swapping out the Docker image or JAR file and restarting. It helps to check before and after the update that your dashboards and connection settings are intact.

If circumstances keep you from updating immediately, mitigations that narrow the entry points include not exposing Metabase directly to the internet (keep it behind an internal network or VPN), cleaning up unnecessary and departed-employee accounts, and reviewing how broadly ordinary users are allowed to run raw SQL. These only buy time, though — fundamentally, a version upgrade is required.

Taking stock of whether your in-house business tools and development platforms have any internet-exposed admin screens or weak authentication left over is useful beyond Metabase. The same caution applies to other cases, such as the takeover vulnerability in a development-assistance tool.

Frequently asked questions

In summary

This case is about how a convenient tool for making company data easy to read can, the more it is left in its default state, become an entry point for a server takeover. The 9.9 CVE-2026-59827 is abused from an ordinary account, the 9.1 CVE-2026-59826 from an admin account, and both ultimately lead to seizing the Metabase server. Because Metabase sits in a position connected to a company's core data, the damage does not end at the tool itself.

The saving grace is that fixes already exist for both. Moving to the latest version for your line stops them. Given the history of recurring H2 problems, putting off the update is best avoided. We will report again if new signs of exploitation or further developments emerge.

References

• ▸ Metabase Security Advisory - Unsafe Deserialization of H2 Query Results (GHSA-w95f-x9v9-wv36 / CVE-2026-59827)
• ▸ Metabase Security Advisory - Arbitrary Code Execution via Database Connection Detail Bypass (GHSA-8wx2-rxp2-4x35 / CVE-2026-59826)
• ▸ NVD - CVE-2026-59827
• ▸ NVD - CVE-2026-59826
• ▸ NVD - CVE-2023-38646 (the 2023 H2-related RCE)
• ▸ Metabase Security Advisories (GitHub)
• ▸ Metabase official site