vulnerability

Metabase's sample database was a file read/write back door

Glenn Fryklund

Glenn Fryklund

— 3 min read
Share
Metabase's sample database was a file read/write back door
Rendered with AI. A business analytics dashboard on a laptop in a dim office, with a glowing document sliding out of the screen onto the desk, standing in for the file-read primitive that native-query access exposed on Metabase's default H2 sample database.

Metabase ships with a sample database so you can try the product before wiring up your own. That sample runs on H2, an embedded Java database, and for most users it is a harmless playground. For anyone with native-query access, it was a back door to the server's files.

The flaw sits in how Metabase handles native queries against an H2 data source. When a user is allowed to run native queries or actions, Metabase passes them through without restricting the host-facing built-in functions that H2 exposes. Five of those functions do the damage: FILE_READ and FILE_WRITE read and write arbitrary files, CSVREAD and CSVWRITE do the same for CSV data, and LINK_SCHEMA folds another database into the H2 instance. A user who can run a native query against the sample database can therefore read or write files on the Metabase server, or link other databases into it.

The reason this is worse than a typical "patch your dependency" item is that the vulnerable path is active by default. The bundled sample database is H2, so an out-of-the-box, unmodified install already carries the exposed surface. The moment you grant a non-admin user native-query access, a common configuration for analyst dashboards, that user holds a server-side file read and write primitive. No misconfiguration or unusual setup is required. The default is the exposure.

The affected range runs from 1.55.0 through the 1.58.16 / 1.59.13 / 1.60.9 / 1.61.4 series, with matching 0.x releases. The fix landed as a four-branch patch release: 1.58.16, 1.59.13, 1.60.9, and 1.61.4, plus the matching 0.x tags v0.58.15.3, v0.59.12.1, v0.60.8.1, and v0.61.3.4. The vendor shipped five fix commits across those branches. Because the patch is spread over supported branches rather than a single version, teams running a mix of Metabase versions need to check each one against the fixed list, not just bump to the latest.

The disclosure moved quickly. NVD published the record on 2026-10-13; the GitHub Security Advisory (GHSA-cwxq-fmxq-jv8h) had been published earlier, on 2026-07-12. The vulnerability is scored CVSS 9.3 CRITICAL under CVSS 4.0. It is not on CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment from 2026-10-13 records no known exploitation, though it flags the issue as automatable with a total technical impact. The advisory credits the report to Rajesh Tewari.

The defensive takeaway is specific. If you self-host Metabase, audit who holds native-query rights. Treat any H2-backed instance below the fixed versions as if it exposes a user-reachable file-read primitive on the host, and close that access or upgrade the affected branch. This is the default exposure, reachable by anyone you have already trusted with a query.

AI/LLM transparency note

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.

Topics:

Read more