CVE-2026-41042: Apache Gravitino unauthenticated H2 JDBC URL injection via testConnection API

Apache Gravitino (before 1.2.1) exposes an unauthenticated REST endpoint POST /api/metalakes/{metalake}/catalogs/testConnection that lets a caller supply an arbitrary JDBC URL for a catalog connection test. Because no validation rejected H2 JDBC URLs or the H2 driver class, an attacker could supply a malicious jdbc:h2:...;INIT=... URL. H2's INIT connection parameter runs arbitrary SQL when the database is first opened, and H2's CREATE ALIAS ... AS '<java source>' compiles and executes arbitrary Java code inside the Gravitino server JVM. By combining CREATE ALIAS with Runtime/ProcessBuilder calls, an unauthenticated remote caller achieves arbitrary operating-system command execution on the server.

• Package/component affected: org.apache.gravitino:gravitino-catalog-jdbc-common (DataSourceUtils.createDataSource), reached through the testConnection REST endpoint and the JDBC catalog operations (JdbcCatalogOperations.initialize).
• Affected versions: Apache Gravitino before 1.2.1 (confirmed on the official 1.2.0 binary distribution; H2 1.4.200 is bundled).
• Risk level / consequences: Remote code execution. The default server configuration uses the SimpleAuthenticator (accepts anonymous requests) and has gravitino.authorization.enable = false, so the endpoint is reachable without any credentials. The H2 driver is always on the server classpath (it is the default entity-store backend) and is treated as a "shared" class by the catalog IsolatedClassLoader, so attacker-supplied H2 URLs resolve to the bundled driver even for non-H2 catalog providers.

Impact Parity

• Disclosed/claimed maximum impact: Remote code execution — "executes arbitrary Java code on the server via H2's INIT parameter", expected impact code_execution.
• Reproduced impact from this run: Arbitrary OS command execution confirmed end-to-end through the unauthenticated REST API. The malicious testConnection call returned HTTP 200 / {"code":0} and a marker file containing the output of the id command (uid=1000(vscode) gid=1000(vscode) groups=1000(vscode)) was written by a ProcessBuilder started from H2-compiled Java code running in the server JVM.
• Parity: full.
• Not demonstrated: N/A — the full code-execution chain was demonstrated.

Root Cause

DataSourceUtils.createDataSource(JdbcConfig) is the single entry point for all user-facing catalog JDBC connections. In the vulnerable version it performed no allow-listing of JDBC drivers/URLs: it passed the caller- controlled jdbc-url and jdbc-driver straight into a DBCP BasicDataSource. The shared validator JdbcUrlUtils.validateJdbcConfig only inspects MySQL/MariaDB/PostgreSQL URLs for unsafe parameters and intentionally does not touch H2 (H2 is the legitimate embedded entity-store backend). Consequently an H2 URL reached the driver untouched.

The call chain triggered by testConnection is:

CatalogOperations.testConnection (REST, @Path "testConnection")
  -> CatalogManager.testConnection
    -> CatalogWrapper.doWithCatalogOps
      -> BaseCatalog.ops()  (lazy initialize)
        -> JdbcCatalogOperations.initialize(conf, ...)
          -> DataSourceUtils.createDataSource(jdbcConfig)   <-- vulnerable
            -> BasicDataSource (url=jdbc:h2:mem:...;INIT=..., driver=org.h2.Driver)

When the pool opens its first connection (during JdbcCatalogOperations.testConnection -> databaseOperation.listDatabases()), H2 processes the INIT parameter. The payload INIT=CREATE ALIAS EXEC AS 'String f() throws Exception { new ProcessBuilder(...).start().waitFor(); ... }'\;CALL EXEC() compiles the Java source via the JDK compiler and invokes it, executing the attacker's OS command inside the server process.

Fix commit: 5daabcd0e8ddc96e25bd6c6ce7b153cdb311c3f2 ("[MINOR] fix(catalog): block H2 JDBC URL and driver in catalog datasource creation (#10801)"), cherry-picked to the 1.2 release branch as 84d3de9c7 and shipped in Gravitino 1.2.1. The fix adds a case-insensitive block in DataSourceUtils.createDataSource() that rejects any URL whose decoded form starts with jdbc:h2 and any driver class starting with org.h2., throwing GravitinoRuntimeException before the datasource is created.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, idempotent, run twice consecutively — both runs pass with exit 0).
2. What it does:
   • Installs OpenJDK 17 if needed.
   • Downloads/reuses the official Apache Gravitino binary distributions gravitino-1.2.0-bin.tar.gz (vulnerable) and gravitino-1.2.1-bin.tar.gz (fixed) from the GitHub release CDN (fallback: Apache archive).
   • For each version: extracts a clean copy, disables auxiliary services, starts the real gravitino.sh server, waits for the /api/version healthcheck, creates a metalake, and sends an unauthenticated POST /api/metalakes/test_ml/catalogs/testConnection with provider=jdbc-postgresql, jdbc-driver=org.h2.Driver, and a malicious jdbc-url whose INIT runs CREATE ALIAS + ProcessBuilder to execute id and write its output to a marker file. Two attempts are made per version (each attempt uses a fresh H2 in-memory DB name because H2 only runs INIT when a database is first created).
   • Captures per-attempt request/response logs, server logs, version JSON, and the RCE marker file under bundle/logs/.
   • Writes bundle/repro/runtime_manifest.json.
