CVE-2023-37470 Overview
CVE-2023-37470 is a critical remote code execution vulnerability affecting Metabase, a popular open-source business intelligence and analytics platform. The vulnerability exists in Metabase's handling of H2 embedded in-memory database connections, where specially crafted connection strings can be used to inject and execute arbitrary code on the server running Metabase.
The core issue stems from the H2 database engine exposing functionality that allows code execution through connection string parameters. Since Metabase permits users to configure database connections—including validating connection strings before adding them—attackers can exploit the validation API endpoint to execute malicious code without proper authentication.
Critical Impact
This vulnerability allows unauthenticated attackers to achieve remote code execution on Metabase servers by exploiting the database connection validation API with malicious H2 connection strings.
Affected Products
- Metabase Open Source versions prior to 0.43.7.3, 0.44.7.3, 0.45.4.3, and 0.46.6.4
- Metabase Enterprise versions prior to 1.43.7.3, 1.44.7.3, 1.45.4.3, and 1.46.6.4
Discovery Timeline
- August 4, 2023 - CVE-2023-37470 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2023-37470
Vulnerability Analysis
This vulnerability is classified as CWE-94 (Improper Control of Generation of Code), also known as Code Injection. The flaw enables attackers to leverage the H2 database's connection string parsing behavior to execute arbitrary code in the context of the Metabase server process.
The H2 embedded database engine supports various JDBC URL parameters that can trigger code execution, including INIT scripts and TRACE_LEVEL_SYSTEM_OUT configurations. When Metabase processes a database connection request containing a malicious H2 connection string, the embedded database engine interprets and executes the injected code payloads.
The vulnerability is particularly severe because the primary attack vector—the connection validation API—can be invoked without prior authentication. This allows unauthenticated remote attackers to trigger code execution during the initial setup phase or through the validation endpoints.
Root Cause
The root cause of this vulnerability lies in Metabase's architecture allowing direct user input into H2 database connection strings without adequate sanitization or restriction of dangerous JDBC URL parameters. The H2 embedded database supports features like INIT scripts that execute SQL statements upon connection, which can include calls to Java methods and system commands.
Metabase's validation endpoints (POST /api/database, PUT /api/database/:id, and POST /api/setup/validate) process user-supplied connection strings and pass them directly to the H2 database engine, creating a direct path from untrusted input to code execution.
Attack Vector
The attack leverages Metabase's database connection validation functionality. An attacker can craft a malicious HTTP request to one of the vulnerable API endpoints containing a specially formatted H2 JDBC connection URL. The connection string includes parameters that instruct the H2 engine to execute arbitrary code during the connection initialization phase.
The vulnerability is particularly dangerous because:
- No authentication is required to access the validation endpoint during setup
- The H2 database engine runs with the same privileges as the Metabase process
- Successful exploitation results in complete server compromise
Technical details regarding specific exploitation techniques can be found in the GitHub Security Advisory GHSA-p7w3-9m58-rq83.
Detection Methods for CVE-2023-37470
Indicators of Compromise
- Suspicious HTTP POST requests to /api/database, /api/database/:id, or /api/setup/validate endpoints containing H2 connection strings
- Unexpected child processes spawned by the Metabase Java process
- Anomalous network connections originating from the Metabase server to external hosts
- Log entries indicating H2 database connection attempts with unusual INIT parameters or JDBC URL configurations
Detection Strategies
- Monitor web server access logs for requests to the vulnerable API endpoints containing jdbc:h2 connection strings
- Implement network-level inspection to detect H2 JDBC URLs in HTTP request bodies targeting Metabase endpoints
- Deploy endpoint detection and response (EDR) solutions to identify suspicious process creation from the Metabase application
- Review Metabase application logs for database connection validation attempts with H2 database types
Monitoring Recommendations
- Enable detailed logging on Metabase instances and forward logs to a centralized SIEM
- Configure alerts for any requests to database configuration endpoints from untrusted sources
- Implement application-level monitoring for H2 database connection attempts
- Monitor for unexpected system calls or process execution from the Metabase server
How to Mitigate CVE-2023-37470
Immediate Actions Required
- Update Metabase to patched versions: 0.43.7.3, 0.44.7.3, 0.45.4.3, 0.46.6.4 (Open Source) or 1.43.7.3, 1.44.7.3, 1.45.4.3, 1.46.6.4 (Enterprise)
- If using H2 as a file-based database, migrate to SQLite as recommended by the vendor
- Implement network-level controls to restrict access to the vulnerable API endpoints
- Review access logs for potential exploitation attempts prior to patching
Patch Information
Metabase has released security patches that completely remove the ability for users to add H2 databases to the platform. Organizations should upgrade to the latest patched versions immediately. Detailed patch information is available in the Metabase Security Advisory.
Workarounds
- Block access to vulnerable endpoints (POST /api/database, PUT /api/database/:id, POST /api/setup/validate) at the network or reverse proxy level
- Implement web application firewall (WAF) rules to filter requests containing H2 JDBC connection strings
- Restrict network access to Metabase instances to trusted IP ranges only
- Consider placing Metabase behind a VPN or zero-trust network architecture until patching is complete
# Example nginx configuration to block vulnerable endpoints
location ~ ^/api/(database|setup/validate) {
# Block POST and PUT requests to vulnerable endpoints
if ($request_method ~* "(POST|PUT)") {
return 403;
}
proxy_pass http://metabase_backend;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


