CVE-2026-103928 in Metabase
Summary
by MITRE • 10/13/2026
Metabase is an open source business intelligence and analytics platform. From 1.55.0 until 1.58.16, 1.59.13, 1.60.9, and 1.61.4, native queries and actions against an H2 data source are passed through without restricting host-facing built-in functions. A user authorized to run native queries or actions can invoke FILE_READ, FILE_WRITE, CSVREAD, CSVWRITE, or LINK_SCHEMA to read or write arbitrary files on the Metabase server or link other databases. The default sample database uses H2, so the vulnerable surface is exposed by default. This issue is fixed in versions 1.58.16, 1.59.13, 1.60.9, and 1.61.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/13/2026
Metabase serves as a prominent open-source business intelligence platform designed to facilitate data analytics through an intuitive interface that allows users to query databases using SQL or visual builders. The vulnerability identified in this context affects specific versions of the software ranging from release 1.55.0 up to version 1.61.4, encompassing minor updates such as 1.58.16, 1.59.13, and 1.60.9. The core issue resides in how the application handles native queries and actions when directed at an H2 database source. In these affected versions, Metabase fails to adequately restrict or sanitize host-facing built-in functions within the SQL engine used by H2. This lack of input validation allows authorized users who possess permissions to execute native queries or perform specific data actions to bypass intended security boundaries. The flaw is particularly critical because it enables direct interaction with the underlying operating system through database-level commands, effectively turning a standard analytics tool into a potential vector for server compromise.
The technical mechanism behind this vulnerability relies on several powerful built-in functions provided by the H2 database engine, specifically FILE_READ, FILE_WRITE, CSVREAD, CSVWRITE, and LINK_SCHEMA. When a user submits a native query containing these function calls, Metabase passes them directly to the H2 engine without sufficient filtering or sandboxing. For instance, invoking FILE_READ allows an attacker to read arbitrary files from the server's file system where Metabase is hosted. This capability can lead to the exfiltration of sensitive configuration files, database credentials stored in plaintext within config files, internal application secrets, or other critical data residing on the disk. Conversely, the use of FILE_WRITE and CSVWRITE enables an attacker to write arbitrary content to specific locations on the server's file system. If the Metabase process runs with elevated privileges or if writable directories are accessible for script execution, this can lead to remote code execution by overwriting configuration files or deploying malicious scripts that are subsequently executed by the application logic.
Furthermore, the LINK_SCHEMA function presents a distinct risk vector related to data exfiltration and lateral movement within an organization's infrastructure. This function allows the H2 database to link to other external databases accessible from the Metabase server. An attacker can leverage this capability to connect to internal corporate databases that may contain highly sensitive information such as customer records, financial data, or intellectual property. By linking these schemas, the attacker can query and extract data from systems outside of Metabase's direct scope, effectively using Metabase as a pivot point for broader network reconnaissance and data theft. The severity of this vulnerability is significantly amplified by the default configuration of many Metabase installations. Since the default sample database utilizes H2, new deployments are vulnerable out-of-the-box unless administrators explicitly change the database backend or apply security hardening measures immediately after installation. This means that organizations relying on default settings for testing or quick deployment are exposed to this risk without any additional effort required by an attacker beyond having valid user credentials with query permissions.
From a classification perspective, this vulnerability aligns closely with CWE-94, which describes Improper Control of Generation of Code (Code Injection), specifically in the context of SQL injection that leads to arbitrary command execution or file system access via database functions. It also maps to ATT&CK technique T1059, Command and Scripting Interpreter, as well as T1213, Data from Information Repositories, because it allows an attacker to extract data from internal systems through the compromised analytics platform. The operational impact is severe, potentially resulting in full server compromise, unauthorized access to sensitive corporate data, and violation of regulatory compliance standards such as GDPR or HIPAA due to the exposure of personally identifiable information or protected health information stored on the affected servers.
Mitigation strategies must be implemented immediately for any organization running vulnerable versions of Metabase. The primary remediation is to upgrade to a patched version where this issue has been resolved, specifically versions 1.58.16, 1.59.13, 1.60.9, or 1.61.4 and later. For environments that cannot immediately patch due to compatibility concerns, administrators should restrict native query permissions to only those users who absolutely require them for business operations. Additionally, organizations should consider migrating away from the default H2 database in production environments, opting instead for more robust enterprise-grade databases like PostgreSQL or MySQL which may have different security postures regarding such functions. Network-level controls can also help by ensuring that Metabase servers are isolated and do not have direct access to critical internal databases via LINK_SCHEMA unless strictly necessary. Regular auditing of user permissions and monitoring for unusual SQL query patterns containing file system operations can provide an additional layer of defense against exploitation attempts while patching efforts are underway.