3. Expected evidence:
   • Vulnerable 1.2.0: testConnection returns HTTP 200 {"code":0} and the marker file is created containing id output → RCE.
   • Fixed 1.2.1: testConnection returns HTTP 500 "H2 JDBC URL is not allowed in catalog configuration" (thrown at DataSourceUtils.createDataSource:54) and no marker file is created.

Evidence

• bundle/logs/reproduction_steps.log — orchestrator log with verdict.
• bundle/logs/vuln_version.json — 1.2.0, gitCommit 1c1665f0....
• bundle/logs/fixed_version.json — 1.2.1, gitCommit e88bffcfc....
• bundle/logs/vuln_attempt_1.log / vuln_attempt_2.log — testConnection_status: 200, testConnection_body: {"code":0}, marker_exists: True, marker_content: uid=1000(vscode) ....
• bundle/logs/rce_marker_vuln_latest.txt — the file written by the attacker's OS command inside the server JVM.
• bundle/logs/fixed_attempt_1.log / fixed_attempt_2.log — testConnection_status: 500, message "H2 JDBC URL is not allowed in catalog configuration", stack at DataSourceUtils.createDataSource(DataSourceUtils.java:54), marker_exists: False.
• bundle/logs/vuln_server.log / fixed_server.log — server-side logs.
• bundle/repro/runtime_manifest.json — runtime evidence manifest.

Key excerpts:

# Vulnerable 1.2.0 (unauthenticated)
vuln_a1 testConnection_status: 200
vuln_a1 testConnection_body: {"code":0}
vuln_a1 marker_exists: True
vuln_a1 marker_content: uid=1000(vscode) gid=1000(vscode) groups=1000(vscode)

# Fixed 1.2.1 (unauthenticated)
fixed_a1 testConnection_status: 500
fixed_a1 testConnection_body: {"code":1002,"type":"RuntimeException",
  "message":"H2 JDBC URL is not allowed in catalog configuration",
  "stack":["...DataSourceUtils.createDataSource(DataSourceUtils.java:54)",
           "...JdbcCatalogOperations.initialize(JdbcCatalogOperations.java:175)",...]}
fixed_a1 marker_exists: False

Environment: OpenJDK 17.0.19, official Apache Gravitino binary tarballs, H2 1.4.200 (bundled), Jetty 9, commons-dbcp2 2.11.0, default server config (SimpleAuthenticator, authorization disabled, H2 entity-store backend).

Recommendations / Next Steps

• Upgrade to Apache Gravitino 1.2.1 or later, which blocks H2 JDBC URLs and the org.h2. driver class in DataSourceUtils.createDataSource().
• Consider a positive allow-list of permitted JDBC URL schemes/drivers in catalog configuration rather than only blocking H2, and apply the same check at catalog creation time (not only testConnection).
• In production deployments, enable authentication/authorization and use MySQL (not H2) for the entity store; restrict network exposure of the testConnection endpoint.
• Add regression tests that assert a jdbc:h2:...;INIT=... URL and org.h2.Driver are rejected through the full REST testConnection path.

Additional Notes

• Idempotency: confirmed — the script was run twice consecutively; both runs exited 0 with identical verdicts (vulnerable RCE confirmed on both attempts, fixed blocked on both attempts). Each run extracts into fresh directories and uses a unique H2 in-memory DB name per attempt.
• Payload detail: every ; inside the H2 INIT value (including Java statement terminators) must be escaped as \;, because H2 uses ; as the URL parameter separator; unescaped ; truncates the URL and the INIT never runs. The jdbc-database property must also be supplied for the jdbc-postgresql provider (PostgreSqlSchemaOperations.initialize reads it before the test connection is opened).
• The exploit does not require the catalog provider to be H2-aware: the H2 driver is a "shared" class (!isCatalogClass) so the catalog IsolatedClassLoader delegates org.h2.Driver to the server classloader, which always has it.