CVE-2026-72899

Executive Summary

CVE-2026-72899 is a critical, unauthenticated SQL injection vulnerability in Metabase, a popular open-source business intelligence and analytics platform. The flaw resides in the handling of publicly shared cards or dashboards that expose field-filter (dimension) parameters, allowing a remote, unauthenticated attacker to inject arbitrary SQL into the underlying database query. With a CVSS score of 10.0 (Critical), successful exploitation can lead to complete compromise of the Metabase application host and potentially lateral movement into connected data sources. No patch is currently available from the vendor, and no public exploit code has been identified, although the vulnerability class is well-understood and trivially exploitable by skilled attackers.

Technical Analysis

The vulnerability is a classic SQL injection (CWE-89) flaw triggered through Metabase's interactive analytics features. Metabase allows users to create "cards" (individual saved questions/queries) and "dashboards" (collections of cards) that can be shared publicly via unauthenticated URLs. When a shared card or dashboard includes a field-filter widget — a UI element that lets viewers dynamically filter results by selecting values for a particular column (e.g., a date range or a category) — the filter value is passed as a query parameter to the backend.

The flaw lies in how Metabase processes these dimension parameters. When a public (unauthenticated) endpoint receives a field-filter request, the application fails to properly sanitize or parameterize the injected value before embedding it into the generated SQL query. An attacker can manipulate the field-filter parameter to break out of the intended string literal or numeric context and inject arbitrary SQL syntax. Because the query is executed with the privileges of the Metabase application's database connection (often a highly privileged account with access to multiple schemas or databases), the injection is not limited to a single table.

The attack surface is significant: any publicly shared Metabase card or dashboard that uses a field-filter is immediately exposed. Furthermore, because the flaw does not require authentication, any organization that has ever published a Metabase artifact with a filter is vulnerable, regardless of network segmentation. The vulnerability is classified as "unauthenticated" (PR:N) and requires no user interaction (UI:N), meaning a single crafted HTTP request can trigger the attack. The CVSS vector also notes a scope change (S:C), indicating that the injected SQL can affect resources beyond the vulnerable component's security scope — in practice, this means the underlying database and potentially other connected systems.

From a code-level perspective, the root cause is likely improper use of string concatenation or an insufficiently hardened query-builder abstraction in the field-filter transformation logic. The lack of parameterized queries (prepared statements) for dynamically added filter clauses allows an attacker to terminate the SQL statement early and append malicious clauses (e.g., UNION SELECT, OR 1=1, stacked queries if the DBMS supports them). Without patch details or vendor disclosure of the exact function names, the attack mechanism must be described at the class level; however, the behavior is consistent with a classic in-band SQL injection where the HTTP response reflects the results of the injected query.

Exploitation Scenarios

Attacker Profile: Unauthenticated remote attacker with no prior knowledge of the target beyond the existence of a publicly shared Metabase card or dashboard.

Attack Chain:

1. Reconnaissance / Target Identification: The attacker identifies Metabase instances by scanning the internet for the Metabase web UI (e.g., default port 3000, or via Shodan dorks such as title:"Metabase"). Publicly shared cards/dashboards are discoverable via search engines or by probing known Metabase URL patterns (e.g., /public/dashboard/, /public/question/). The attacker locates a shared artifact that contains a field-filter parameter (a common pattern is a date picker or a dropdown for a category).

2. Triggering the Flaw: The attacker loads the public card/dashboard and observes the HTTP request generated when interacting with the filter. The field-filter value is transmitted as a query parameter (e.g., ?filter=value). The attacker replaces the legitimate filter value with a crafted SQL injection payload. Because the application is unauthenticated, no session or authorization check is passed — the request goes directly to the vulnerable query-processing logic.

3. Payload / Execution Method (vulnerability class): The attacker injects SQL payloads designed to (a) break out of the intended SQL context (e.g., closing a single quote and appending OR 1=1 to bypass filtering logic), and (b) execute arbitrary SQL statements. A standard technique for data exfiltration is a UNION SELECT attack to concatenate the results of additional queries (e.g., dumping database credentials or system tables) into the legitimate result set displayed in the card. In more advanced scenarios, if the underlying DBMS (PostgreSQL, MySQL, etc.) supports stacked queries, the attacker can use them to write files, create database backdoor accounts, or call database-specific functions to reconnoiter the host operating system. The response from the server contains the results of the injected query, confirming a successful in-band injection. No public PoC is available; attack chain is inferred from the vulnerability class.

