Unauthenticated SQL injection through publicly shared Metabase dashboards

Metabase allows an unauthenticated attacker to inject arbitrary SQL via a publicly shared card or dashboard that exposes a field-filter (dimension) parameter.

Metabase is affected on the following branches:

• >= x.58.0 and < x.58.24; the identified patched release is x.58.24.
• >= x.59.0 and < x.59.21; the identified patched release is x.59.21.
• >= x.60.0 and < x.60.17; the identified patched release is x.60.17.
• >= x.61.0 and < x.61.11; the identified patched release is x.61.11.
• >= x.62.0 and < x.62.9; the identified patched release is x.62.9.
• >= x.63.0 and < x.63.5; the identified patched release is x.63.5.

Other branches or default status are not established by the record. A patch for one branch must not be treated as evidence that parallel or other release branches are unaffected.

Metabase does not safely handle input associated with a field-filter (dimension) parameter on a publicly shared card or dashboard, allowing arbitrary SQL to be injected into the application database. The attacker does not need authentication and only needs access to the public link UUID for the shared content; public sharing is enabled by default, so publishing a link is the only required setup identified by the advisory. At a high level, the attack involves sending a network request to a public card or dashboard with an attacker-controlled field-filter value, causing Metabase to execute SQL in the application database context. The advisory does not describe the exact query-construction or input-neutralization detail, so no specific function, endpoint, or payload should be inferred. The affected scope is limited to the Metabase branches listed in affected_summary when they contain public content exposing a field-filter parameter.

The flaw is remotely reachable over the network, requires no authentication, does not require user interaction, and is assessed as low complexity. The practical precondition is a Metabase instance with a publicly shared card or dashboard that exposes a field-filter (dimension) parameter; the advisory states that public sharing is enabled by default. The supplied SSVC assessment records exploitation as none while marking the issue as automatable with total technical impact; the record also marks public_exploit as false. These statuses do not prove that every instance has avoided unauthorized access, so organizations that exposed matching public content should perform the post-compromise checks in remediation.

An attacker can execute arbitrary SQL through the Metabase application database without an account or user interaction. Technical consequences may include changing application configuration, retrieving stored credentials for connected databases, reading or exporting data accessible through those connections, and affecting the integrity or availability of linked data systems. The vendor advisory describes a path leading to admin access, and CISA states that administrative privileges are possible in the worst case. The record does not establish server-side code execution, name a specific victim, or show that every affected instance has been compromised.

The flaw exposes Metabase data and configuration to an actor who does not have an account. If exploited, the attacker could read data permitted by connected database connections, export data, obtain stored credentials for those databases, and change application configuration. CISA also identifies administrative access as a worst-case outcome. Organizations with matching public cards or dashboards may therefore face simultaneous risks to data confidentiality, configuration integrity, stored credentials, and connected data systems.

1. Upgrade Metabase to the patched release corresponding to the deployed branch: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, or x.63.5. Verify the branch before deployment because the advisory identifies patches separately for each branch.
2. If immediate upgrading is not possible, temporarily disable public sharing or unpublish public links that expose field-filter parameters. This is only a temporary mitigation.
3. If the instance had matching public dashboards or cards, revoke all active user sessions after upgrading by accessing the application database and running TRUNCATE TABLE core_session.
4. Review API keys and delete unrecognized keys; inspect administrator accounts for unexpected changes.
5. Rotate credentials for all databases connected to Metabase if matching public content existed.
6. Review data warehouse logs, Metabase activity, and query history for unauthorized access or unexpected query activity. Failure to find evidence does not rule out exploitation.

1. Inventory every Metabase instance and compare its version with the affected branches and patched releases in affected_summary.
2. Identify cards and dashboards that are publicly shared, especially content with field-filter (dimension) parameters and the related public link UUIDs.
3. Review API keys for unrecognized entries and inspect administrator accounts for unexpected changes.
4. After upgrading, review data warehouse logs together with Metabase activity and query history for unauthorized access or unexpected query activity.
5. If matching public cards or dashboards existed, perform the session, API-key, administrator-account, and connected-database-credential checks described in remediation as an investigative precaution. The advisory does not define a unique IOC; absence of evidence in logs does not prove that an instance is safe.