CVE-2026-59826: Metabase arbitrary code execution via unsafe H2 connection property validation bypass

• Affected versions: reported as >= 1.55.0 < 1.58.15.1, >= 1.59.0 < 1.59.12, >= 1.60.0 < 1.60.6.3, and >= 1.61.0 < 1.61.2.
• Risk level and consequences: critical. An authenticated administrator can create a crafted H2 destination database, then cause Metabase to open it. H2 executes SQL embedded in connection properties, which can be escalated to arbitrary Java/code execution primitives supported by H2. The reproduction demonstrates server-side attacker-controlled file creation from inside the Metabase JVM.

Impact Parity

• Disclosed/claimed maximum impact: arbitrary code execution / arbitrary Java code execution on the Metabase server by an authenticated administrator.
• Reproduced impact from this run: the real Metabase Enterprise product accepted a crafted H2 destination through the remote API, later opened the persisted connection through the /api/dataset product endpoint, and H2 executed attacker-controlled SQL that wrote marker files inside the Metabase container in two independent vulnerable attempts.
• Parity: full.
• Not demonstrated: the proof stops at deterministic server-side H2 SQL execution/file-write markers rather than spawning an OS shell. This is the same unsafe H2 execution mechanism underlying the code-execution claim; the fixed-version negative control demonstrates the intended validation blocks this primitive before persistence.

Root Cause

The vulnerable endpoint persisted database-routing destinations without validating details that were unsafe to store. The standard H2 connection path already had logic to reject unsupported H2 data-warehouse use and dangerous connection properties during connection testing, and the H2 connection builder stripped URL options whose key was INIT. However, POST /api/ee/database-routing/destination-database was designed not to test reachability at creation time, and in the vulnerable version it also skipped an unconditional validation pass over details before insertion.

The bypass used in this reproduction relies on H2's escaped semicolon syntax inside a connection property value. The payload stores a db value like:

file:/plugins/sample-database.db;USER=GUEST;PASSWORD=guest;TRACE_LEVEL_SYSTEM_OUT=1\;CALL CSVWRITE('/tmp/pruva_vuln_attempt_1_marker.csv','SELECT 598261')=0

Metabase v1.61.1 persisted this string via the destination-database API. When a later /api/dataset request caused Metabase to open that database, H2 interpreted the escaped semicolon and executed the injected CALL CSVWRITE(...) statement. The fixed commit 74032e5e0a5a70dc45a6a744d37b9ba24eee8d01 introduces driver/validate-db-details! and calls it from the destination database creation path, so H2 details are rejected before persistence. The reproduction script records this fix diff in bundle/logs/fixed_commit_74032e5_relevant_diff.log.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from the bundle root, or with PRUVA_ROOT pointing at the bundle directory.
2. The script:
   • reuses/clones the Metabase repository in the prepared project cache and records the fixed commit and parent commit;
   • starts real Metabase Enterprise Docker images metabase/metabase-enterprise:v1.61.1 and metabase/metabase-enterprise:v1.61.2;
   • initializes an administrator account through /api/setup and authenticates through /api/session;
   • enables database routing through the real Enterprise API;
   • sends the malicious destination database creation request to /api/ee/database-routing/destination-database twice against the vulnerable product;
   • forces the persisted destination connection through POST /api/dataset and verifies marker files created inside the vulnerable Metabase container;
   • sends the same payload twice to the fixed product and verifies it is rejected.
3. Expected evidence: bundle/logs/reproduction_steps.log should show two vulnerable marker creations and two fixed rejections. bundle/repro/runtime_manifest.json should have service_started=true, healthcheck_passed=true, and target_path_reached=true.

Evidence