4. Post-Exploitation Impact: With SELECT-level injection, the attacker can dump the entire contents of any database the Metabase service account can access, including user tables, application secrets, and third-party data. If the injected statements allow data modification (e.g., UPDATE, DELETE, or INSERT), data integrity is compromised. Furthermore, if the database user has FILE or EXECUTE privileges, the attacker may read application source code (including API keys for connected data source like AWS, Snowflake, or Google BigQuery), write webshells to the Metabase host, or leverage database-extended features (e.g., xp_cmdshell in MSSQL, COPY ... TO PROGRAM in PostgreSQL) to achieve remote code execution on the host OS. Given the critical CVSS score, the expected outcome is total compromise of the Metabase server and lateral movement into connected data infrastructure.

Impact Assessment

Business Impact: Full confidentiality, integrity, and availability loss. The CVSS subscores (C:H/I:H/A:H) indicate that an attacker can read all sensitive data accessible to the Metabase service account, modify or delete data in connected data sources, and potentially disrupt the availability of the Metabase application itself. In regulated environments, this constitutes a reportable data breach. Because Metabase is often used to analyze production databases, the blast radius includes all linked data warehouses, product databases, and analytics pipelines.

Affected Systems: Any organization running self-hosted Metabase (open-source or enterprise edition) that has enabled public sharing of cards or dashboards with field filters. The META cloud-hosted offering is also presumed vulnerable until vendor advisories state otherwise. The exact affected version range is unknown, and the NVD data does not specify version constraints; this suggests that the vulnerability may be present across multiple versions or that disclosure is incomplete.

Blast Radius: The vulnerability has a network-based attack vector (AV:N), with a change in security scope (S:C). The database credentials stored in the Metabase environment are typically provisioned with broad read-only or read-write access to multiple schemas, amplifying the initial injection into a data exfiltration event affecting core business data. If Metabase is deployed in a Kubernetes environment or has network access to internal services, the attacker may pivot to other internal applications.

Detection Guidance

The following detection rules target the indicators of SQL injection in HTTP requests directed at Metabase's public endpoints. Focus on the presence of common SQL metacharacters and keywords in query parameters, especially in URIs containing /public/ and filter-related parameters. Note that URL encoding (e.g., %27, %20) will require decoding in detection logic or normalization by the detection engine.

Sigma Rule

title: Suspicious SQL Injection Attempt on Metabase Public Endpoint
id: 4f4f3c8e-9a5c-4d2a-b3e8-6b1f7a0e3d2c
status: experimental
description: Detects SQL injection patterns in HTTP requests to Metabase public card/dashboard endpoints
author: Valtersit Threat Intel
date: 2026-01-01
logsource:
  category: webserver
  product: generic
detection:
  selection:
    http.url|contains:
      - '/public/'
      - '/public/question/'
      - '/public/dashboard/'
    http.url|contains|all:
      - 'filter'
  sqli_patterns:
    http.url|contains|any:
      - 'UNION%20SELECT'
      - 'UNION+SELECT'
      - "' OR '1'='1"
      - "' OR 1=1--"
      - '%27%20OR%201%3D1'
      - 'SLEEP('
      - 'pg_sleep('
      - 'WAITFOR%20DELAY'
      - 'INTO%20OUTFILE'
      - 'INTO%20DUMPFILE'
      - 'EXEC%20xp_'
      - 'information_schema.tables'
  condition: selection and sqli_patterns
falsepositives:
  - Legitimate use of single quotes in filter values (rare)
level: high

YARA Rule

rule Metabase_SQLi_Field_Filter
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects SQL injection patterns in HTTP traffic targeting Metabase public endpoints"
        cve = "CVE-2026-72899"
        date = "2026-01-01"
    strings:
        $public_path = "/public/" ascii
        $filter_param = "filter" ascii nocase
        $union = "UNION" ascii nocase
        $select = "SELECT" ascii nocase
        $quote = "' OR " ascii
        $sleep = "sleep(" ascii nocase
        $coment = "--" ascii
        $outfile = "INTO OUTFILE" ascii nocase
        $dumpfile = "INTO DUMPFILE" ascii nocase
    condition:
       uint16(0) == 0x4854 and // "HT" = HTTP
       $public_path and $filter_param and
       ( 1 of ($union, $select) or $quote or $sleep or $coment or $outfile or $dumpfile )
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"ET EXPLOIT Metabase Public Card/Dashboard SQL Injection Attempt (CVE-2026-72899)";
    flow:to_server,established;
    content:"/public/"; http_uri;
    content:"filter"; http_uri;
    pcre:"/(?:UNION\s+SELECT|'\s*OR\s+['\d]|SLEEP\s*\(|pg_sleep\s*\(|WAITFOR\s+DELAY|INTO\s+OUTFILE|INTO\s+DUMPFILE)/i";
    classtype:web-application-attack;
    reference:cve,2026-72899;
    sid:7289901; rev:1; priority:1;
)

Elastic Detection

