[acmeguy]

Why (urgent)

A fourth adversarial review of the confinement merged in #103 found two critical holes that are exploitable with default config. #103 is deploying to dev now.

Finding	Impact	Fix
MotherDuck md: options (motherduck_host, ports, download URLs)	The pod requests any internal or metadata URL at DuckDB instance creation, before the sandbox, and the response body comes back in the error (reproduced)	Only a database name and a token-shaped motherduck_token are accepted. The token is validated too, since Cube pastes it into the URL
Databricks JDBC options (VolumeOperationAllowedLocalPaths, StagingAllowedLocalPaths, SSL key stores, proxies)	The in-JVM driver uploads or downloads pod files, e.g. /proc/self/environ, to the tenant's own workspace	Allowlist of connection options in the URL and the properties, for every JDBC type that can load the driver
DuckDB unbounded memory, threads and spill (medium)	One tenant query can OOM-kill the shared cube process or fill its disk	Defaults of 1 GB memory, 2 threads and 4 GB spill, raisable through CUBEJS_DB_DUCKDB_MEMORY_LIMIT, _THREADS and _MAX_TEMP_DIRECTORY_SIZE

Verification

• Image yarn test: 760/760, including new tests for every vector.
• The reviewers' MotherDuck exploit was run against both images:
  • merged image: the internal server receives GET /leak?/extension_version= and its body is returned;
  • this image: refused with "MotherDuck connection options other than the token are not allowed".

🤖 Generated with Claude Code