Exploits

Metabase H2 Deserialization Flaw Allows Authenticated RCE

Published  ·  5 min read

Metabase has a problem. A user with an account and permission to run native queries can execute operating system commands on the server. That's not a typo.

The bug is CVE-2026-59827. A researcher going by Gutierre0x80 found it and published a working exploit.

And here's the part that should get your attention. The default sample database is enough. You don't need a custom H2 setup. If you're running Metabase with the standard sample data and you have users who can write native queries, you're exposed.

Quick Summary

What

Details

Vulnerability

Authenticated RCE via H2 deserialization

CVE

CVE-2026-59827

Affected

0.58.0 to 0.58.15, 0.59.0 to 0.59.12, 0.60.0 to 0.60.6.3, 0.61.0 to 0.61.1.4

Requirement

Valid credentials + native query permission

Impact

OS command execution on the Metabase server

Fix

Update to 0.58.15, 0.59.12, 0.60.6.3, or 0.61.1.4

What Is Metabase?

Metabase is a business intelligence tool. You point it at a database, it lets you run queries, build charts, and share dashboards. It's popular because it's simple. Non-technical people can use it without writing SQL.

It supports a bunch of database engines. One of them is H2, a lightweight Java database. H2 is handy for testing or embedded setups. Metabase ships with a default H2 sample database so you can play around with the tool right after install.

That sample database is part of what makes this bug so easy to exploit.

The Bug

Here's what happens.

When Metabase runs a native H2 query, it deserializes Java objects returned in columns of type OTHER. No validation. No checks. It just takes whatever comes back and deserializes it.

An attacker crafts a query that returns a malicious Java object. When Metabase deserializes it, the object executes code. That code runs on the Metabase server with the same privileges as the Metabase process.

The exploit uses a Java deserialization chain. It's a known technique. The researcher published a Python script that automates it.

What You Need:

  • A valid Metabase account
  • Permission to execute native queries
  • Access to an H2 database connection (the default sample database works)

That's it. Three things. And if you have them, you can run any command you want on the server.

How the Exploit Works

The researcher's proof-of-concept is on GitHub. Here's the basic flow:

  • Log in with valid credentials
  • Find the H2 database ID
  • Generate a malicious Java payload
  • Send it through a native query
  • The payload executes

The exploit script does all of this. You give it a URL, username, password, and command. It handles the rest.

The Query:

SELECT CAST(X'<payload_hex>' AS OTHER)

That casts the hex payload to the OTHER type. Metabase deserializes it. Game over.

After it runs, you might see errors like:

  • ClassCastException
  • ProcessImpl
  • NonTransientConnection
  • JdbcSQLData

Those indicate the deserialization happened and the command ran.

Who's Affected

These versions are vulnerable:

Version Range

Fixed In

0.58.0 to 0.58.15

0.58.15

0.59.0 to 0.59.12

0.59.12

0.60.0 to 0.60.6.3

0.60.6.3

0.61.0 to 0.61.1.4

0.61.1.4

Older versions are probably affected too. The bug has likely been there for a while.

Why This Matters

An authenticated user can run OS commands on your server. Think about what that means.

They can read files. Install malware. Pivot to other systems on your network. Steal data, credentials, or anything else sitting on the machine.

The attacker needs valid credentials and native query permissions. That's a barrier. Not everyone has those. But how many people in your org have Metabase accounts? How many can run native queries? Any one of them could exploit this.

And if someone compromises a single user account? They escalate to full server access.

What You Should Do

  • Update immediately. Go to one of these versions:
    • 0.58.15
    • 0.59.12
    • 0.60.6.3
    • 0.61.1.4
  • Restrict native query permissions. Not everyone needs to run native queries. Lock that down to the people who actually use it. Fewer people with access means fewer potential attackers.
  • Remove the sample database. If you're not using it, delete it. If you are, consider switching to a different engine.
  • Monitor for suspicious queries. Look for CAST with hex payloads. Watch for weird command execution on the server.
  • Audit your user accounts. Who has access? Should they? Remove accounts that shouldn't be there. Use strong passwords. Turn on two-factor if you can.

The Bottom Line

Metabase has an authenticated RCE bug in how it handles H2 databases. An attacker with credentials and native query permissions can run OS commands on the server. The default sample database is enough to pull it off.

Update to a fixed version. Restrict native query permissions. Watch for any suspicious behavior.

What You Should Know About It:

Key Point

Detail

Vulnerability

Authenticated RCE via H2 deserialization

CVE

CVE-2026-59827

Affected

0.58.0 to 0.61.1.4

Requirement

Valid credentials + native query permission

Impact

OS command execution

Fix

0.58.15, 0.59.12, 0.60.6.3, or 0.61.1.4

What You Should Do About It:

  • Update immediately.
  • Limit native query permissions
  • Delete the sample database.
  • Watch for any suspicious queries.
  • Audit user accounts.

FAQ Section

What is CVE-2026-59827?

An authenticated remote code execution bug in Metabase. It exploits H2 database deserialization to run OS commands on the server.

How does it work?

An authenticated user sends a native query that returns a malicious Java object. Metabase deserializes it without validation. The object executes code.

What are the versions that are vulnerable?

0.58.0 to 0.58.15, 0.59.0 to 0.59.12, 0.60.0 to 0.60.6.3, and 0.61.0 to 0.61.1.4.

Do I need admin access to exploit this?

No. Any authenticated user with native query permission can exploit it. The default sample database is enough.

Is there a patch?

Yes. Update to 0.58.15, 0.59.12, 0.60.6.3, or 0.61.1.4.

Source: Exploit DB
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067