POST /_security/rule/_execute?rule_type=query
{
  "query": {
    "bool": {
      "must": [
        {
          "wildcard": {
            "url.path": {
              "value": "*public*"
            }
          }
        },
        {
          "match_phrase": {
            "url.query": "filter"
          }
        },
        {
          "query_string": {
            "default_field": "url.query",
            "query": "UNION SELECT OR (SLEEP() OR pg_sleep() OR WAITFOR DELAY OR INTO OUTFILE OR INTO DUMPFILE)"
          }
        }
      ]
    }
  }
}

Splunk SPL Query

index=web sourcetype=access_combined
| spath input=referer
| where url LIKE "%/public/%"
| rex field=_raw "filter=(?<filter_value>[^&]*)"
| eval decoded_value = urldecode(filter_value)
| search decoded_value IN ("*UNION*SELECT*", "*' OR 1=1*", "*SLEEP(*", "*pg_sleep(*", "*WAITFOR*DELAY*", "*INTO*OUTFILE*", "*INTO*DUMPFILE*")
| stats count by src_ip, host, url, filter_value
| sort - count

Wazuh OSSEC Rule

<rule id="378235" level="15">
  <decoded>web-access-log</decoded>
  <match>query=|filter=</match>
  <regex>/(UNION|SELECT|OR\s+['\d]| SLEEP\(|pg_sleep\(|WAITFOR\s+DELAY|INTO\s+OUTFILE|INTO\s+DUMPFILE)/i</regex>
  <description>CVE-2026-72899: Metabase Public Card/Dashboard SQL Injection Attempt</description>
  <group>sql-injection,attack,web-application,</group>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>

Mitigation & Patch Guidance

Patch Confidence: 0/4 (UNPATCHED) — No patch is available from the vendor. All mitigations below are temporary until an official fix is released.

1. Immediate Mitigations (Stop the bleeding):

   • Disable public sharing: In the Metabase Admin Panel (Settings → Admin → Public Sharing), disable the "Enable Public Sharing" toggle. This immediately removes all URLs that expose cards/dashboards to unauthenticated users, completely closing the attack surface.
   • Revoke existing public links: If global disabling is not feasible (e.g., due to embedded analytics needs), manually revoke every public link by toggling the sharing off/on or by monitoring all cards/dashboards with enable_embedding or public UUID characteristics.
   • Network-level blocking: Deploy a WAF (Web Application Firewall) rule to block any request to /public/* endpoints that contains common SQL injection signatures (see Suricata rule above). This is a stop-gap measure as SQLi payload obfuscation can bypass signature-based detection.
   • Restrict database privileges: Immediately audit and reduce the privileges of the database user that Metabase uses. Revoke write, DML, and file-system rights if the user does not strictly require them. Implement database-level network ACLs to restrict which hosts the Metabase service account can connect to.

2. Patch / Upgrade Steps:

   • Monitor the Metabase release page and the Metabase security page for advisories. As of this report, no patched version is available.
   • Track the CVE in the NVD (the provided NVD link) for updated version information.
   • The vendor has not yet announced a fix timeline; plan for a hotfix or version bump within the next 1–2 weeks. Until then, treat all self-hosted instances as compromised-risk.

3. Long-Term Hardening:

   • Assume all public links are dangerous: Adopt a policy requiring authentication for all card/dashboard interaction. If anonymous sharing is a business requirement, consider using a multi-layered proxy that terminates SQL injection attempts at the network edge.
   • Database hardening: Enforce least-privilege for the Metabase database user (Prevent SELECT on system tables, no INSERT/UPDATE/DELETE unless required, disable COPY TO PROGRAM in PostgreSQL, etc.). Implement row-level security where possible.
   • Network segmentation: Place the Metabase application server in a DMZ or isolated VLAN with strictly limited outbound connectivity to internal databases.
   • Monitoring: Deploy the detection rules above in production and conduct 30 days of threat hunting to identify any past exploitation of public endpoints (e.g., look for anomalous filter= values in access logs since the public links were created).
   • Incident Response Preparedness: Prepare a data-breach response plan specific to the exposure of analytical data. If the database user had write access, include a data-integrity audit.

References

1. NVD Entry for CVE-2026-72899: https://nvd.nist.gov/vuln/detail/CVE-2026-72899
2. Metabase Security Advisories (vendor site): https://www.metabase.com/security/
3. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-72899 not listed, confirming no known exploitation in the wild as of publication)
4. MITRE ATT&CK Technique T1190 – Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Known Threat Actor Campaigns: No exploit code, public PoCs, or threat actor campaigns have been reported by FIRST.org, CISA, or the NVD as of this writing. However, the critical severity (CVSS 10.0) and the fact that Metabase is a widely deployed open-source tool make active exploitation highly likely in the short term, especially given the trivial trigger (unauthenticated HTTP request). Organizations are advised to prioritize the mitigations above before public PoCs surface.