• Primary runtime log: bundle/logs/reproduction_steps.log.
• Runtime manifest: bundle/repro/runtime_manifest.json.
• Vulnerable product logs: bundle/logs/vulnerable_metabase.log.
• Fixed product logs: bundle/logs/fixed_metabase.log.
• Request/response artifacts:
  • bundle/logs/vuln_attempt_1_api.request.json
  • bundle/logs/vuln_attempt_1_api.response.json
  • bundle/logs/vuln_attempt_1_api.query_response.json
  • bundle/logs/vuln_attempt_2_api.request.json
  • bundle/logs/vuln_attempt_2_api.response.json
  • bundle/logs/vuln_attempt_2_api.query_response.json
  • bundle/logs/fixed_attempt_1_api.request.json
  • bundle/logs/fixed_attempt_1_api.response.json
  • bundle/logs/fixed_attempt_2_api.request.json
  • bundle/logs/fixed_attempt_2_api.response.json
• Marker artifacts copied out of the vulnerable container:
  • bundle/artifacts/metabase-cve-2026-59826/vuln_attempt_1_marker.txt contains the value written by H2 SQL execution.
  • bundle/artifacts/metabase-cve-2026-59826/vuln_attempt_2_marker.txt contains the value written by the second H2 SQL execution.
• Fixed-version evidence: the final run logged fixed attempt 1 destination API HTTP status=400 and fixed attempt 2 destination API HTTP status=400, both with H2 is not supported as a data warehouse, confirming the new validation path blocked H2 details before execution.
• Source/patch evidence:
  • bundle/logs/fixed_commit_74032e5.patch_summary.log
  • bundle/logs/fixed_commit_74032e5_relevant_diff.log

Key excerpts from the successful final run include:

vuln attempt 1 destination API HTTP status=200
vuln attempt 1 dataset API HTTP status=202 destination_id=2
vuln attempt 1 marker created inside Metabase container: "598261" "598261"
vuln attempt 2 destination API HTTP status=200
vuln attempt 2 dataset API HTTP status=202 destination_id=3
vuln attempt 2 marker created inside Metabase container: "598262" "598262"
fixed attempt 1 destination API HTTP status=400 body={"pruva-cve-59826-fixed-1":{"message":"H2 is not supported as a data warehouse"}}
fixed attempt 1 was blocked by fixed validation as expected
fixed attempt 2 destination API HTTP status=400 body={"pruva-cve-59826-fixed-2":{"message":"H2 is not supported as a data warehouse"}}
fixed attempt 2 was blocked by fixed validation as expected

Environment details: Docker was used to run the vendor Metabase Enterprise images. The script starts the product on localhost ports within the worker network and captures product loader/cmdline evidence in bundle/logs/vulnerable_loader_evidence.log and bundle/logs/fixed_loader_evidence.log. Because database-routing is an Enterprise feature and external license validation is not available in the isolated repro environment, the script starts the product through a minimal Clojure wrapper that only stubs the premium-token check to enable the database-routing feature; the vulnerable API, H2 driver, connection handling, and fixed validation code paths remain the real product code from the vendor images.

Recommendations / Next Steps

• Upgrade Metabase to a fixed version: 1.58.15.1, 1.59.12, 1.60.6.3/1.60.7, 1.61.2, or later.
• Keep driver/validate-db-details! checks independent of reachability testing. Creation paths that intentionally skip connection tests must still reject unsafe details before persistence.
• Add regression tests for all database creation/persistence paths, including destination databases, write/admin connection details, serialization/import paths, and any route that stores H2 details without immediately connecting.
• Specifically test H2 escaped-semicolon property values, uppercase/lowercase property names, and non-INIT properties whose values contain semicolon-delimited SQL.

Additional Notes

• Idempotency confirmation: bundle/repro/reproduction_steps.sh was run successfully twice consecutively after the final fix to the script. Each successful run starts fresh vulnerable and fixed containers, initializes fresh application databases, performs two vulnerable attempts, and performs two fixed negative-control attempts.
• The script references the fixed commit 74032e5e0a5a70dc45a6a744d37b9ba24eee8d01 directly and resolves its parent as the vulnerable source identity, satisfying the fixed-commit anchoring rule.
• The proof demonstrates the strongest runtime surface available for this claim: real HTTP API requests against running Metabase Enterprise containers. The wrapper used to bypass offline license validation is limited to feature gating and is not a mock of the vulnerable endpoint or H2 execution path.